Open pennomi opened 7 years ago
@pennomi I would warmly welcome the first approach you mentioned, with adding a hook in the engine for allowing external processes to generate maps and return a file path. This would be absolutely great, allow a lot of flexibility and still keep the engine simple. The principle of separation of concerns is powerful, and should be leveraged when possible.
I would much rather see that the first approach was taken, rather than requiring the map generation tool to be written in LUA to integrate with the engine.
If you wish to flesh out the command line interface in more detail, I'd be very happy to discuss those aspects.
Cheers /u
For reference, the Random map generation issue tracked by flare-engine-next is at dorkster/flare-engine-next#23.
@pennomi I'll copy over your idea to that idea to that issue, since I really think you may have found a good approach to solve this without making the engine too complex : )
The collision was fixed ? nice system, gratz 👍
Make a default number of maps for each game area, which are randomly selected from the game engine, and saved. This is not a procedural mapping system, but in my opinion it is much better, easier to manage, and it works well in addition to ensuring a variety of feel for the player. I think it's a good idea.
The recent comments on another thread got me thinking about procedural map generation. (Specifically where @clintbellanger mentions that it makes sense for external generator tools to be a separate codebase from the engine because each tileset is unique in what rules it would have to follow.)
One thought is that we could provide a hook in the engine to subprocess out to an external generator program. That would provide a whole lot of flexibility to the implementer of the program because it could be written in any language and could potentially be packaged as a mod. We'd just need to build out a consistent command-line interface with inputs and outputs, so it should be pretty simple. (For example, the program would take in some sort of
map_id
andgame_seed
and would return the newmap_filepath
) The downside is that there would be no way to guarantee the dependencies to run the subprocess exist on the target system.A secondary thought would be to provide a very low-level LUA interface for generating maps and build that into the engine directly. It could provide tileset parsing, asset loading, and simple functions to add each tile/event/creature/etc. Seems like this would be a lot of work though. Plus not everyone enjoys LUA.
Feel free to close this issue; I highly doubt random maps should be built into the v1.0 engine. Just wanted to get my thoughts down and see if anyone was thinking along the same lines.