Back in high school, Phil wrote a simple strategy game called “Battle of the Masters” on an old (well, not at the time) TSR-80. This game was almost chess-like in its simplicity. Two armies fought to defeat one another over a battlefield of simple obstacles. The graphics were crude but the idea was there, along with some familiar unit types.
Let’s jump forward a bit now; it’s about 2000 or 2001 at this point. Phil sends Louis an email with a link to a TSR-80 emulator and a bunch of games. These were all old games Phil had made back in high school. Louis was beside himself, and in his glee he noted the beautiful simplicity of “Battle of the Masters.” Talk was talked and “Battler” was born.
That’s right, “Battler,” not “World to Conquer”; we’re not there yet.
Six different unit types were completed for Battler, many of which were redone for WtC. It was basically the same game as its more modern counterpart but played instead on an isometric grid of squares. It was pretty fun, but then attentions wavered and other projects took the spotlight. Battler was never completed—until now.
After the success of their GBAX2003 entry Kunoichi Yami, the Northern Bytes team decided that competitions were a great way to force the completion of a project. And thus was it decided that Northern Bytes would participate in the 2003 uDevGames Contest. But what to do?
With a few ideas bouncing around, including one for a total “Advance Wars” rip-off, it was decision time. After careful consideration, it was decided that Battler would make a great entry. Unsatisfied with the original graphics, Louis sought to give the game a more refined look. A hex system was chosen to replace the problematic squares and from there, a whole new game was born: “Battler 2,” later renamed “World to Conquer.”
The Tools
We chose to build World to Conquer as a Carbonized application using Metrowerks CodeWarrior, partly due to familiarity with that particular integrated development environment, but mainly because our lead programmer was too lazy to purchase a new iBook with specs sufficient to run Mac OS X.
On the plus side, this ensured that we could reach as big a potential audience as possible—the game runs well under Mac OS 9, and doesn’t have particularly demanding CPU or memory requirements. These are big pluses for a contest (like uDevGames) that uses public voting, especially since World to Conquer is primarily a gameplay-driven title anyway.
Our programmer made sure to keep the bulk of World to Conquer’s source code and external tools portable, using a platform abstraction layer that was implemented both for Macintosh and Windows. Being able to test on both platforms made it easier to track down tricky bugs. It also made our project accessible to team members that weren’t fortunate enough to own a Macintosh computer.
We used Apple’s QuickTime for music on both the Macintosh and PC ports. This technology lent itself well to playing compressed AIFF files, which we selected as a good compromise between file size and quality. MP3s sound better, but were much larger. MIDI was briefly considered, but rejected as too limiting for our talented musician.
Our graphics code makes heavy use of translucency for special effects and highlights. That part of our code isn’t particularly efficient (the fades during the splash screen sequence are particularly sluggish), but we were able to eliminate in-game speed hits thanks to a custom graphics manager that divides the screen into a grid of 16×16 chunks, and only bothers to repaint dirty (changed) areas. The screen is represented internally as a hierarchy of graphical elements, allowing us fine control over layering and placement.
We used the well-documented BMP and GIF file formats for our graphics resources, and uncompressed WAV files for sound effects.
Probably the hardest part of this project, from the programming perspective, was creating a reasonable AI for the computer opponent. The gameplay doesn’t lend itself well to a traditional “depth first search” because of the sheer variety of moves and randomized attack effectiveness. We made the problem tractable by breaking down the computer behavior into a smaller class of objective problems: finding shortest paths on hexagonal grids stocked with obstacles, evaluating potential attack options, minimizing “friendly fire,” and even some rudimentary cooperation between computer-controlled units (e.g. for computer-controlled healers).
Fortunately, when we decided to switch to canned scenarios, this took some of the pressure off having a “flawless AI.” You may notice that many of the scenarios by design feature large computer armies vs. a relatively small group of player-controlled units. This gives the computer army an artificial advantage, to help balance out the intelligence of a human player. In some respects, this may actually make the game more fun. If the computer were perfectly intelligent, a human would struggle to even draw. As things stand, there’s fun to be had in using superior intelligence to defeat sheer numbers. A planned two-player option to the game will make things more interesting for folks that want to have a more even-handed battle of wits.
Gameplay philosophy aside, the computer AI has some major flaws we hope to address in the future. Specifically, it does not go out of its way to protect computer “leaders” nor does it more aggressively pursue player “leaders.” The computer AI also does not yet have any knowledge of goal-based scenarios.
Graphics were made primarily in Photoshop, though it’s been rumored that Richard dabbled in the use of Painter in his attempt to find an easier way to draw the base black outlines for sprites. Painter was used to make the title background as well.
The music was done using Finale 2003 for notation, Pro Tools LE for playback, and a Yamaha MOTIF as the primary (and only) sound box. The original sound proposal called for a series of five themes-encompassing both melody and orchestral texture-that would be executed in a wide variety of styles. After the game concept was revised the in-game motivation for the five themes no longer existed, so the team adapted much of the music that had already been composed for the new game concept, and Ben finished the rest of the music to new parameters. Ben was pleased with the final product, though he admits he is still learning all the nuances and tricks of the MOTIF instrument. With a little more time to devote to it, he would have developed the various themes more fully and touched up some sound-balance issues.
Sound effects were mostly made from arrangements of original and free sound clips. The original sounds were recorded on a digital video camera, being the best mic that could be found at the time. The sounds were all pieced together in Sound Effects and Sound Studio.
An indispensable tool to the creation of WtC has been, of course, the level editor developed along with the game. Since we do plan to release it to the public, it has been kept relatively easy to use and has made mission creation a breeze.
The Making of WtC
Much of the game’s design was already in place thanks to it being a sort of pseudo sequel to a previous project. The guiding principal of the game never changed, i.e. a simple strategy game. That was the goal, to reproduce the elegance of Battle of the Masters. Every unit was to perform but one action, every unit would be dramatically different. And everything would be done with the mouse, no menus.
Though the core of the gameplay never changed, the game’s focus took a huge turn when it was realized that time would not permit the creation of the conquering aspect that was originally intended. That’s when the non-combat aspect of the game switched from a freeform Risk style to a challenge-based mission style. This change greatly affected the focus of the game, as the creation of missions became a new and interesting challenge to take on.
Graphic design was done first and foremost on paper. Come to think of it, most of the design was. Louis spent much time bouncing ideas off friends and classmates in order to emerge with a tighter sense of the game and the final graphical look.
A constant exchange of resources and products between Louis and Phil eventually led to the contest complete version of World to Conquer that made it here.
What Went Right
Game design and Gameplay
First and foremost among things that went right was making a complete, playable game; having a deadline to stick to had everything to do with it.
Sticking to a simple battle plan also proved to be a life saver. With the battle engine up and running in no time, it was possible to concentrate on the nit and grit of content.
Switching to the mission based game play was also indispensable to the game’s completion, since the Risk style conquest part would have involved the creation of a whole other game on top of the existing battle engine.
Polish
And finally, the feel: the essential simplicity and concept of the original was conserved brilliantly in the final product.
What Went Wrong
Interface Design
Not enough time was spent designing and implementing an interface, so the game ended up not really having one as far as menus go.
Also, we weren’t able to fit in all the features we wanted, such as save and load and army color edit.
Unfinished Graphical Refinement
Although all the graphical content was completed, the implementation was never fully achieved. This is unnoticeable to the player, but some of the effects were designed to play out in more dramatic ways. Time constraints once again didn’t allow the changes to be made.
Few Unit Types
Three more unit types were originally designed but had to be cut because of lack of time.
In Conclusion
If anything, this has only strengthened our resolve to continue making games and having fun doing it. Barring time constraints, this project went off without a hitch. With no major bugs, no huge unforeseen delays, it was smooth sailing. We had a blast making the game and learned a whole heap.
RTS,SNES,CodeWarrior,Carbon,MIDI,AI,Pro Tools
Since 1998, iDevGames has been educating, supporting and enhancing the community of game developers that develop video games for Mac OS X & iPhone. Subscribe to our