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: http://www-cs-students.st...ap-generation/. 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...)

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?

@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^^)

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.

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.

Problems with H3 RMG:
- 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

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!

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum