My Dungeon Game [work in progress]
- Thread starter Jadzia
- Start date
I have already considered procedural generation, and I haven't ruled it out. 
I made a PG dungeon algorithm a year ago for a friend, but his project didn't go any further than asking me to make that algorithm, which annoyed me. It's quite bit different, but I could reuse the ideas I had then as a starting point here.
However, I'm concerned that the end result wouldn't be worth the effort. Levels designed by a human can be clever, interesting, and with balanced difficulty. I think these qualities are important for arcade games with fixed level sequences. Procgen all too often produces data that seems to lack those qualities.
So I'm undecided. It's something I can look at towards the end.
I made a PG dungeon algorithm a year ago for a friend, but his project didn't go any further than asking me to make that algorithm, which annoyed me. It's quite bit different, but I could reuse the ideas I had then as a starting point here.
However, I'm concerned that the end result wouldn't be worth the effort. Levels designed by a human can be clever, interesting, and with balanced difficulty. I think these qualities are important for arcade games with fixed level sequences. Procgen all too often produces data that seems to lack those qualities.
So I'm undecided. It's something I can look at towards the end.
One thing you could do as a halfway measure to procedural generation is to have a batch of fully human-designed level chunks and then have a generator mix and match them to build levels. That way, you can have the cleverness of human design while allowing for unexpected level arrangements. It seems like the best of both worlds although it would admittedly be a bit of a pain. You'd probably need rules to determine what kinds of chunks can be adjacent to each other and so forth.
That's why you allow variability in orientation and so forth, and not have the chunks so big that their similarities are obvious.
Plus, if you have enough unique chunks there should be very little repetition.
Plus, if you have enough unique chunks there should be very little repetition.
What might work is having chunks different sizes.
If all chunks are big (24x24)--> (+) Potential to be clever and interesting. (-) Familiarity/repetition is bad.
If all chunks are small (8x8) --> (+) Easy to get unique layouts. (-) Could look scatty. Unlikely to be clever or interesting.
If chunks are mixed sizes --> (+) Potential to be clever interesting and unique. (-) Not as easy to fit together.
A different idea I had last night was to:
If all chunks are big (24x24)--> (+) Potential to be clever and interesting. (-) Familiarity/repetition is bad.
If all chunks are small (8x8) --> (+) Easy to get unique layouts. (-) Could look scatty. Unlikely to be clever or interesting.
If chunks are mixed sizes --> (+) Potential to be clever interesting and unique. (-) Not as easy to fit together.
A different idea I had last night was to:
- Design the overall layout/flow of a level on maybe a 3x3 upto 8x8 grid. (eg, Spiral to centre, Zigzag from bottom to top, Randomly branched). Each location in this grid is a 'room'.
- Decide on the 'room' size (8x8, or 12x12, or 16x16 tiles).
- Place those main structural walls.
- Decide if there's going to be any symmetry (Left=Right, Top=Bottom, Quarters, None).
- Decide if the level is going to have low/intermediate/high wall density.
- Select appropriate detail for each of those 'rooms'.
That sounds good. I actually was thinking about chunks of multiple sizes before you mentioned it! Since your levels are going to be gridlike to begin with you could get away with having chunks of any size. To keep things sane, you could require that they are all square, though rectangular chunks could allow for more variety--it would just make the random distribution trickier.
The rules for detailing each room are where the real interest would lie. One thing you could do is try to equally distribute powerups throughout the level. Use a pathfinding algorithm to find the quickest path through the level and then drop powerups every n steps (plus or minus a random fudge factor) along the way. This would keep the levels "fair" and avoid concentrating powerups/items too close together.
Something else that occurs to me is that you could add a lot of variety by having multiple tilesets. So you'd have a set of predefined chunks which are just arrangements of walls, but you'd randomly choose a tileset for each level's graphics, so each level would have a "theme." Combined with random decorative details, the same chunk would look decidedly different between a snow level and a desert level, with different decorations, powerups, and orientation.
I actually was thinking about chunks of multiple sizes before you mentioned it! Since your levels are going to be gridlike to begin with you could get away with having chunks of any size. To keep things sane, you could require that they are all square, though rectangular chunks could allow for more variety--it would just make the random distribution trickier.The rules for detailing each room are where the real interest would lie. One thing you could do is try to equally distribute powerups throughout the level. Use a pathfinding algorithm to find the quickest path through the level and then drop powerups every n steps (plus or minus a random fudge factor) along the way. This would keep the levels "fair" and avoid concentrating powerups/items too close together.
Something else that occurs to me is that you could add a lot of variety by having multiple tilesets. So you'd have a set of predefined chunks which are just arrangements of walls, but you'd randomly choose a tileset for each level's graphics, so each level would have a "theme." Combined with random decorative details, the same chunk would look decidedly different between a snow level and a desert level, with different decorations, powerups, and orientation.
Okay. Here is output from newly made random dungeon structuring algorithm.
This is tree like at the moment (so ignoring symmetry). It wouldn't be hard to make additional connections between the room nodes, if we wanted to.
Too many dead ends might be undesirable too. We could preferentially make any additional connections through these so that they're no longer dead ends.
This is tree like at the moment (so ignoring symmetry). It wouldn't be hard to make additional connections between the room nodes, if we wanted to.
Too many dead ends might be undesirable too. We could preferentially make any additional connections through these so that they're no longer dead ends.
I've had a lot of rest and relaxation these past few days, so I didn't do anything to my program over the weekend.
This afternoon I've created 12 other procedural generation algorithms in addition to the one above, which produce a variety of different shaped dungeons.
One produces long snaking passages with a few small side shoots. (a derivative of depth first search) which is possibly my favourite algorithm of them all. Two algorithms produces simple patterns: spirals and zigzags. Some produce random dungeons with lines of symmetry, or different near the middle than they are near the edge. Some produce dungeons with greater connectivity than a tree.
This has become a bit of a digression, adding breadth to the project. I believe it will be all the better for it, and it'll all come together eventually.
This afternoon I've created 12 other procedural generation algorithms in addition to the one above, which produce a variety of different shaped dungeons.
One produces long snaking passages with a few small side shoots. (a derivative of depth first search) which is possibly my favourite algorithm of them all. Two algorithms produces simple patterns: spirals and zigzags. Some produce random dungeons with lines of symmetry, or different near the middle than they are near the edge. Some produce dungeons with greater connectivity than a tree.
This has become a bit of a digression, adding breadth to the project. I believe it will be all the better for it, and it'll all come together eventually.
Interesting. The direction you seem to be heading in seems like you could make some sort of Tron RPG, The dungeon made up of lightcycle trails or something.
Well, I assume those are just shapes and not the actual textures that will be used for the tiles, right, Jadzia?
I can visualise that. It's a nice idea.
I think that would be best made as a 3D game with a WoW-like camera.
I don't think plain/thin light cycle walls would look right in 2D, unless we downgrade to wireframe.
Correct.
True, although the way I was thinking about it was to have the walls drawn from an isometric perspective, unless that's what you meant by 3D. Thin 3D walls, though I can imagine that would be even harder to do due to perspective and wanting everything to mesh together.
Weapons could be discs, with more powerful ones as you progress, with the goal to get to Tron, similar to the original movie, although I haven't seen it yet, I can imagine you could put some of the sequel's elements in it.
the Tron Dungeon would work @ a wireframe level. with random elements and proper graphic work the whole thing could come together by just pushing a few buttons.
Game creation software is expensive but well worth it for the right group of programmers and artists in the end the money is the compensation for the upfront stuff.
I have not taken the plunge into more gaming work due to the falling three dimensional fourperson chess game creation failure that happened like eight years ago on my end.
these days I just test the new games that are in beta or alpha ..,
this seems alpha stage
idea: sound interactive triggers??
reach a hole in the floor player hears a creek then falls unless the person is moving quickly??
anyway if you need graphic backgrounds I can let you have any of my fractals which are really four dimensional dungeons based on some math.
I'd call that isometric.
What I meant by 3D was polygon/model based with 3D camera, which is something I don't do.
I think in general there's been a lot of disagreement over the meaning of 2D and 3D. The term 2.5D was invented to help, but it has ended up being applied to pretty much everything that occurred between Pong and WoW.
Unfortunately I don't own the IP, so am not going to be making a Tron game.
think said:
I don't know if arcade games should rely on sound feedback. Traditionally appearing in noisy arcade halls with loud music playing, the player couldn't be expected to hear and react to every sound effect... and that defines the mood of arcade games for me. It's an option I'll consider, but I think I'd prefer to have the game rely on visual feedback, and just use sound effects aesthetically.
That's very kind of you think. However, I generally swap graphics around until I'm happy with them. I don't know yet if fractals would fit with the theme. But I shall keep your offer in mind, thanks.
Right, and I agree. I think that it could done done using isometric perspective rather than 3D. I just wanted to make sure we were thinking about the same thing here
I think of 3D as something with a moveable camera. That helps with the distinction, as something isometric usually is static. And I agree about the term 2.5D. I remember early 3D shooters such as Duke Nukem 3D often got the term 2.5D applied to them because they technically weren't real 3D compared to what we got later on, and instead used tricks, so the term got muddied even further.My main criticism against Isometric is that it can feel awkward controlling a character, since graphics follows diagonals but the controller is horizontal/vertical. Replacing keyboard with mouse control, we'd be into Diablo 2 territory, which obviously works well.
I did a little to my procgen program this evening. It may not look much, but it begins creating a game map from the connectivity worked out earlier. These are the main structural walls defining the layout/flow of a dungeon. Obstacles, doors, collectables, generators and monsters can be added into this. I'm intending for the game screen to show about 16x16 tiles, which is a bit wider than the 12 tile corridor width seen in the left picture.
I did a little to my procgen program this evening. It may not look much, but it begins creating a game map from the connectivity worked out earlier. These are the main structural walls defining the layout/flow of a dungeon. Obstacles, doors, collectables, generators and monsters can be added into this. I'm intending for the game screen to show about 16x16 tiles, which is a bit wider than the 12 tile corridor width seen in the left picture.
Very nice! I look forward to your next update.
Today I've been looking at FMOD. This is an API for managing sounds, and I've never used it before. In previous games I've used DirectSound, but I'm trying to move away from directx.
FMOD is over featured for my needs, so have spent a bit of time this evening seeing how it all works and making a simple front end for it using the 3D sound interface.
So now all I need to call is one or two functions like
"Use this file as sound effect 1"
"Play sound effect 1 at these 3D coordinates"
I like simple no-nonsense abstractions.
FMOD is over featured for my needs, so have spent a bit of time this evening seeing how it all works and making a simple front end for it using the 3D sound interface.
So now all I need to call is one or two functions like
"Use this file as sound effect 1"
"Play sound effect 1 at these 3D coordinates"
I like simple no-nonsense abstractions.
Rett Mikhal
Captain
Have you ever looked into Nethack, the king of dungeon crawlers?
Similar threads
