Map format for Dune II remakes

[bluehappybyte]

Hi

There are currently multiple Dune 2 remakes developed:

- Dune 2 - The Maker

- OpenDune

- Dune 2 - The Golden Path

- Dune Legacy (which is were I am from)

Some of these remakes have already developed their own map format. My idea is to unify the map format, thus every dune remake can use any map. I investigated a little bit the D2TM and D2TGP map formats but was not satisfied with their solution.

D2TM stores mainly the map and the starting positions. No way to specify units or structures. The format is similar to an ini file but the terrain info is not saved in the typical key/value mechanism of ini files.

D2TGP uses some binary format which I could not find any specification for and is difficult to implement in editors and other games.

Therefore I designed my own map format with the following things in mind:

- human readable

- stores the terrain explicitly (not a seed value like Dune II)

- can store units and structures

- make it possible to have maps which can be played with every house (not just the houses specified in the map like in the Dune II scenario/map format)

- can specify reinforcements

- easily implementable for Dune II remakes

As a result I designed a map format that is as similar as possible to the original Dune II scenario format (scen*.ini files). In fact the original scenario format is a subset of my format with only small changes where necessary.

A first draft of this map format specification can be found at http://www.myway.de/richieland/Dune II Scenario Format Specification.pdf. I implemented it in the Dune Legacy version which I released today.

What do you think about it? What do you think is necessary to be accepted in other Dune II remakes or editors? Up to now it is only a suggestion how we could help map makers and increase the pool of available maps.

The following simple map shows how the terrain info is saved in the ini file and how it is possible to let the user choose which house to play:

[BASIC]Version=2License=CC-BY-SAAuthor=R. SchallerTechLevel=8WinFlags=3LoseFlags=1[MAP]SizeX=32SizeY=32000=%%%%%--~~~~++++++++++~~~~--%%%%%001=%%%%%%--~~~~++++++++~~~~--%%%%%%002=%%%%%%%--~~~~++++++~~~~--%%%%%%%003=%%%%%%%%--~~~~++++~~~~--%%%%%%%%004=%%%%%%%%%--~~~~++~~~~--%%%%%%%%%005=-%%%%%%%%%--~~~~~~~~--%%%%%%%%%-006=--%%%%%%%%%--~~~~~~--%%%%%%%%%--007=---%%%%%%%%%--~~~~--%%%%%%%%%---008=----%%%%%%%%%--~~--%%%%%%%%%----009=-----%%%%%%%%%----%%%%%%%%%-----010=---O--%%%%%%%%%--%%%%%%%%%--O---011=-------%%%%%%%%%%%%%%%%%%-------012=--------%%%%%%%%%%%%%%%%--------013=---------%%%@@%%%%@@%%%---------014=----------%%%@@%%@@%%%----------015=-------O---%%%@@@@%%%---O-------016=-----------%%%@@@@%%%-----------017=----------%%%@@%%@@%%%----------018=---------%%%@@%%%%@@%%%---------019=--------%%%%%%%%%%%%%%%%--------020=---O---%%%%%%%%%%%%%%%%%%---O---021=------%%%%%%%%%--%%%%%%%%%------022=-----%%%%%%%%%----%%%%%%%%%-----023=----%%%%%%%%%--~~--%%%%%%%%%----024=---%%%%%%%%%--~~~~--%%%%%%%%%---025=--%%%%%%%%%--~~~~~~--%%%%%%%%%--026=-%%%%%%%%%--~~~~~~~~--%%%%%%%%%-027=%%%%%%%%%--~~~~++~~~~--%%%%%%%%%028=%%%%%%%%--~~~~++++~~~~--%%%%%%%%029=%%%%%%%--~~~~++++++~~~~--%%%%%%%030=%%%%%%--~~~~++++++++~~~~--%%%%%%031=%%%%%--~~~~++++++++++~~~~--%%%%%[Player1]Quota=0Credits=1500[Player2]Quota=0Credits=1500[CHOAM]Carryall=5'Thopter=5Launcher=5Tank=5Siege Tank=5Trike=5Quad=5Harvester=5MCV=5[UNITS][STRUCTURES]ID000=Player1,Const Yard,256,66ID001=Player2,Const Yard,256,924[REINFORCEMENTS]

[athanasios]

How about extending the terrain info? Currently it is very limited. We could thus create new sprites and add variety to the terrain. This could be done while maintaining compatibility with existing format.

[MrFlibble]

That's a commendable effort, bluehappybyte, but the question remains whether the other developers are willing to adopt a unified format instead of the respective native formats. The problem here is that the remakes you have listed all have very different goals, so to speak, which puts the need of a unified format into question. For example, OpenDUNE so far aims at recreating the Dune 2 engine as closely to the original as possible and porting it to other platforms with some minor tweaks and fixes thrown in, and the original INI format seems to be quite sufficient at this stage of development. Dune 2: The Golden Path, on the other hand, introduces lots of new features, including new terrain types (e.g. sand crags), which makes scenario compatibility with the other Dune 2 projects problematic at best. It is also worth noting that to adapt a unified map format would mean introducing certain changes to the code of each remake, while the benefits of this move aren't very clear right now.

It seems to me that at this point, there's a good prospect for a unified format between Dune Legacy and Dune 2 - The Maker, so perhaps you should contact Stefan directly on the subject. I don't know about the OpenDUNE team's plans for future development (they were hinting at some improvements to the original game), but for now they have concentrated on recreating the Dune 2 engine as their top priority. As for Dune 2: The Golden Path, it is my understanding that Drackbolt prefers working on his own, and besides, the additions that he has introduced in his project make an interchangeable map format quite problematic.

[Nyerguds]

Heh, I've pretty much used this format myself in a game I made for school, years ago.

http://nyerguds.arsaneus-design.com/project_stuff/2006-07/screens1/battle_game_dungeon_lite.txt

http://nyerguds.arsaneus-design.com/project_stuff/2006-07/screens1/battle_game_dungeon.jpg

(note, file format tags are in Dutch)

## Dungeon Maze
x=15
y=14
terrein=kerker
muur=*
held=h
monster=oger,o
monster=imp,i

[map]
map=***************
map=h    **       *
map=     ** *** * *
map=****o** *** * *
map=*       *   * *
map=* ******* o * *
map=*     ***   *i*
map=***** ******* *
map=*   o      ** *
map=* *   ** *    *
map=* *****  *  ***
map=*  i*    *  ***
map=*****i  ** o  *
map=***************

^_^

[stefanhendriks]

Is it me , or is the map format actually much like the original Dune 2 format?

For D2TM I haven't really thought out a format, so I just stored what I needed. I still have to rewrite the loading of maps anyway. I think introducing a 'general map format' is a nice idea. It would be even better if it was extendible, without breaking it for other games.

For skirmish maps however, it would be fairly easy to use. You'd probably only need some starting positions, amount of players, size and terrain tiles. That would basically be enough right?

Last but not least, if you really think it is very easy to use and should be used by other remakes, i'd suggest you write a little class that is able to read such files, and leave spaces in the reading mechanism where the actual game engine should be hooked into. That way all a developer of a remake has to do is fill in these gaps to make it work for his engine.

How do you feel of using XML instead of INI for generalizing a map format?

[MrFlibble]

Last but not least, if you really think it is very easy to use and should be used by other remakes, i'd suggest you write a little class that is able to read such files, and leave spaces in the reading mechanism where the actual game engine should be hooked into. That way all a developer of a remake has to do is fill in these gaps to make it work for his engine.

Yeah, that's definitely a good idea. Also, I think that for a unified format, it would be nice to have the option to either use the original seed map generator (since the code has been deciphered and already implemented in the remakes) or the custom-created terrain. Format subtypes would also allow to make maps interchangeable between remakes that might introduce various non-trivial changes, like new terrain types in D2TGP.

Heh, I've pretty much used this format myself in a game I made for school, years ago.

http://nyerguds.arsaneus-design.com/project_stuff/2006-07/screens1/battle_game_dungeon_lite.txt

http://nyerguds.arsaneus-design.com/project_stuff/2006-07/screens1/battle_game_dungeon.jpg

^_^

Nice oldschool stuff, love it

[Nyerguds]

Oh gods, please no xml... inis are just way easier to edit without needing actual programs for it.

[bluehappybyte]

Is it me , or is the map format actually much like the original Dune 2 format?

For D2TM I haven't really thought out a format, so I just stored what I needed. I still have to rewrite the loading of maps anyway. I think introducing a 'general map format' is a nice idea. It would be even better if it was extendible, without breaking it for other games.

For skirmish maps however, it would be fairly easy to use. You'd probably only need some starting positions, amount of players, size and terrain tiles. That would basically be enough right?

Last but not least, if you really think it is very easy to use and should be used by other remakes, i'd suggest you write a little class that is able to read such files, and leave spaces in the reading mechanism where the actual game engine should be hooked into. That way all a developer of a remake has to do is fill in these gaps to make it work for his engine.

The whole idea of using a format that is as similar as possible to the original Dune 2 format is in ease the implementation of the map format for all Dune 2 remakes (I assume that all Dune 2 remakes support the original format). The most basic implementation would only need to add the reading of the terrain info into their existing scenario reading code (Check if the version key is set and is >1, read SizeX/SizeY and then read all the keys 000 to SizeY. Reading all the terrain cells in one map row is then a simple loop and a switch statement for every cell.

The other big change is the possibility of houses that are chosen by the player. These need some changes to reading the house sections and when reading units/structures (e.g. "Player1" instead of "Atreides").

I don't think there can be any class for supporting map reading despite a standard INI file reader (you can use the one from Dune Legacy if you like).

IMHO skirmish maps are more than just "starting positions, amount of players, size and terrain tiles": What about starting units/structures, reinforcements or the available tech level?

How do you feel of using XML instead of INI for generalizing a map format?

I think it is more difficult for everyone to implement a separate map reading mechanism than to extend the already existing one (again under the assumption that every Dune 2 remake already supports the original format).

Yeah, that's definitely a good idea. Also, I think that for a unified format, it would be nice to have the option to either use the original seed map generator (since the code has been deciphered and already implemented in the remakes) or the custom-created terrain. Format subtypes would also allow to make maps interchangeable between remakes that might introduce various non-trivial changes, like new terrain types in D2TGP.

The suggested map format supports the possibility to use the original seed maps (but only for 62x62, 32x32 and 21x21 maps).

Format subtypes are interesting but might be difficult to support: Either the differences between subtypes are rather small or maps would only work in one Dune 2 remake. Maybe we can specify which features a map file uses and a Dune 2 remake has to check first if it supports all listed features. Something like this:

[MapFeatures]
sand crags = true
armed harvester = true

I left out these additional features in the current specification but added the version key for later extending the format.

[athanasios]

A value to show which game/s the map is compatible with?

[stefanhendriks]

If it is just the dune 2 map format, but extended, then i'd assume you want to add a value where you describe what kind of map it is:

- skirmish

- campaign/single player

- multiplayer (online)

You could probably add some section where you want to add some properties, where you could describe what kind of features are enabled. Features which are game specific. If you can aggregate these features, then you could make a map usable in multiple games, though the playability will differ a bit between the engines.

The reason I came up with XML is just because I work with that a lot on the webservices side. Its a nice markup language, extendible, etc. Compared to INI it is more logically structured imo, and you can make relationships (parent/childs) easier. That is, if you really need it of course.

[bluehappybyte]

If it is just the dune 2 map format, but extended, then i'd assume you want to add a value where you describe what kind of map it is:

- skirmish

- campaign/single player

- multiplayer (online)

Campaigns are not yet covered but one possibility for campaigns would be a pak file like scenario.pak. Some ini files (region*.ini) control the order of the different maps.

Regarding skirmish and multiplayer maps I see no big difference between them concerning the map format. AFAIK other games do not distinguish between them but only put them in different directories.

[Nyerguds]

Personally, in the current proposal, I'd add a [Terrain] header above the actual map info, and allow seed-based maps too. You never know if some remake wants to support them, even if it's just for playing the original missions.

[drackbolt]

Just to weigh in a little here... Actually the idea would be cool with me, and I'm probably less anal than most people think about working alone. ;) The fact is, I code in Blitz, which not a lot of other people know, and I haven't wanted to share source for fear of version splintering (and also to protect a few things I want to use commercially in the future). I'm actually working with a couple other people I trust now, on a few things, including my net library. The only reason I currently use packed data for my maps is to keep the file sizes low. 128x128 maps = 16384 cells, and that's without boundary or other data! The format just happens to be packing routines I already had in place for networking.

However, any such format would also need to be "loose" enough to allow for some minor changes between versions, as MrFlibble noted. Sand crags are a big hit in my circle, and I'm sure others have ideas about hybrid terrain or who knows what. I can easily write a parser to get the data I want as long as everything is uniquely IDed.

[bluehappybyte]

I've updated the format specification with the main addition being a new features section which allows for extensions to the format. Dune2-like games shall check upon loading if they support all needed map features. The new version of Dune Legacy already does this.

Another new thing is the possibility to place special units (Deviator, Devastator, Sonic Tank) for houses that are chosen at the start of the game by the player (and not by the map designer as it is done in original Dune II). This way if the player wants to play Ordos he gets Deviators, and if he chooses Atreides he gets Sonic Tanks. Of course the map designer has to make sure that the balancing of the map is not influenced too much by the players house choice.

You can find the new version of the specification in the Dune Legacy Wiki.

[MrFlibble]

Another new thing is the possibility to place special units (Deviator, Devastator, Sonic Tank) for houses that are chosen at the start of the game by the player (and not by the map designer as it is done in original Dune II). This way if the player wants to play Ordos he gets Deviators, and if he chooses Atreides he gets Sonic Tanks. Of course the map designer has to make sure that the balancing of the map is not influenced too much by the players house choice.

That's a very nice feature to implement, I like it :D It immediately reminded me of Warcraft II map-making where units and structures will be converted to their other side counterparts if the player selects the side that is opposite to the default one in map settings. Obviously it's most useful for multiplayer or skirmish maps, although maybe a campaign with selectable Houses could be made too?