In the context of my student research project I want to develop a random map generator for VCMI. The project has been approved by the university. It has to be submitted at the latest 1st july 2013. Any help regarding map generation algorithms or the h3m map format is appreciated. Yeah, I didn’t want to develop VCMI any further, but things have changed:) The possibility to do a student project about vcmi/rmg gave me the motivation.
The RMG should be handled as a sub-project like libvcmi, battleAI,… I’ll commit to trunk if I got something usable. (which is almost safe and won’t be changed to frequently)
@Ivan/Tow: Is there any good material how the .H3M format is composed of?(I’ve searched a little bit, and you may know already some good material^^, I can always look into the source code, i know^^)
The next step is to compare already developed algorithms(which can be found via the internet) and compare them with the original H3 template-based RMG. That seems to be very nice: www-cs-students.stanford.edu/~am … eneration/. Perhaps it can be adapted to the tile-based terrain of H3.
In the far future I may write a simple map viewer with Qt if there is enough time. This way I can watch generated maps directly in linux instead of copying them to VM/Windows. This should be relatively easy. Some map drawing code have to be moved from client to lib. (then it can used by external apps) This map viewer can be used as a base for a map editor later. (I know far future, so don’t think too much about it…)
Original RMG explained. Some implementation details are missing, but I find it a very worthy read. Even considered coding RMG on my own in the future, glad there’s someone to take the job
I can’t see much reason behind “simple map viewer”, consider using this: mapeditor.org/
Thanks Warmonger! Hmhm I can’t download the ppt file from dropbox. I receive a dropbox error 500 when clicking on the link. Any country restrictions?(don’t know)
What do you mean with the map editor project? Can this editor be programmed to load and render h3 maps?
I think RMG shouldn’t be concerned with map storage format… just fill fields our H3M reader fills.
BTW, I doubt simple map viewer would be simple to do – there is a quite big step of randomization performed after a map is loaded but before it is displayed. You would have to make terrainRect render non-randomized maps. It uses callbacks for FoW etc. – a common piece code for client and map viewer would be a nontrivial task. Moreover, putting terrainRect into lib would make it dependent on SDL. I’m not sure if it would be a good decision. After all server doesn’t need it. Lib is designed to handle game data/mechanics common to lib and server, not rendering of graphics. What about a new dynamically linked library instead?
If this is going to be submodule like libraries maybe you should use not h3m but our internal format directly? This will also remove some limitations that come from it. Rectangular maps were requested already after all
And instead of storing generated maps you can store presets + random seed.
I remember some RMG-related info on Russian forums. Will try to find it.
Not sure if this can work as full H3 editor - objects in H3 are quite complex and from what I see this map editor is oriented towards simple set of tiles.
OK I’ve created a list which steps I want to do. The main goal is to develop rapidly a functional RMG with all parts of generation(terrain, heroes, towns, …). It doesn’t need every feature or produce good-looking maps in the first development phases. The implemention of the RMG will be similar to the original algorithm of H3.
I want to use the internal map format of VCMI. Storing generated maps to H3M is not required for now. I’ll integrate the RMG lib into vcmiclient, therefore a specific RMG generation screen/GUI(in PreGame) is needed (like in H3) => to start/test a generated map. That functionality is experimental and disabled by default. For testing purposes the generated map is fully visible when starting the game.
That’s my current todo list:
I want to separate map loading logic and the object representation of a map(map header,…). It simplifies/separates better the API and different map loading/saving algorithms can be supported. Mappa gets split into: CMap(the value object), CMapService(contains loading, saving, map accessing logic…)
Have a detailed look into the internal map format. Add javadoc comments like I did for the filesystem API. Add remarks which map attributes are required/optional.
Add RMG screen/GUI to vcmiclient/map selection. (buttons may be disabled, don’t have any functionality for now…)
Mock map generation(with terrain, obstacles, towns…). VCMI should start that map (to find out how the internal system works) This is coded in libRMG.
Future steps(i haven’t done much research, but algorithms which I found are similar -> fractal, voronoi polygons):
zones placement: huge amount of portals, including one-way portals. Sometimes - even completely sealed off sections. Algorithm should be able to place zones without large nuber of intersections (try to make zones graph planar). May be one of the most complex part of RMG.
creatures placement: sometimes H3 RMG may place them incorrectly. E.g. artifact guardians may block access to nearby town.
huge maps generation: if zones are not big enough to cover whole map large areas of maps will be filled with blocked terrain
Thanks! That is really nice material. I’ll dive into it later:)
First part of preparation is done. Map loading is separated from the map object. If there are any new bugs when loading maps, please tell me. (I’ve tested several maps/campaigns…)
Second part is to add the RMG ingame screen and some mock map generation for testing. I won’t add a new library for the RMG, code will be placed into /lib/RMG.
I agree that it can’t be fixed completely - not every graph can be made planar.
But RMG places just too many teleporters too often. For example I just generated random map.
Template was 8MM0b, one level map. Connections in rmg.txt look like this:
I think it could be relatively easily and with good results approximated with some kind of genetic algorithm. You can consider placements as permutations.
Of course! But productivity is currently limited due to exams:( The RMG screen and the foundation to start RMG maps is done so far, if you didn’t know it already. Currently I’m busy with creating a mock map. I thought to get this step done earlier, but terrain placement seems to be trickier than expected. Mostly you just don’t recognize it, but the map editor of H3 does a lot of processing here. Selecting the correct view image of the terrain type and adding implicitely terrain tiles if needed. But I got now a theory to map this in a straightforward and easy way. (patterns which indicate which terrain view to use… relatively simple rules -> complex patterns -> rolled out in .json files)
This week are the last exams, so hopefully I get some time over christmas time!
The map generator is disabled by default ATM. There are many things left to do. When a basic map can be played(!) this may be changed. To show current progress in-game you have to set enableRMG to true in one of those files config/settings.json(for Win) or ~/.vcmi/config/settings.json(for Linux):
The RMG code is commited to lib/RMG. There will be some additions to lib/Map in the next days. At this timeline you’ll see progress and source code changes better: sourceforge.net/apps/trac/vcmi/timeline.
There are some updates to announce:) The RMG generates now(with rev3084) a test map with one island and 1 town for every player. Current town & terrain generation has the only purpose to create a valid map. This will be changed later of course. But the rest this means player/team generation, map header(description,…) is fully functional.
There a few known bugs to mention:
correct terrain view handling implemented, but not activated for now(1 part is missing + testing)
starting the map with only 1 player currently crashes(should be fixed in a few days)
1>d:\home\krs\work\programming\vcmi\vcmi\lib\mapping\cmapeditmanager.cpp(256): warning C4018: '<' : signed/unsigned mismatch
1>d:\home\krs\work\programming\vcmi\vcmi\lib\mapping\cmapeditmanager.cpp(288): error C2440: '=' : cannot convert from 'void' to 'bool'
1> Expressions of type void cannot be converted to other types
1>d:\home\krs\work\programming\vcmi\vcmi\lib\mapping\cmapeditmanager.cpp(294): error C2440: '=' : cannot convert from 'void' to 'bool'
1> Expressions of type void cannot be converted to other types
1>d:\home\krs\work\programming\vcmi\vcmi\lib\mapping\cmapeditmanager.cpp(300): error C2440: '=' : cannot convert from 'void' to 'bool'
1> Expressions of type void cannot be converted to other types
1>d:\home\krs\work\programming\vcmi\vcmi\lib\mapping\cmapeditmanager.cpp(267): error C3499: a lambda that has been specified to have a void return type cannot return a value
1>
1>Build FAILED.
The boost random library is header only and exists since boost 1.4.3 if i have looked correctly. The problem is that they’ve renamed the header files sometime between boost 1.4.6 and 1.5.0. Warmonger you have three options. Either you update to boost 1.5.0+ if you want to compile it quickly. The second option would be to fix it by yourself with a macro. The third and probably most convenient option would be to wait till 20.00h(utc+1), then I will have fixed it:)
Krs it seems to be that your compiler doesn’t support the new function declaration syntax for automatic return type deducation or sth. like that is it called:) You have only two options. Either fix it by yourself and adding -> bool after the line 261 right near (bool rslt). The second option is to wait as said above.
