Minirogue: retro dungeon diablo-like

This is kind of a Diablo-like game setup, i though it would be better to upload
this little demo now that still is simple and clean.

The program generates a random old style dungeon with rooms,corridors,doors,lights and stairs.
You can walk around with your avatar with an a-star pathfinding system.
A Permissive field of View Algorithm is implemented to determine visible, invisible and shadowed cells in the dungeon from the avatar perspective
You can change the Field of View behavior mode by pressing F4 (modes 0,1,2, default 2)
Each time you take a stair/elevator, a new random dungeon is generated.

Main classes
World: setup and initialization
Map: generates a random abstract map and prints an ascii representation
can be used alone without dependencies
Grid: initialites Map and generates the 3d grid from the map data
Avatar: generates the avatar and his behaviors
Cam: setup camera control

Support classes

Pathfinder: used for a* searchpaths
Fov: used for Permissive Field of View
Picker: used for mouse picks a collection of usefull functions for loading models,textures,etc…


Left Mouse: Walk to selected cell
Middle Mouse: Rotate camera around avatar
Mouse Wheel: Zoom camera in and out
F1: toggle wireframe
F2: toggle texture
F3: take snapshot
F4: change Fov Mode:
1:hide not visible tiles
2:hide not visited tiles and obscure visited

The program can be run only with python+panda3d, no other library dependencies exist.
About the media required, only a cube egg model and a few textures are needed at the moment,
and are included in the zip package.
Textures are defined in the class, if you wanna change them.

grab it here:

version 1

version 2 (with FOV)


I thought it would be nice to show this as it is, separate from the game code, as an example of a simple 2d graphic user interface.

press f1 to toggle fullScreen on/off, space to insert a new message in the console, letter ‘c’ toggles the console mode simple/extended

question: Anybody could illustrate me on how to make one of the sprites created on this application pickable?

note: by the way, i started on this by modifing the script on this thread, thanks!

i’ll try to keep posting future versions here.

help tips and comments will be appreciated :slight_smile:

That’s a pretty interesting sample. I tried to do something similar myself, but didn’t get very far since I found the square based level structure too limiting for a modern Diablo-style game.

Your code looks very organized, but it runs quite unevenly. For example, in the brick textured areas I sometimes get as low as 7fps yet in others it might be 170fps. I guess you have too many lights for non-deferred rendering or there are too many objects for collision testing. For comparison my own badly written experiments had a couple of dozen animated models pathfinding using A* picked up from the web in similar environments and it still ran at a fairly consistent rate.

Otherwise it’s a very nice sample, thanks for sharing it with us :slight_smile:

Very nice, good work! I like the lighting effects, but as Mindblighter already pointed out the amount of lights make the game really heavy. Reducing the amount of lights, or using deferred lighting would be an option.

Also, note that you need to put "basic-shaders-only #f in Config.prc somewhere otherwise the game won’t show any shaders. This is needed because of the large amount of lights.

Hey thanks for the comments!
yes, this first version it was a bit overloaded with lights etc, just trying diferent little things at the moment.
pro-rsoft, thanks for the basic shader tip, didnt know about it.

i just updated the top of the thread and uploaded the second version, with field of view calculations and the corresponding 3d representation

not showing the whole map at a time is one of the keys to improve framerate, and i think it looks cool to show how dinamically the map is changing to debug the visible and remembered areas from the character eyes, not shure is this is still gonna happend by the end of the process, but now looks interesting to me :slight_smile:
try it out!

About referred light i think maybe could be exactly what i need, is it a difficult thing to implement by someone as dumb as me about panda/3d stuff?
basically i would like to provide some rooms with pointlights of diferent colors. Also more lights should be carried by diferent avatars/characters/monsters…


really amazing and promising stuff here (tried the v2) - looking forward for more!

I just decided to go on in introducing some monsters in the dungeon, and of course, a cascade of unresolved questions has come to mind…

realtime vs turnbased:

should each monster just have a timer and evaluate to do a new action once in a while, at real time? or should every move/action be sequenced in turn sequences?

That is not a trivial question, aldough no clear answer arise yet, for the moment i think the best thing to do would be to try to make an hibrid.

  • realtime free movement until we found some monster
  • when we encounter a new monster the time freezes
  • you and the monster/s move in turn until no more actionpoints or no more monsters visible

does that sound good?

the thing is i would like to provide this crawler with some tactical issues and a pure realtime approach would derivate in more hack’n’slash than tactical.

if someone has any though about it feel free to throw your opinion!

turnbased! turnbased a-la Fallout!
If you’ll follow that choice I’ll offer you either a little help on some code or whatever you need, seriously!

the best thing i can recommend you is playing different types of games in this genre. i bet you have played some rogue-style games already, but once you reached the point in a game development you havent really observed closely in other games, you can learn a lot by playing them again.

yes, really i think realtime is fun for a while but soon can get you tired of repeating the same actions at high speed.

In fact my first approach goes in the direction of the fallout series, or the jagged aliance series, etc, but i want to find a key element in the mechanics that makes the experience a bit more fluid, not having to micromanage lots and lots of details each turn.

The time approach from classic roguelikes also is interesting, everyone executes a movement simultaneously in the same turn,having each character diferent time related speeds,etc…

I feel more easy for now the first approach. Now the question is:

should i divide humans and monsters in 2 teams and execute team1 turn first and then team2 turn?

should i provide characters with a initiative number and execute turns in order of the initiative?

well, just thinking in loud voice a bit.

astelix, your help would be greatly appreciated if you feel like doing something.
how about programming the actor stuff? :wink:
i have to get into that but now experimenting with the game mechanics absorbs all my time.

haha I know what you mean :slight_smile:
ok, deal - you may send me details on what you got in mind by PM or we can keep going here, as you wish.

mhm with this kind of help this experiment may have a chance to grow a little more :slight_smile:
ok i’ll send you details by PM.

updated with the first version of the game 2d gui.

Very cool. Kinda sounds like a cross between Diablo (as you mentioned) and Neverwinter Nights (NWN like 3d view).

Pesonally, I’d love to see what you guys can do with realtime combat. Since you mentioned teams, I’m not sure if this means multiple players or not. If multiple players and they can be in different areas in different combat I’m not sure how well that can be done with turn based combat.

mhmm will se how evolutionates.

one of the realtime combat mechanics that caught my eye was the Onimusha series for ps2, the way of managing targeting/facing+bloking+attacking+combos was really adictive,tecnical and fun.

but for this little thing, i supose it would be more easy for now to have everything under some kind of turn control, and yes, maybe managing a team of characters who can help each other

the point is to find a nice balance between easiness of use and a lot of micro-options that you can design as a behavior background.

I just introduced some dumb monsters in the 3rd version im doing now, and the whole thing is getting quite better!

I don’t think real time combat necessarily equals simplistic repetitive combat. Diablo I/II are some of the simplest games and combat is fairly fast and repetitive, progressing to new things as you level up. It’s also one of the funnest games I’ve played. MMORPGs such as Age of Conan are also real time, but can be far from simple.

Not my game, I’m not telling you how to do it or even requesting it one way or another. I’m just suggesting that real time combat might be the way to go depending on the type of game you want to make (team play to me sounds like multi-player).

After typing all that I realized I may have completely misunderstood what you mean by teams. If you are referring to the player controlling a team of characters such as in Heroes of Might and Magic (sorry, the only group turn based game I’ve ever played), perhaps something like a party of adventurers that you move around as a group and go into combat against a single group of 1 or more enemies, then turn based combat just might be the way to go.

This looks great, i plan to make turn based game (fallout, and jagged alliance like), but in a different setting (close future) and with more complex game mechanics, tons of weapons and other sorts of items.

The screenshots and packages are all gone, leaving dead links. I found the Minirogue project on SourceForge, but it seems to be no longer “simple and clean”, as snaptothegrid originally posted. Anyone have a copy of the demo provided on this thread saved?

I’m actually going to upload it on SF as it was before to be totally rewritten - do a checkout in an hour starting from my post time for the branch “pilot1_r137” on the repository to have it.
By the way is long time I aint fresh news from snaptothegrid and actually I’m on my own rewriting the engine for the third time trying my best to have it clean and fully object oriented, about to be “simple” that’s not guarantee but I’ll try to comment it AMAP.

Awesome. Thanks for that. :slight_smile: