Hello!

I've always been interested in random /  / procedurally map generation.  A major feature in rogue likes (see NetHack).
And since I've always loved Link to the Past, I'd thought I'd try to merge the new genres together.
Yeah, not easy.

Lacking any real direction, I just jumped in and started hacking on stuff.

My first change is supporting strings as tile ids.
Its backwards compatible so integers (in existing quests and output from quest editor) will still work.

Git Repo: https://gitorious.org/red-solarus/red-solarus
Please remember to use the red-solarus branch!

Note that I haven't used C++ in a very long time and only the second time I've used Lua so I may have made some mistakes.

My next task is to actually play ZSDX to get a better feel for the engine (no really).
Then to build another sample quest with multiple maps, still static.
And so on.

Thanks!

[Christopho]

Hi!
String tile ids are a nice change. It will help users modify tilesets more easily without breaking maps. The hard work is to update the editor to support them though

To make dynamic maps, you can use the file API. It allows you load data files from the saves directory instead of from the ususal data directory.

This is certainly an interesting idea! I'm starting an MComp (like a masters) degree in Games Computing in September, and seeing as most of my research has been around procedural content generation I wanted to continue with it. I was looking to explore how to use searched based procedural content generation in order to evolve my levels, and perhaps how to adapt them for individual players. I was considering Solarus as a platform to implement and test my ideas on, and I find this post!

Hey, hkeeble!
If you want, just send me your pubic ssh key and I'll set you up in the red-solarus project.
I'll probably work at a much slower pace than you'll need for your research but maybe it will be useful.

At the moment I'm working on the editor changes that Christopho suggested.  Should be finished in a week or so.  Real life =)

From what I seen so far, it will be easiest to start with plain old rooms and hallways and spawn monsters based off of the players health level. But don't let me stop you.

tinyweldingtorch at gmail dot com

[Christopho]

tinyweldingtorch: I merged your change in a branch string_tile_id: https://github.com/christopho/solarus/tree/string_tile_id
I simplified some code, in particular I removed unnecessary int to string conversions from Lua.
And I started to update the editor in that branch. The editor works with string tile ids now. The GUI does not allow to change them yet (it continues to generate auto-incremented ids). But I think it will be done very soon, possibly tonight. Stay tuned!

Hey, hkeeble!
If you want, just send me your pubic ssh key and I'll set you up in the red-solarus project.
I'll probably work at a much slower pace than you'll need for your research but maybe it will be useful.

At the moment I'm working on the editor changes that Christopho suggested.  Should be finished in a week or so.  Real life =)

From what I seen so far, it will be easiest to start with plain old rooms and hallways and spawn monsters based off of the players health level. But don't let me stop you.

tinyweldingtorch at gmail dot com

Awesome! I'll send an email your way soon. I'm unsure of the exact approach I'm going to be taking at the moment, as I've not had a chance to really delve into the engine, but doing so slowly in my downtime. Seeing as the engine appears to have a strong Lua binding and data files for maps, it may be that actual changes to the engine source for what I wish to do would be very limited, but again I'm unsure. Either way, I'd like to contribute to the red-solarus branch where I can 

[Christopho]

tinyweldingtorch: it's done. String tile pattern ids are now supported in the master branch. They can be changed from the quest editor.

Hey Christopho!

If I said I wanted to get rid of project_db.dat what would you think?

At the moment I have to define each map in there.  Works great for normal Zelda games but a fair number of rogue-likes don't have an explicit number of maps.
Some are infinite and will just keep generating new ones the further you go down the dungeon.  Others a random range, for example there will be 5 to 10 levels in the game.  And so on.

Also I would say, just let the file system keep track of files.  You already have a sprites directory structure, why do you need to list out each of those sprite files in project_db.dat?

Anyway, just wanted to get your thoughts on the matter.

[Christopho]

This is a good remark. I don't love project_db.dat either for various reasons. Sometimes it is complicated to keep it in sync with the actual files, for example when you copy resources from another project. It is also a source of conflicts when several people create different maps/sprites/etc in the same project at the same time.

Still, it is useful to maintain a list of resources. In some of my games, I have .lua files inside the map folder that are not maps but scripts that maps can call (but okay, there is no .dat file with it in that case so the auto-detection could work).
Also, I wouldn't like to have to browse subdirectories recursively to find resources. The engine would need to do so, as well as the editor and various tool scripts like data files converters.
project_db.dat also gives a user-friendly name to each resource. However, now that maps and tilesets are identified by strings instead of integers, this is not so important as before.

So, to conclude, I have mixed feelings about project_db.dat. I might remove it in the future, yes.

Now in your use case, you can add maps dynamically into the savegame directory and forget to add them to project_db.dat. These maps will work in the engine, but not in the editor and other tools. Which is not the ideal solution, I agree.

If you're still interested in randomly generated dungeons and rogue-like features, check out this post:

http://forum.solarus-games.org/index.php/topic,404.0.html

which describes the first release of our Solarus project.