Long answer: This is just a hobby project, and development simply takes a long time. There is no roadmap or milestones, just a little bit of long-term planning and a whole bunch of features we'd like to add, plus a never-ending list of bugs to be fixed.
Right now, development is concentrated purely on the DOOM family of games. Other games are not even on the radar at the moment.
That is because we want the generation of DOOM maps to become as good as possible, ironing out all the issues with the new shape grammar system, and getting the code to be really clean, stable and robust. Only when that is achieved does it make sense to begin to target other games, having a solid foundation to build upon.
Turning to the question of which games to support: the most likely candidates will be games which are based on the DOOM engine, such as Heretic and Hexen. Games like Wolfenstein-3D and Blakestone are simply too limited, and actually make me nauseous when playing them, so there is no desire to work on them. Games released after the year 2000 or so, like Doom 3, have map formats which are too complicated or too poorly documented, making it almost impossible to write the necessary CSG code.
Also some games have a style of gameplay which is differs from the find-all-keys & kill-all-monsters style which you see in DOOM. So games which have extensive RPG elements, or a game like Thief where sneaking around is a primary concern, would probably require a lot of new logic to support them well.
(See also this forum post: Possible Games)
1. Visplane Overflows: when too many "visplanes" are drawn, the game suddenly exits to DOS with an error message. This is very harsh on the person playing. It is not possible for OBLIGE to guarantee that the number of visplanes stays under the limit at all times (except to make extremely dull maps).
2. Save Game Overflow: when a map has too many things (entities) in it and the player tries to save the game, it exits to DOS with an error message. It would be difficult to ensure the number of things stays under the limit (e.g. removing monsters or pickup items would compromise the gameplay of the map).
(Note: the above also applies to Chocolate-DOOM, which intentionally keeps those limitations in place)
The other reason is the nature of these maps. With single player or co-op, you will play the map once and move on to the next. It doesn't need to be a masterpiece to be fun.
However with DM or CTF you usually play the map for long periods of time, learning the layout well so you can concentrate on tactics. Hence the layout and flow of the map is absolutely critical, and it should be nice to look at too since you are spending a lot of time in there. Generating maps of sufficient quality is much harder to achieve.
One possible way would be to generate the name first, before the map itself, then check the name for various keywords to decide what elements to use on the map. For example, if the name mentioned "Lava" then force the liquid areas in the map to use the lava texture. The problem is that this can conflict with the settings chosen by the user. So if the user has set "liquids" to NONE, then they're gonna be annoyed when they discover a level with lava in it.
That leaves the only other possible way: generate the map first, remembering what elements were used, then generate the name of the map, and somehow make the components in the name match the actual elements used. For example, if the liquid of the map was lava, then we should favor names containing "Lava" and skip names containing "Water" or "Nukage". It is not clear how to achieve that with the current naming system.
Instead of that, we are looking for a method to generate levels that is as simple as possible while still producing very good results, and it seems the V7 system can achieve that.
Boss maps usually have special layouts or special requirements, like killing all the Barons in E1M8 of DOOM will lower a wall, so the code will have to support all those special things, and it will be a lot of work.
games/doom/monsters.lua
file,
without having to compile anything.
OBLIGE will load your changes the next time you run it.
Compiling Oblige.exe is fairly complicated, and we simply don't have the time or inclination to teach complete strangers on the internet the basics of compilers, makefiles, libraries and all that stuff. Sorry -- it's nothing personal,
If you are a programmer and are running Linux, then the INSTALL.txt document in the source package has some information to get you started.
So please don't nag us to implement something. If you have a request and ask nicely, we will definitely consider it.