To speed things up, I wanted to auto translate these bundles, and then have others look over and refine the translations later.

Looking at what already existed, I was not excited.

• I did not want some heavy weight application.
• I found some simple auto translation tools, some free-ish, some pay-per-say. But they did not support java resource bundles.
• I did like translate shell a lot, but it needed integration into the java resource bundle ecosystem
• Very few tools supported maven
• Nothing “just worked”

So I created a maven plugin (SpeakingDuck) to translate resource bundles. SpeakingDuck will use whatever translation tool you configure it to run with.

Find it on github:   https://github.com/busyDuckman/speakingDuck

or install via the Maven Repository, or via reference in your pom.xml.

The following pom.xml will cause German, Chinese, Spanish and Russian resource bundles to be maintained (updated for new keys) every compile.

<build>
    <plugins>
        <plugin>
            <groupId>com.busyducks</groupId>
            <artifactId>speakingDuck-maven-plugin</artifactId>
            <version>0.9.7</version>
            <configuration>
                <call>trans -b :$CALL_LANG $TEXT_ESCAPED_QUOTED</call>
                <translations>
                    <translation>
                        <bundlePattern>./src/main/resources/generalText_$FILE_LANG.properties</bundlePattern>
                        <sourceLang>en:en</sourceLang>
                        <destLangs>de:de, zh:zh, es:es, ru:ru</destLangs>
                        <replaceExistingKeys>false</replaceExistingKeys>
                    </translation>
                </translations>
            </configuration>

            <executions>
            <execution><goals><goal>translate</goal></goals></execution>
            </executions>
        </plugin>
    </plugins>
</build>

The translations are generated via translate shell (because of the call “trans -b”), you will need to install translate shell yourself for this to work.

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.

Resources:

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

Status:

• 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

Tools:

• Xeen Utilities
• MM3 Dumper

Mods:

• respawn mod

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

Xeen modding

• MM3 modding page: http://jeffludwig.com/mm3/resources.php

Xeen Cluebooks

• MM3: http://www.abandonia.com/files/extras/25850_game_extra_1.pdf
• WoX: http://www.abandonia.com/files/extras/26962_Extra%20document_Cluebooks.zip

MM3 Releases

• DOS: http://www.abandonia.com/en/games/1035/Might+and+Magic+III+-+Isles+of+Terra.html
• Amiga: http://www.lemonamiga.com/?game_id=3142
• SNES

WoX Releases

• Dos: http://www.abandonia.com/en/games/482/Might+and+Magic+IV+and+V+-+World+Of+Xeen.html
• Mac:
• PC-98

“Vintage” Computing:

• File Formats from the C64: http://petlibrary.tripod.com/formats.htm

Reference Code

• LHZ https://github.com/rwfpl/rewolf-mm3-dumper
• Xbr

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.