Messages

1

7DRLs / Re: Voronoiance - 7DRL Success

« on: March 17, 2014, 01:39:14 PM »

I love the concept!

Thanks! It's good to get something out after the idea has been burning a hole in my mind for two years :^)

2

7DRLs / Voronoiance - 7DRL Success

« on: March 17, 2014, 11:11:20 AM »

Win 32/64, Mac OS X and *.love builds here. Linux users should be able to get the Love engine from love2d.org and use the *.love file.



I managed to get a playable game using voronoi diagrams actually done! I've had a back-burner project using far more sophisticated level generation on the go since just before IRDC 2012. My frustration with my lack of progress made me through away the level gen but try and get a voronoi diagram based roguelike done for 7drl 2014.

I'm pretty happy with it but it isn't as polished or as feature packed as I would have liked. I think it's enough to show the basic idea of using non-tessellating geometry for the levels though.

3

Programming / Re: Monster generation

« on: January 24, 2014, 12:24:43 PM »

So I had some special requirements for this, because it was being used for my game MicRogue....

@jasonpickering: So your monsters array gives you relative probabilities and you have the chance to upgrade one monster per-level to a special monster. I'd guess you have a few other constraints you want to apply:

• The total number of monsters per-level. Could be a specific value or a min and max range.
• You want to enforce some kind of variety. For example by saying "I want at least three types of monster on this level".

If you were to put it in Excel I'd guess it might look like this (I made up the numbers for Total and Min. Species):

Level |	Slime |	Large Fire |	Skeleton Warrior |	Demon |	Eye |	Ninja |	Cockatrice |	Total |	Num. Special |	Min. Species
1	3	1	0	0	1	0	0	4	1	2
2	3	1	0	0	1	0	0	4	1	2
3	3	2	1	1	1	0	0	4	1	2
4	2	2	1	1	2	1	0	5	1	3
5	2	2	1	1	2	1	1	5	1	3
6	1	3	2	1	2	1	1	5	1	3
7	1	3	2	2	2	1	1	6	1	3
8	1	3	2	2	2	2	2	6	1	4
9	1	3	2	2	2	2	2	6	1	4
10	1	3	3	2	2	2	2	7	1	4

4

Programming / Re: Monster generation

« on: January 21, 2014, 10:09:13 AM »

that sounds good, but i wonder if perhaps my original way of just building an array for each level might have been the easiest way to go. It would take up some room, but as opposed to doing the equation to figure out how to have 3 slimes on levels 1-3 then 2 for 4-5 then 1 for the rest of the levels, it would be a bit faster.

It sounds like you're trying to do something out of the ordinary. Could you specify the exact behaviour you'd like to see?

5

Design / Re: Are required resistances fun?

« on: January 09, 2014, 10:32:22 AM »

Apart from the obvious sense of getting more powerful the only fun that crudely implemented resistances add to the game is an extra desiderata for inventory management. Even then it largely seems to be a fairly simple set of rules you can apply to make the decision it's just made more difficult by the size of inventories and the number of equipment slots.

Ultimately the interesting decisions are those that force some form of trade-off. Larger inventories, more equipment slots and lots of randomly generated floor trash work against it.

6

Programming / Re: "Game state"-based game loop.

« on: June 27, 2013, 10:50:24 AM »

...
I just recently made a system with states and "sub-states" similar to this. However, I've hit a new snag: Consider the "inventory" state. The title of the inventory window may vary depending on what command is given to access it, like drop, for example. How should this be communicated? It also needs this in order to know what action to take after finishing with the window, like the just-mentioned drop.

Normally I organise it so that my states have arguments when you change to them. So I would pass the title and action on selection into that. It can be tricky to arrange it though depending on the language.

7

Programming / Re: Game Requests

« on: June 12, 2013, 09:17:49 AM »

One day I'll have an idea someone else hasn't had before :^)

8

Programming / Re: Game Requests

« on: June 12, 2013, 08:04:53 AM »

I'll throw the idea of playing the evil artifact into the ring again.

Hah... I almost did that for my thesis. Kind of a puzzle game where you need to manipulate people to do bad things so that you can possess them.

I've been mulling over an idea where you play as a haunted house and try and get rid of the people living in you. At first you're only able to move small objects and unnerve the occupants but you're powered by their fear and can eventually make the walls bleed, throw stuff around and conjure wet asian ladies out of TVs.

The challenge would be fighting against the exorcists and paranormal investigators that can harm you or the goths and occultists that think your shenanigans are cool instead of scary.

9

Programming / Re: "Game state"-based game loop.

« on: June 11, 2013, 08:42:00 AM »

I also use a stack of state objects (I call them Screens in my code) but instead of allowing the states to grab each other's stuff, the shared data gets passed in to the sub-state objects.

That means the code ends up looking like this:

Code: [Select]

enterScreen(new ThrowItemScreen(world, player));

And each state object (such as ThrowItemScreen or PlayScreen) is completely isolated from other state objects. So the map is referenced by the PlayScreen, but also the ThrowItemScreen, ExamineScreen, and probably a few others.

This is definitely the tidiest way to do it but it depends on the state library or pattern you're using. Some of them don't allow arguments on state constructors.

10

Programming / Re: Game Requests

« on: June 10, 2013, 08:28:44 AM »

An Ico style roguelike could be fun. The player (@) is essentially invincible but can be stunned and pushed around by enemies. You have look after another actor (maybe a & to carry on with the sidekick theme) and if they die the game is over.

Normally escort quests are terrible but Ico was really just a big escort mission and worked out ok.

11

Programming / Re: "Game state"-based game loop.

« on: June 10, 2013, 08:22:21 AM »

...
So then the Main and Inventory game sub-state objects would operate on the data in the Game object, right?

Yep, because those states always exist while a Game state exists it's ok for them to access data that Game is the owner of.

12

Programming / Re: "Game state"-based game loop.

« on: June 07, 2013, 10:23:17 AM »

I've got another question about this "game state object"-based game loop: where should the data (like the map) the logic functions use go? I'd usually have it in the game object itself, if the logic function was a member of the game object, but here the logic function is a member of the game state object.

If you have a hierarchical state machine (stack of state effectively) I'd put the map the the root Game state. An example state hierarchy for a roguelike could look something like:

Code: [Select]

MainMenu
    EnterName
    ChooseRace
    ChooseClass
Game
    Main
    Inventory
EndGame
HiScores


13

Programming / Re: Brilliant Observations by My Brother

« on: June 05, 2013, 08:29:24 PM »

I actually never played any of the Metroid games. So, if you people would recommend a single of them to play, which one would it be? Super Metroid seems to get mentioned a lot?

As always,
Minotauros

Super Metroid is definitely worth a go and probably the clearest example of the Metroidvania style. Whatever you do don't play The Other M, it's terrible.

14

Programming / Re: Brilliant Observations by My Brother

« on: June 04, 2013, 11:23:45 AM »

I think the art of level design might be to railroad a player down a path, but have him be completely oblivious to the fact that he's being railroaded.

I think this is where badly designed games and poor procedural gen go wrong. In an ideal world we should be being lead around by delicious carrots and not beaten with arbitrary sticks like invisible collisions.

...
1) The dungeon is shaped like a skull!

Link's Awakening (probably the best Zelda from a Dungeon Design PoV) repeated the same trick of the dungeon shape matching the theme. I think this could bode well for procedural generation because it means that almost any overall shape can be made to work.

I think your points about rooms off the critical path is totally valid. If anything the problem with modern AAA games (especially corridor shooters) is that they don't have enough of them, they are critical path and nothing else. I think roguelikes fail in not properly handling such 'dead-ends' though.

Roguelikes and some Metroidvanias (I would count Dark Souls as a Metroidvania at least structurally) also add another interesting take on critical paths, there can be more than one.

I'd strongly believe that ideas like critical paths, dead-ends, necessary and optional items, abstract keys and doors (e.g. the hookshot is a 'key' and a chasm you can cross with it is a 'door') can be packaged together and used to make interesting level generators.

15

Programming / Re: Brilliant Observations by My Brother

« on: June 04, 2013, 09:08:08 AM »

Like I told him, "Dude I would love a good Zelda game but procedurally generated."
Brother:"So you'd keep the worst part of Zelda and get rid of the best part?"

Like Binding of Isaac? :B

Binding of Isaac isn't bad for 3 months work from two guys but I would agree that it makes design mistakes with the power-ups and the level gen could be a lot better. With over a million sales it does prove there's a market for games heavily inspired by roguelikes though, which is nice.

I posted the Zelda and Metroid analyses because I don't think we really have a firm grasp on what makes such hand-crafted level design good. I don't think the analyses are perfect but they are at least a start on the road to understanding the problem.

There are some interesting articles that do analyse games level design though which could be a start. Here is one for Zelda and here is one for Super Metroid.

...I don't really have a YES YOU'RE RIGHT or NO BUT YOU'RE WRONG, IDIOT to add to either one since neither one tries to SAY something.

Quite a bit of your rant is essentially you shouting NO BUT YOU'RE WRONG though. The Zelda analysis basically says that placing necessary items off the critical path is bad, which is a debatable point. No one is complaining about heart containers or other unnecessary upgrades being off the beaten track.

The metroid articles points out that 'dead-ends' always have items (optional upgrades) in there. Makes sense if you want to encourage exploration but it's also something that roguelikes don't really do except by random chance.

Dark Souls allows for some measure of free roaming, but it's mostly an illusion. There's a couple of places you can go to "out-of-sequence", but Anor Londo is locked off untill you ring both bells of awakening, and you have to go through a fortress that was previously closed to get to Anor Londo. There's a few instances where you can choose which route to take to get to a place, and there's more than a handful of places you NEVER have to go to in order to beat the game, but sheer curiosity will see most players going to every location.

Zelda 1 had far more free roaming than say Dark Souls or Super Metroid but LttP is pretty much on par with Dark Souls for openess. Also Dark Souls gives far more exploration opportunities than say Brogue. You can do the bells in either order (even missing out entirely on the Depths and Blighttown), then Sen's and Anor Londo then the 4 Lord's Souls in any order. One of the Lord's Souls can be obtained right at the start of the game.

Kind of off-topic-- but, supposing you went the procedural Zelda route- what would you do to the combat mechanics to make it relatively interesting?

If you wanted it realtime something like Dark Souls combat could still roughly work in 2D. So you have to actively hold your shield up, time attacks carefully, weapons behave differently, slow down the pace a little compared to normal Zelda.