Overview:
Master of Orion II: Battle at Antares (or MOO2 for short) is widely held as one of the best space-borne turn-based strategy games ever made. Released in 1996 as a sequel to the massively successful Master of Orion, MOO2 was a huge hit with fans of the old game and new players alike. Much to the dismay of the many MOO2 fans and online communities, its own sequel Master of Orion 3 was a complete failure and is generally accepted as one of the worst games of recent history. Completely lacking any of the gameplay that made its predecessors successful, MOO3 failed in its entirety.
Master of Orion 2.5 is a long-term game design and implementation project I have started to keep myself busy and to learn about the different challenges that face game designers. The primary goal is to produce a rough clone of MOO2 that can be refined and improved to create the kind of game that I think MOO3 should have been. The secondary goal is to examine why MOO2 was fun and what elements of it made it so successful. For this project, I will be using Java as it's the language I'm most familiar with.
Copyright:
The Master of Orion intellectual property presumably belongs to Atari or something. Because I don't believe for a second that I'd be able to obtain the rights to use the Master of Orion IP in a final product, it will only be used during development of this project and not in any product. If I decide to create a final saleable product, the game's graphics, sound, music, user interface designs etc will need to be recreated entirely. If I ever complete the project in its current form, I will decide whether or not to do that.
Producing a final product:
It is my hope that by the time the primary goal of this project is complete, I will have learned a lot about how and why MOO2 did things the way it did. At that point, I can develop a new game from scratch into a saleable product. My ultimate aim is to make sure the final game contains many of the same gameplay elements that made MOO2 fun and successful. Redevelopment in a different programming language like C# would be prudent if I do decide to create a final product and opens the possibility of making good use of 3D elements in the game.
About this website:
This webpage is for recording the game's development as it happens. It's pretty much entirely for my own benefit but putting it online seemed like a good idea. Maintaining a devblog is a method of making sure that the project is never dropped when I lose interest in it. Because I write an entry after each programming session detailing what I was working on and what I plan to do next, I can drop the project at any time and then pick it up months later without losing my place. This has proven to be very effective so far, with large gaps in development time failing to kill the project.
Breakdown of the project:
The project itself can be broken into four main stages**:
- GUI design/implementation
- Game mechanic design/implementation
- Network coding
- AI coding
Note that I have put the design and implementation phases together rather than systematically designing everything before implementing it. This is because 90% of the designs are already prepared since I'm recreating a game that already exists. Any new design work will be done ad-hoc during implementation.
Within the GUI section are roughly 20 different screens that must be implemented along with data structures to hold any info the the game mechanics may make use of to alter the gui. For example, the planetary view screen must carry info on the number of farmers, workers and scientists and the game mechanics can make use of this. While implementing GUI screens, I find myself implementing a large portion of the mechanics behind the screen's use (for example, map generation is required before it can be displayed) so the GUI and game mechanic implementation stages are tied together somewhat.
Once the GUI and mechanics are mostly in place for the main game, the game will be played in a sort of multiplayer "hotseat" mode to test whether the game mechanics function correctly. Once the gameplay appears to be working, the netcode coding can begin. This is the point when the game would officially be complete and playable, but of course AI would be required for a singleplayer game. AI coding would be the last component of the project before it could be considered complete. If I then decide to make a saleable product from the game, I will start an entirely new project with that goal as described above.
**The fifth and final stage of the project will be implementing Tactical Combat, which will require its own AI, netcode, mechanics and GUI. Tactical combat is like an entire second game from a design and implementation point of view and will take a significant amount of time. I am not sure whether I will bother doing this in the current project but there could be a lot to learn from doing it.
