dungeon mapping
Community Forums/Showcase/dungeon mapping
| ||
initially centered, but now lives in the top right corner: And a couple of generated maps:   maps are revealed as you go through each room. generation is procedural, instant and is progressive (rooms are numbered as they are created so that keys can be placed to open later rooms) |
| ||
| Looks nice but : (not a big issue but think about it) One important thing in games is to have a consistent graphics style, so that it looks immersive and coherent, which means that the shapes and colors must appear to be from the same world (made in the same way), but in this screenshot, the floors walls ceilings doors and the character, clothes, weapons have a different graphics style, some are made with "smooth" shapes and detailed textures and some are made with small cubes. |
| ||
| Reminds me of Gauntlet! I liked that game but Druid was better. I agree with Remi. I think your floor is nice but the walls, especially the top isn't quite right. I like the inscription on the wall but it might be better on the top and some bricks for the walls instead. It's just a bit "samey". I think I sort of said this already so sorry to repeat myself. lol Cool map overlay. |
| ||
| yep, noted. I spent ages with the last revision getting stuff to look right and neglected the gameplay. I'm gonna go for gameplay first this time around :) |
| ||
another peek with some new grass and room contents: |
| ||
| @AdamStrange>>Since i currently work on a similar game (i mean with rooms and passages and obstacles and turningmoving characters), let's discuss a bit about these topics (if you don't mind) : About pathfinding : How do you manage the nodes/pathcalculation/pathfollowing, per map ? per room ? (i plan to to manage the nodes/pathcalculation/pathfollowing per room) Do you use nodes positioned on a grid or nodes positioned around passages, around corners, around obstacles ? (i plan to use nodes positioned around passages, around corners, around obstacles) About collisions detection and repositioning : What is the logic of your collision system ? (i plan to oriente/translate one turningmoving entity at a time, then calculate if a collision happened with the static environment or with static entities, and if yes, reposition the turningmoving entity at the appropriate position, knowing that each turningmoving entity has one or several ellipsoid colliders, and that each static entity has a low tris mesh collidable.) About maps and loading/buidling/saving/destroying : How do you manage the passage from one map to another ? (i plan to use "entranceexit(s)", which are meshes with, as a property, the name of the target map to load) |
| ||
| lordy - big and interesting... :) first off. the entire level map is 128x128. with a map position being: * none - nothing at the position - blank, dead space * floor - there is a floor * solid - these is something on the floor that blocks your way * wall - as solid, but has no floor and can't be blown up/removed so in essence, there is a floor or a solid movement is in sub position movement. so a traditional roguelike would move one square, I move (10x) per square, so you can be present on up to 4 squares at a time pathfinding * there isn't any. I use a monster type, with each different type of movement dealt with separately. your man is also the same type, so a single base type that handles basic moment in any direction works across the board. * Each monster then decides what it is doing and does it (move left, right, up, etc) Different movement types, would have different logic, but the underlying system is the same. collision, detection * for any movement. check to see if you can move in that direction (4 directions) and the move (if possible) * because movement is sub square based. I actually use y rotation on every monster. This way you know the explicit direction the monster is facing * when a monster goes in a different direction, you also need to rotate the facing direction t cace that way. I do this in steps so the monster/you will turn to face slowly I did a lot of pre-work (see all the entries over the years) and came up with this: * a generic monster type that has everything a monster needs, position, type, rotation, etc a fixed number of monsters (I currently have a max of 200) - in a linked array a monster is added to the array when it is 'born' and remove when it dies. some monsters are born, but not active! * collision detection is number based. - you have the four corners of the monster - you have the map - check if each corner is colliding at that map position (beware of sub positions - hence ditching float for a custom fixed point) - sliding collision, etc is automatically handled: if new space free then move ---- each frame ---- * update any existing monsters - the monster update will check if there is a collision with you too - decide any moment, etc * check user input * display * maps: - currently it's all dev so I just press R to regenerate a new level (it's now instant). - in practice there will be stairs, ladders, holes, etc to go between levels - the map is completely separate from the display - so it could be shown as ascii or flat. I chose to use my 3d view - I spent weeks fighting with auto generation of dungeons - they are really hard to do without becoming boring. the more detail you want, the harder the code becomes. - I'm currently playing with a very simple start room, add doors, try to add room < repeat - one thing I found was to do with progression from room to room. Say you want a locked area - where do you put the key? - I now use a system where the first room is 1, then next room (which can be accessed from 1 is 2. the next room (could be from 1 or could be from 2) is 3, etc - so is there is a locked door that goes from room 5 to room 12. the key can simply be put any any room 1,2,3,4,5 - a quick random and placement * doors - doors come in 2 type up/down and left/right - this handles the different directions needed to access each door - doors are then solid - closed or locked - you can't pass - or open - open or bashed in - you can pass |
| ||
| You chose to work with a grid layout, which is easier, i have tried to manage ai and collisions detection and repositioning on a map with a grid layout and on a map without a grid layout, and with grid based turnsmoves, ai is simpler to code and there is no need for collisions detection. Anyway it is interesting to discuss about it, sometimes we can find interesting ideas. :) there will be stairs, ladders, holes, etc to go between levels Yes, that's what i call the "entranceexit(s)" I'm currently playing with a very simple start room, add doors, try to add room < repeat I do something similar : add start entranceexit, add first room, choose a random room, choose a random wall, try to create a temporary passage, try to create a temporary room, check if there is enough empty space to create the room, if yes create the passage and the room, if no choose another random room, until too many tries have been done unsuccessfully, then add others entranceexit if wanted. I spent weeks fighting with auto generation of dungeons The best way i have found to build rooms and passages or caves and tunnels is to use my own logic, i have studied some examples on the web but none of them corresponded to what i wanted, but it can help to find new ideas. About doors : Personally i use the words "dpassage" for a passage with a door and "wpassage" for a passage with a window. And not all passages have a door or a window. And for those who have a door or a window, some of them have a lock which can be locked or unlocked. (so some of them may require a key) Since you know which rooms are connected to others rooms, here is a cool idea for "occlusion culling" that i have written before : (This assumes that you know which rooms are connected to others rooms) I hide all rooms I show the room where player is (the active room) I show the rooms which are connected to the active room I show the rooms which are connected to the rooms which are connected to the active room This works well and it does not take much time to do these calculations. The other thing i do is that all the meshes which are static (columns, sculptures, containers, furnitures, rocks, plants) are set as childs of a room and thus are shown or hidden automatically if the room is shown or hidden. |
| ||
| I thought about trying a doom type layout where everything is based on a triangle and binary table, but i couldn't be bothered to get into the logic - but it's on the back burner. I tried culling with view frustrums, lod, etc. but found that the models I was using were too high poly count and started to bring the fps down. Currently I reverse the user position to a window and only render what is in the window - if it has been visited... it's the main reason i went from flat back to textured rendering. The grid mapping needs collision because I am moving at sub tile movements. I'm currently prototyping an automatic wall hide for village/town rendering - sort of advanced nightshade (ultimate play the game) |
| ||
| The gris mapping needs collision because I am moving at sub tile movements Not sure what you mean by that ? One thing that i am doing differently from what you are doing is that i include the wall inside the tile/cell, so a tile/cell can have a floor, a wall, a ceiling, a passage. (whether it is a room or a cave) Here is a good explanation about "occlusion culling" : http://docs.unity3d.com/Manual/OcclusionCulling.html |
| ||
| excellent article there. One thing that strikes me is how primitive Max is compared to Unity Should have been grid not gris - broody smel checking lol I've got a quick definition of what I call subgrid movement:  in a normal rogue-like, you have a XY map grid and you move in one map position per round. there is very little collision needed apart from: IF MAP[newX, newY] = FLOOR THEN moveto(newX, newY) Both X and Y can be integers and the world is lovely subGrid mapping uses the same map, but floats for the actual positions, so instead of moving one map position, you move (say) 0.1 This complicates collision checking as you now need to check what is infront of you and also to the sides (as you never know where (in float terms) you actually are. |
| ||
Here's a mini gif of the wall hiding I was working on: and a link to the concept: https://www.youtube.com/watch?v=ZbhDiL2VoeE This also shows the staff with the glowing orb on the top and surged movement. You can also see the main character rotating to face the direction of travel - yep, the orb does sort of blur behind him when he moves :) |
| ||
| Love it! |
| ||
| I love the wall hiding work. Awesome idea! Brilliantly implemented. This man will go far! I hope. lol |
| ||
| some of it is bloody mind bending though ;/ just spent loads of time trying to figure out why particles wouldn't show on the black background... Eventually needed tweaks to 3 shaders and 2 sources. All to do with depth, models, and perceived depth - very subtle (particles are rendered in 2d but with true depth) Here's the result (with them correctly showing on the background)  |
| ||
| ..it looks like a tree growing out of his hand..hehe..but generally speaking, i really like your work..im just wondering when will project be completed and/or some demo available to play with because i am not sure what kind of game this actually is.. |
| ||
| Weird but nice effect indeed ! (maybe try it with one color and different shades of this color) |
| ||
| weird is good :) but again it can be tweaked later - currently it doesn't actually do anything... I'm just playing around with the actual mapping generation, plants, etc. Unlike the other dungeon stuff I posted - this will be completely procedural - so I can only tell it what to do and have no idea about what it looks like :) |
| ||
here's a quick peek of indoors, outdoors and automatic up/down deciders:     |
| ||
| @Adam>>In case you don't know about these games, take a look, it may give you some ideas : Delver : https://www.youtube.com/watch?v=nyN5PbKPiks Dungeon prospector : https://www.youtube.com/watch?v=B6OET-htMmM |
| ||
| i've got delver - did not like it lol not come across prospector. being honest - They both come across as sub-par doom |
| ||
| Holy grap! Adam you really are close to a killer game. Keep it up dude! |
| ||
| . |
| ||
| Anyway, good luck! |
| ||
| @munch>>a bit more aggressive (about thunder) https://www.youtube.com/watch?v=oxt4CQhTGD8&t=15s |
| ||
Here;s the new modified mapping with popup The track has a certain something about it - I like the drive :) I've not thought about music as such yet, but I do have a nice tool to do it all in : https://vjointeractive.wordpress.com/wave2-fairlight-cmi/ I currently use it to cut, edit, customise the audio :) But it is a very advanced sequencer too (music I made only with the app): https://soundcloud.com/mavryck-james |
| ||
| Personally i don't like music in games, except if it is in appropriate places (in a bar/tavern or near a speaker or near a musician who is playing) or maybe a motivating music while in combat (diablo 1 style https://www.youtube.com/watch?v=B8klPYjS3ws&t=01m07s )) But the music should be calibrated depending on the game ambiance, your game ambiance seems calm and playful (not like diablo 1 where it is oppressive/scary) |
| ||
| your game ambiance seems calm and not serious Nah, it's deadly serious. Can't think where you got that idea from?  |
| ||
| éhéhéh :D |
| ||
| I like the popup, remains me of an old amiga game though I cant recall its name, going to drive me mad all day. |
| ||
| This really is looking great. At first I thought, well nicely different style, but probably not something I would play, but now.. There's so much action and a visual happening! Love the way you make it come across. Gives me that old Pacman-want-to-play feeling. Just amazing to watch. |
| ||
| The popup mapping seems to be too near from the character. |
| ||
| The popup mapping seems to be too near from the character. I've to agree with that..you should get a higher distance from the popup (2-3 tiles away at least) or the player will have that constant feeling of one step from falling into the abyss. In my opinion i dont like to see those kind of popups in games (many Minecraft clones have that). You get the idea that nothing exists from that point, and i like to think that world is infinite. Apart from that personal opinion i like everything about your game. |
| ||
Just a couple of shots showing the new UI: You can see the life on the bottom left and the magic on the bottom right. gold is in the middle. Top right is the map. Either the indicator (m) or the map itself with new alpha:  There is new graphics and animation for the bomb and the magic system is now functioning with magic being depleted and renewed. When MuShu dies there is also Naked Angel on death!  And a slight modification to the pop-up system. Rooms appear as one when you enter. only outside pops up (with more tiles being shown per popup. |
| ||
| I would love to see a Moria remake using your engine. Jason |
| ||
| interesting to go back and look at Moria and Angband, etc. In essence this is a dungeon crawler (of that sort), just with my own take on things :) |
| ||
Trees have now made an appearance:  Each tree belongs to a family, and is unique so no two trees are actually the same. Trees also alpha fade when you are behind them:  |
| ||
| I may have more time in Angband than any PC game ever. Moria was my first intro to roguelikes on the PC back in the early 90's. |
| ||
| if you have any suggestion, help, thoughts... :) |
| ||
| This is really coming together pretty nicely(I wanna play!). The trees in their current size(even though looking good) may be obscuring the vision a little too much, or intentional? The occasional torches or lanterns, fireplaces? |
| ||
| yep - trees made a little smaller. slowly adding other decoration now :) |
| ||
| I am curious : why do you choose to focus on creating the graphics first ? I have already tried this approach in the past and nearly became obsessed on little (unimportant) details then i realized that what matters the most in a game is the gameplay (controls, ai, actions, interactions, possibilities) ? So now, i first focus on the gameplay and then i focus on the graphics (meshes, textures, animations) and the sounds (from sources, ambient). Since you have apparently tried to create several different games, what are your thoughts about that ? (focusing on creating the gameplay first vs the graphics and sounds first) |
| ||
| mmm, interesting one. I think first off I don't have a good idea of where or how things are going to go, so I start with a bare bones general idea. In this case it was taking the basic game framework I have and the low poly models (the higher poly ones took down the cpu). With the last game I found that doing the game/graphics was fine, but adding sound is a real chore after the fact - it is more sensible to do it at the same time! Note, I haven't done music as I need to get the code ready for that. So Now I have a framework, with base models (blank floor, blank wall, blank monster/you). I then worked on the movement and basic map system (in essence the first image in this message (although it has more advanced graphics)). All monsters use the same core code, so I just needed to get this right, and all monsters will be right (with error checking on the map, etc. It turned out that this wasn't working as expected and I needed to do a quick and dirty fixed precision number system. -------------- So at this stage we now have basic mapping, movement, blank graphics, etc. User input, sound, page systems (start page, options, page, etc) are all handled though a number of files that make up my game framework - they are all agnostic so can be used to make any system. you can move, there is a map, you can drop a bomb, it goes off and destroys stuff - basic bomberman. Another person (who sometimes comments) was doing something very similar - so similar I needed to form the concept into something else. I toyed with walls, and wall hiding. and then also remembered nightshade (ultimate plays the game). I went and had a look and liked the graphics and thought "medieval town looks nice, wall hiding, nice..." So I took everything and stared in that direction. Taking the rpg concept I had before and got as far as I could with the graphics ssystems. I liked at what I had and thought How can this be a game? My prior issues were to do with making something look pretty meant you have to design it. I wanted it procedurally done - so I have no idea of the end result. Now (taking all prior work and concepts) I sat down and though how do you create something that feels like a place (with what I have got). I have rooms and an order (I didn't have this before) - this means I can set a goal and lock rooms. Group rooms together can form a house. thin about how the village would be made up, remove some walls to make gardens and smaller dwellings. Add some water (or not) and decide if the water surrounded a house, maybe this could be a mill. if we have a mill then the people would not be too poor, etc, etc, etc The basic gameplay is still the same: map, movement, drop bomb. everything else is just gravy - complex gravy, but just dressing. I also have more and more complex building routines to decide the makeup of a village. Here is the text output from a couple of runs: ---------------- water=81 no mill artisans poor market town poor rating = 60 markets = 1 room count = 20 room 2 is now a market plaza room 15 is now a market plaza income = 40 has church room=1 house=1 rooms=1 plaza 2 size=6,3 plaza 6 size=5,3 plaza 9 size=5,3 plaza 15 size=8,5 ---------------- water=94 mill is in room 18 part of house 6 (3rooms total) artisans some trading poor rating = 20 markets = 3 room count = 20 room 8 is now a market plaza room 4 is now a market room 15 is now a market room 19 is now a market income = 60 no church outside 14 size=1,3 outside 4 size=7,8 plaza 5 size=2,5 plaza 8 size=5,5 You can see that I am working out how a village will be structured - from this the graphics and contents will correspond. So the graphics and building system are done at the same time I now do the sound as I add new stuff as it is much simpler to know where the sound should go as you write it Although the gameplay is functional - there are no enemies. but the game is already coming up with the basic details of how task/quests should be given. The dungeons/mines will follow the initial village design... |
| ||
| I wanted it procedurally done - so I have no idea of the end result. Same thing here, so that i want to explore the environments and still be surprised how it is assembled. I find really boring to create maps manually... Anyway, it looks good so far, maybe add some enemies and different spells and create a small game with a wizard... |
| ||
| maybe add some enemies and different spells and create a small game with a wizard... Yep, I was thinking the same sort of thing. I want to test how the upper floors and lower levels operate next. I know what to do, just have to code it :) The one thing I really have to say about all of this is the tools: * 2d graphics requires a tool (photoshop). * 3d needs a program and a 3d library - i built my own * sound needs an editor - again I built my own * games need some form of framework - as above 3d is a whole nest of pain particles, shaders. and making it all work together sound is a different pain (audacity is good for capturing) anything else it is terrible. Getting people, anyone at all interested in support, help, suggestions is virtually nil! |
| ||
| ok, just got some spells operational: lightning - what you expect fireball - what you expect What spells would be good to have? |
| ||
| Haste, unlock door, invisibility, froze enemies, summon some beast to help... |
| ||
| I'd would be nice to have spells that can be used for puzzle solving: Such as: Wind Blast - Pushes items / enemies one square and lever control. Teleport - Move char through obstacles. Light Orb - For the darker dungeon parts. Stone Skin - Protection. Reveal - Show hidden items / secret passages within a short range. |
| ||
| ok, here are the first 3. these are the look and basic operation, but not what they might do on contact - they do break down doors though ;) fire - blasting a door to bits:  fireball - press to make bigger fireballs. on release they are launched:  and lightning - this has new staff animation (at the top):  This one shows the magic (mana?) held in the purple bottles diminishing Each spell type has a different staff animation on the top of the staff - the fire has flame and smoke effects You might also note that MuShu (the wizard) has different animation when casting? |
| ||
In heroquest (since we were talking about it), there are 4 elements : earth, water, air, fire... Maybe this can give you some ideas |
| ||
| I've decided on 4 different types of location: conifer - pine trees grassland tundra - wheat crops, etc tropical Although they all use the same general procedural systems, each has it's own ecosystems, plant and animal life, challenges, etc. Here are 3 different takes on tropical from lush to sparse:    One last thing... All of the vegetation moves, so trees slowly wave. Plus large plants are all unique - they all differ slightly too. it's all very subtle but makes at come to life :) |
| ||
| Looks good, but the trees are too small compared to the characters and the buildings (except if they are supposed to be "small cultivated trees") If you need inspiration for terrains and vegetation, you can take a look at the terrains of "magic the gathering", many beautiful examples. |
| ||
| mm, it's all tweekable :) The actual height/size of vegetation is determined by the amount of water. but I've increased it a little. Never come across Magic the Gathering before |
| ||
exterior bits slowly being added (procedurally of course). Today it's shrines:   There are 4 main gods, plus some wildcards. so worship at your peril and don't bother them too much... |
| ||
| When you say "procedurally", do you mean that all is made (modelised/textured) by code, or that premade parts are assembled randomly by following some rules ? |
| ||
| Looking very impressive - how about a ranged weapon (bow and arrow) with exploding arrows - could be along the lines of your wand/fireball. |
| ||
| @RemiD I know where your going with this. and yep - its both! At its core is a simple tile system. the map is procedurally generated (from a set of rules). The parts fit into a single tile. But... Some parts are themselves procedurally generated. E.G. the plants. Each plant has a genus (a type). but is totally unique - the model is different - the code crates the mode for the plant when it needs it and decides itself how it will look. Plants are procedural. Ranged weapons could be done, but currently I'm focussing on the spells side of things - although I could add another character later with that ability |
| ||
| Some parts are themselves procedurally generated. E.G. the plants. Yes but with premade parts. This is not a critic, i do the same... I am impressed by games like "kkrieger" where all is supposed to be modelised textured with code... |
| ||
| Yes but with premade parts. hmmm, I think that's more pedantic and subjective. kkrieger is generating known (within a defined range). It certainly looks like there is some form of base model system in operation - even if the model are code generated? Using the same terms - all my 3d models are totally procedurally generated, as they are made from primitives (modelled from code, not from models) and then pulled/pushed into place, and then further procedurally animated, etc. They are then stored as vertexes - which fixes them? I will admit that the texturing is a single bitmap, but again there are procedural stuff going on in the shaders. I do have completely procedural texture shaders, but chose not to use them. It is much simpler to give procedural generators known stuff to work with, otherwise you generally end up with much that looks like crap <but you might want that?> |
| ||
| My intent was only to clarify what we mean by "procedurally created". Personally i have always said that i assemble premade parts with code to build my environments. Only a few things in my game will be created only from code, like the heights colors of terrains, and the shapes colors turns moves of particles. The others things are created with premade parts assembled randomly by following some rules. (but maybe this is also what is meant by "procedurally" = to follow a procedure) It certainly looks like there is some form of base model system in operation I hope so because else i don't understand how they created it. <but you might want that?> Even if i don't want it, my graphics skills are very basic, so it will look very basic (low tris shapes, few colors). |
| ||
| pity you are not using Max, I could help you out :) |
| ||
| You already help me when we discuss about how we make/manage the things in this kind of game. ;) I wish that "omnicode" would discuss a bit more on the forum, see what he has done : http://www.blitzbasic.com/logs/userlog.php?user=15985&log=1872 it is quite good imo. |
| ||
| just checked it - I Love the tiny map in the top-right :) The rest - not so much. sorta cheap skyrim? Checked out the website - not brilliant - forum is wonder-spam |
| ||
| Impressive! Keep your style, it's unique (not 8-bit like in the video posted above) |
| ||
| LOL, thanks degac. ok, map edges now have an actual edge (simple but effective):  Also some items can now be carried/picked up (they appear above your head) and thrown - along with throwing arc and suitable sound effects. There are also new metal doors, locked doors (which need keys), doors that open, etc - sort of advanced Heroquest (for RemiD) |
| ||
Here's the latest shot: So what’s so special about it? First off there’s mist (which swirls around) and fire - well there was until I picked up the fireskull ! Then we’ve got a pit and if you look really hard you can see there are spikes in the pit… and they move. Oh and what about the rope bridge? |
| ||
| Nice, but i still think that mixing "meshes made of small cubes" and "meshes made of triangles" looks inconsistent. When i look at your previous screenshots, only the sorcerer and the pig (and maybe the chest) seem to be made of small cubes and the others seem to be made of triangles ? |
| ||
Deaths are also being described: @ RemiD MuShu New...     Also MuShu can now be different colors, so that makes different hats, robes, etc more simple. the white edging is also removable and colourable. It is possible to play MuShu without clothing! ;) |
| ||
| "Perfect" death...? :) Looking good, I like the "level building as you walk on neighboring tiles" effect. |
| ||
| The hat was insane? Just the hat Adam? haha ;) |
| ||
| each death is created by however you died - the felines represents "you drowned" more could be added... the "hat" has 20 options of your death. and it could be the "gold" which also has 20 different options! Your hat was: Toasted till crispy declared the winner... etc Your gold was: Partly to blame Found drunk in charge of a panda Thrown out of the youth group... etc |
| ||
| Enough with the pictures Adam - we want a playable demo! |
| ||
| Yes the new shape will fit better in your environment. Good ! |
| ||
| The bridge tile looks like it "hangs in the air". Could you add some ending and starting to it? For longer segments this might be useful. |
| ||
In a traditional roguelike, you need to create your initial character along with stats. So here is a different take on it:   all of the options may not be available at the start - I haven't quite decided yet. Also the rotation speed can be changed, my thought is to have it very fast to begin with? and the result:    etc, etc |
| ||
| This looks good imo, and the possibility to customize the character attributes/skills is a good idea, but personally i prefer to separate the appearance (shape and color) from the attributes/skills In your example, the player would not be able to know how each hat shape, hat color, weapon, will affect the attributes/skills of the final character, and this could be annoying... Another approach, would be to have different kinds of magicka (fire, ice, wind, electric, sound, light, dark, poison, ...) and different kinds of weapons (scepter, spear, sword, axe, mace, ...) and each character (the mage too) would have resistances or sensibilities against some magicka or some weapon. But this is just how i see it... |
| ||
| Good point - maybe i'll add something to give you a clue :) |
   |