Baseborn: Technical difficulties

Working on Baseborn was one of the best times of my life. I’ve never been so productive and learned so many new things in such a short time. Working with Chris was awesome, and I’m glad we decided to go on working together after the class was over. However, we encountered a number of technical problems during development, and I wanted to share some of them.

One major hurdle early on was that both Chris and I were using Flashdevelop to do our programming, but our professor required all work to be submitted in the form of a Flash Professional .FLA project file. Due to some incompatibilities between the Flex and Flash Professional compilers, all the code we were using to embed art and media assets would have to be rewritten, which, in a project of Baseborn’s scale, would have required an absurd amount of refactoring. Neither Chris nor I had access to Flash Professional except for one day per week (when our class took place), I knew we had to find a way to make our project work in both environments with a minimal amount of changes.

From this necessity FLAKit was born. Instead of embedding assets with Flex metatags or importing them as FLA project symbols, FLAKit loads images and sounds asynchronously from the project directory. This actually helped speed up our iteration time; embedding assets slows down compile time dramatically, while loading them at runtime is almost instant. In a future version of FLAKit I hope to add support for live updating to further increase productivity.

In the end we were able to take our finished project and open it in Flash Professional with no changes whatsoever. I’ll never forget the rush of excitement I as I checked and double-checked that I had opened the correct file. It was almost too good to be true.

Before Chris and I were working together, he asked me how one would go about creating and using animations when the tools built into Flash Professional were unavailable. I briefly explained the concept of a sprite sheet and demonstrated my usage of it in my own project. I was using my own custom bitmap canvas rendering framework at that point with sprite sheet rendering built in, but it would have required far too many changes in order to work in Chris’ project. I wrote a quick class that showed off the basics of a sprite sheet system, then polished up the interface afterward. As you can see from his article on Baseborn’s art process, Chris took to sprite sheets pretty immediately. This class ended up serving us through the entirety of Baseborn’s development, and it’s now included in FLAKit.

Another challenge was learning to use version control as a team. I’d been using Mercurial and Bitbucket on my own for some time before the class, but I’d never been in a situation where other people were contributing to the repository as well. The first few revisions were full of overwritten changes and merge errors, and more than once my commit message contained an apology for messing up Chris’s work or reintroducing a bug we had previously fixed.

Fortunately, it didn’t take too long for us to get familiar with the tools. TortoiseHG and Kdiff3 make using Mercurial a breeze, and Bitbucket’s hosting and issue tracker helped us to stay on track with our goals and tasks. I can’t recommend them highly enough.

One of the biggest mistakes I feel we made was in designing the structure of the code. The update method of our main class is over 450 lines of code and contains a lot of logic that should have been encapsulated into the player class. Towards the end it was difficult to make even minor changes. The enemy class is an example of good entity design; all of its logic is hidden away and it never directly modifies global data. If we had followed this pattern for the player class, our code would have been much more manageable. Unfortunately, the AI logic has received the most work and is the most recent code in the game, so the lessons I learned from writing it came too late to be of any use elsewhere in the project. We’ll be sure to keep this kind of encapsulation in mind in our future projects.

We encountered a lot of technical challenges during Baseborn’s development, but overall we managed to pull through and ship a game I’m quite proud of. Working on a team to bring a game to completion was a great learning experience, and I’m excited to see where we go from here.

One Comment

Comments are closed.