Show Posts
286
Programming / Magic & Mayhem Engine Open Source Clone
« on: August 30, 2015, 04:07:37 pm »
Hi, folks!
Besides X-COM, there is another game using very similar and powerful isometric engine (among the most advanced to my knowledge) by the same designer (Julian Gollop). The game is Magic & Mayhem, based of Lords of Chaos - an old Amiga game.
The game has a lot of issues, due to the publisher interfering with developers and enforcing the usual christmas deadline (November release date speaks for itself). Running the game modern computer is pain too (although I've succeeded running it on OSX with PlayOnMac, after disabling opengl). Maybe now is the time to fix it and bring back to life as an open source project?
Most game data resides as open text in *.cfg files, but a some things are hidden under binary and few *.cfgs are encrypted, which is solved with waiting for the engine to decrypt them and then just dumping them from memory.
Tinkered a little with Magic & Mayhem engine (without using any debugger) gets some knowledge on how to decode binary data (I've successfully decoded all sprites), but unfortunately not the most interesting thing, which is the map encryption algorithm, required to get factual knowledge of how maps are stored and rendered.
Algorithm decoding CFG files would be nice too, because distributing decoded files would be copyright infringement.
Does anybody know how to decode *.map files?
I'll share with you my Magic & Mayhem engine facts and guesses:
- All map tiles are 64x48 (with light source coming from the southwest), where 16 pixels are used for height. There are no wall or floor tiles, like in X-Com style engines.
- Map is drawn in layers, using either priority queue or zbuffer.
- Water is procedurally generated between layers, as specified by `WaterLevel` variable in level files.
- Creatures have width/height size (TileSizeXY) and TileHeight, which determine their blocking profile and when they drown (water level gets past their height).
- Creatures move on grid lattice (directly using mapping to 64x32 tiles tops), like in older RTS games (Warcraft and Starcraft). Creatures can move only 8 directions, which is especially noticeable with flyers, where bat flies in zig-zag.
- Non-creature game objects (like trees and doors) are made completely out of tiles. Quote from doors.cfg "Terrain tiles need to be assigned a door number, the tile numbers that make up the door are listed [...] along with the animations for the door opening and closing"
- Game maps files (*.map) inside ./Realms appear to be compressed using the same algorithm as the txt files inside of ./CFG/Encrypted folder. The *.nod files are not compressed, but I guess they hold something like precomputed movement maps for AI.
- Due to the rhomboidal minimap shape, the map format appears to be rhomboidal too. So the Y-axis is diagonal to the viewport (like in X-com), as opposed to the vertical successive Y's, in games like Civilization II. The map is also toroidal, meaning that its west edge transitions into it's east edge, Pacman-style ( https://en.wikipedia.org/wiki/Wraparound_(video_games) )
- The map drawing algorithm can be copied from: https://sourceforge.net/p/pentagram/code/HEAD/tree/pentagram/trunk/world/ItemSorter.cpp which should give correct occlusion for a world made of arbitrary bounding boxes. I.e. projectiles and spells like tornado will render correctly.
- the lightmaps are implemented by simply altering the tile and creature brightness. Fog of war appears to be more complex.
- The sprite format used for creatures and tilesets is described in https://github.com/saniv/sau/blob/master/src/fmt_spr.c
- "It was designed first as a multiplayer game and we sort of retrofitted the single-player experience, so it didn’t work so well unfortunately, for me." -- Julian Gollop
Besides X-COM, there is another game using very similar and powerful isometric engine (among the most advanced to my knowledge) by the same designer (Julian Gollop). The game is Magic & Mayhem, based of Lords of Chaos - an old Amiga game.
The game has a lot of issues, due to the publisher interfering with developers and enforcing the usual christmas deadline (November release date speaks for itself). Running the game modern computer is pain too (although I've succeeded running it on OSX with PlayOnMac, after disabling opengl). Maybe now is the time to fix it and bring back to life as an open source project?
Most game data resides as open text in *.cfg files, but a some things are hidden under binary and few *.cfgs are encrypted, which is solved with waiting for the engine to decrypt them and then just dumping them from memory.
Tinkered a little with Magic & Mayhem engine (without using any debugger) gets some knowledge on how to decode binary data (I've successfully decoded all sprites), but unfortunately not the most interesting thing, which is the map encryption algorithm, required to get factual knowledge of how maps are stored and rendered.
Algorithm decoding CFG files would be nice too, because distributing decoded files would be copyright infringement.
Does anybody know how to decode *.map files?
I'll share with you my Magic & Mayhem engine facts and guesses:
- All map tiles are 64x48 (with light source coming from the southwest), where 16 pixels are used for height. There are no wall or floor tiles, like in X-Com style engines.
- Map is drawn in layers, using either priority queue or zbuffer.
- Water is procedurally generated between layers, as specified by `WaterLevel` variable in level files.
- Creatures have width/height size (TileSizeXY) and TileHeight, which determine their blocking profile and when they drown (water level gets past their height).
- Creatures move on grid lattice (directly using mapping to 64x32 tiles tops), like in older RTS games (Warcraft and Starcraft). Creatures can move only 8 directions, which is especially noticeable with flyers, where bat flies in zig-zag.
- Non-creature game objects (like trees and doors) are made completely out of tiles. Quote from doors.cfg "Terrain tiles need to be assigned a door number, the tile numbers that make up the door are listed [...] along with the animations for the door opening and closing"
- Game maps files (*.map) inside ./Realms appear to be compressed using the same algorithm as the txt files inside of ./CFG/Encrypted folder. The *.nod files are not compressed, but I guess they hold something like precomputed movement maps for AI.
- Due to the rhomboidal minimap shape, the map format appears to be rhomboidal too. So the Y-axis is diagonal to the viewport (like in X-com), as opposed to the vertical successive Y's, in games like Civilization II. The map is also toroidal, meaning that its west edge transitions into it's east edge, Pacman-style ( https://en.wikipedia.org/wiki/Wraparound_(video_games) )
- The map drawing algorithm can be copied from: https://sourceforge.net/p/pentagram/code/HEAD/tree/pentagram/trunk/world/ItemSorter.cpp which should give correct occlusion for a world made of arbitrary bounding boxes. I.e. projectiles and spells like tornado will render correctly.
- the lightmaps are implemented by simply altering the tile and creature brightness. Fog of war appears to be more complex.
- The sprite format used for creatures and tilesets is described in https://github.com/saniv/sau/blob/master/src/fmt_spr.c
- "It was designed first as a multiplayer game and we sort of retrofitted the single-player experience, so it didn’t work so well unfortunately, for me." -- Julian Gollop