Dear Princess Celestia,


Today I learned an important lesson on the value of good coding design.  If you’re writing a piece of software that you intend to be modular, it’s always a good idea to plan out the design to actually function this way before you start writing any code.  Otherwise, a sudden realization of a fundamental design flaw might require you to rewrite the whole content storage system in your application.  And that wouldn’t be so good.


Your faithful student,


Gabu

OK, so I know that I said in my last blog entry that the next thing I’d be working on was character encounters, but as you probably gleaned from the above, I suddenly realized shortly after writing that that there was a fundamental design flaw in the way in which content was stored in my application that made it impossible to load content (images, audio, etc.) from an external source.  This was a Very Bad Thing, because that obviously meant that the entire idea I had behind cases being modular and separate from the executable was not going to work.  So unfortunately I had to spent the last two days effectively tearing down and rewriting the content storage system in the game to properly accommodate the loading of external content.

However, I’m pleased to report that that speed bump is now behind us, and the game is now looking better than ever.  I’ve now broken off the case source compiler from the executable itself, and have gotten it to successfully compile all the case data plus all required images into a single binary file that can then be loaded into the executable.  In other words, I’ve already got a very, very rudimentary version of a case editor up and running.  <fluttershy>yay!</fluttershy>

As such, now I can finally begin work on character encounters.  Sorry to anyone who was expecting that work sooner.  I promise that when that’s done, I’ll finally actually have some more gameplay footage for you to look at, rather than just this technical mumbo jumbo. 🙂

More details for those interested after the break.

First up, these changes also required an update to the parser – in the case source file, you can now specify both characters and evidence and provide file paths to the images used for each, and it will automatically compile those images in with the rest of the case data in the binary file it outputs.  The new portions of the case source file look like this:

As you can see, you’re now able to define characters and images for their emotions, and evidence and their images and descriptions.  You also give these characters and evidence unique IDs (e.g., “TwilightSparkle” or “CapeShred”), which can then be referenced within the content (e.g., to specify what evidence needs to be presented, or what characters are in the scene).  Previously, these IDs had been hard-coded into the application, but now they’re entirely defined within this source file.

Note that, currently, we only have one single frame per emotion.  That’s mostly because I don’t have any idle/talking animations yet; however, it shouldn’t be too difficult to generalize this to allow for multiple frames of animation per emotion.

(Also, astute readers will probably wonder where the definition of the background music is.  OK, OK, you got me; that’s still hard-coded.  That will be pulled out into the source file when I work on character encounters, since those have an abundance of background music changes.  Stay tuned!)