OpenXeen is a game engine rewrite I have been working on for Might and Magic III, IV and V . It’s opensource and still under development.
Currently it brings up monsters, objects, and most of the outdoor environment.
- Git: here
- Wiki: here
- Development Blog: here
- State of openXeen features
- Interested in contributing
- Xeen development related links
- The xeen wiki (the groundwork reverse engineering project that OpenXeen stands on top of)
- Software is not ready for release.
- At the moment it can:
- Parse the cc files and open some graphics and audio files
- Parse some map info
- Create proxies of all files in cc files.
- Display a simple rendering of some xeen components. NB: First run will take some time, proxy files are being created.
Might and magic III (Isles of Terra) support.
I have got the MAMIII GUI up, and decoded some sprites. Not much more to show yet.
I am by no means a proficient at reverse engineering software, however I wrote up a quick primer on how I was using the cpu logs generated by the dosbox debugger, to recover some MM3 data.
Xeen Info Gneral:
- Xeen Wiki: http://xeen.wikia.com/wiki/Xeen_Wiki
- CC file format: http://rewiki.regengedanken.de/wiki/.CC
- MM3 CC file: http://rewiki.regengedanken.de/wiki/MM3.CC
- MM3 CC file LHZ compression: http://blog.rewolf.pl/blog/?p=1202
- MM3 modding page: http://jeffludwig.com/mm3/resources.php
- MM3: http://www.abandonia.com/files/extras/25850_game_extra_1.pdf
- WoX: http://www.abandonia.com/files/extras/26962_Extra%20document_Cluebooks.zip
- DOS: http://www.abandonia.com/en/games/1035/Might+and+Magic+III+-+Isles+of+Terra.html
- Amiga: http://www.lemonamiga.com/?game_id=3142
- File Formats from the C64: http://petlibrary.tripod.com/formats.htm
Other WoX Engines:
- DeamMasters Xeen engine in scumvm https://github.com/dreammaster/scummvm/tree/xeenand https://github.com/roguevm/roguevm/find/xeen
Articles on the History of MaM
- 5 pages covering the series:http://www.hardcoregaming101.net/mightandmagic/mightandmagic3.htm
Reverse Engineering Dos Games:
- A good primer http://wiki.scummvm.org/index.php/HOWTO-Reverse_Engineering
- Dosbox 0.74 debug build: http://source.dosbox.com/dosbox-74-debug.exe
- Bridging IRA to dosbox https://github.com/wjp/idados
- Driving the dosbox debugger: http://www.vogons.org/viewtopic.php?t=3944
Code Audit, first release – v0.1.0 alpha
(From my dev blog)
With this first release I wanted to take stock of where the code is at, where I am heading and what my time is being spent on. I have a job and a family, so openXeen is largely coded in at night or when I can grab 5 minutes. This forces me to code in a manor ‘resistant to interruptions’ (finish one logical area at a time, use a fully thought out architecture).
What I also need to do Is audit how much time I spend on what. Which is where this line of code by package breakdown comes into play. It breaks my 8.8k lines of code down, telling me where my effort has been spent. I aim to update this graph at every delivery milestone. What I learnt:
- 1/3 of the code is concerned with reading and loading files contained in the .cc archives (reds)
- 1/3 of the code is ‘toolbox code’ (oranges), stuff that is not relevant to xeen, and ideally would have been provided by java or a 3rd party library.
- 1/6 is in game mechanics (blues), arguably this is an over investment in mechanics early on. But I am prioritising having a ‘game’ by the end of the year, not a tech demo.
- 1/6 is in rendering (greens). The rendering code has been kept as simple as possible. I love to write rendering engines, and know this is a trap. You spend far too much time on rendering ‘goodies’, then your engine was built without respect to the actual game (because the game did not exist yet) and you have nothing to show in your render. Your’e exhausted, and sometimes coded into a corner.