Well, I’m sorry to say that the current version of Crystal Lotus (for Windows Forms) is going away. I will spend a blog article or two discussing the code, but essentially the main progress I made was with the deck editor and core card functionality. The majority of my time was spent being frustrated with NeoForce Controls, XNA 3.1, and .NET 3.5 before I finally switched to Windows Forms. The code was all ported successfully, but the project stalled not long after due to school-related workloads.
Thankfully, I’m switching to EnigmaEngine, XNA 4.0 and .NET 4.0 for a fresh start. I’ve also talked and read more about designing and writing a rules-enforcing application, so I feel better prepared. I will do an entre-mortem of Crystal Lotus 0 (I’m a programmer… I count starting from 0). Then, after my tests in May, I’ll jump start Crystal Lotus.
Before I begin my entre-mortem, I would like to mention that I’m a high school student. As a result, I haven’t taken an actual CS course at a college or university, but I have been programming C# for well over 2 years. Therefore, kindly judge by quality of code or end product rather than age or the fact that my life is hectic with AP and IB tests and classes.
Generally, in the games industry, a development team will conduct and publish a post-mortem of their game several months after the first or second patch of their game. However, since Crystal Lotus is nowhere near finished and is instead adopting a ‘one step sideways’ plan of action, an entre-mortem seems more appropriate. An entre-mortem is simply a reflection on the design and development of the application. For Crystal Lotus, the entre-mortem will focus on the code and code design but will stray into art and UI occasionally. Additionally, the optimistic scope of the project will be discussed, with the intent about reaching a reasonable conclusion about the development timeline for such audacious projects.
Crystal Lotus was originally designed to fulfill four aspects of functionality. Firstly, it was to entail a complete rules-enforced game of Magic: the Gathering, albeit with a limited amount of cards implemented under its rules engine. Secondly, an AI was needed to provide for human-versus-computer matches and optionally computer-versus-computer matches. Thirdly, Crystal Lotus needed to provide a deck editor to allow for custom creation of decks. Fourthly, Crystal Lotus was to provide a medium-scope RPG – that is, 8 to 10 hours of gameplay – in the style of the popular Shandalar game.
The code and design was intended to be a one-man project spread over months or years, assisted by interviews with the coders of successful engines and supplementary reading on specific topics. The art was to come from OpenGameArt.org, OpenClipArt.org or made by the programmer. Sounds and sound effects were also expected to come from OpenGameArt.org, or otherwise left out of the game in hopes of finding an appropriate asset at a later data.
The completed portions of Crystal Lotus were adequately designed and implemented, favoring neither runtime speed nor code elegance. However, the creation of the completed deck editor and partial implementation of rules engine did only require one person with assets from OpenGameArt.org. The coder did anticipate increased complexity as work on the rules engine progressed; however, the alternative of recruiting a dedicated, skilled and compatible coder was unrealistic, especially considering the current programmer’s inexperience with collaboration tools.
A review of the methodologies used to develop Crystal Lotus reveal a standard object-oriented programming paradigm coupled with a data-driven design. This model was moderately successful as it allowed for polymorphism and quick iteration and redesign, but a few specific code-defined types may need to be redesigned to allow for cleaner and faster development in future versions.
Along with a broad overview of the project, it is also essential to consider the process and design of several key code-defined types. Specifically, the Card, CardLayer, Deck, Format, DataLoader, QueryCache and DeckEditor types.
Note: This article is to be continued next week with an overview of the types. Then, it will be concluded in a third article before I turn my full attention to tests. ALSO: Source Code is available on the Google Code site.