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.




  • 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.



Related Links



Xeen Info Gneral:

Xeen modding

Xeen Cluebooks

MM3 Releases

WoX Releases

“Vintage” Computing:

Reference Code

Other WoX Engines:

Articles on the History of MaM

Reverse Engineering Dos Games:



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.