I haven’t posted anything in a while. I’m not being lazy – I’ve been focused on a game prototype that I have been fooling with for over a year. I picked it up again last month after a long break and I made a few breakthroughs – fixing several major issues by hacking the game engine I am using to build it.
I have a love/hate relationship with game engines (and frameworks in general). I’ve used a lot of code frameworks in my day job: Drupal, WordPress, Magento, BigCommerce, Gaia, Flixel, Flashpunk, Backbone, and a handful of others I can’t think of right now.
The simple fact is that any code framework is a philosophical statement. It’s a developer’s way of saying “this is the way that I think this (whatever) should be built.” Sometimes, they’re great. I’m personally a big fan of WordPress as a CMS and website framework. Other frameworks seem like they’re well thought out, but don’t align with my workflow, like Backbone or the Flash Gaia framework. Still other frameworks seem to have fundamental issues that makes them cumbersome to deal with. *cough*Magento*cough*.
I’ve been building my game prototype in Flixel, which is an Actionscript3 framework for building retro-style 2D games. It’s a really great framework, especially if you are building something with fairly typical game mechanics, like a 2D platformer or a top-down shooter. Unfortunately, I’m working on a concept that uses non-standard game mechanics, so I’m building a lot of pieces from scratch. Even worse, I spend a lot of time chasing down gremlins in the Flixel engine and modifying the core code.
This is where my love/hate comes in. On one hand, it’s a hassle to deconstruct someone else’s code and modify it for your needs. I spent nearly 8 hours tracking down a bug (or “unimplemented feature”, depending on your point of view) in the Flixel core that was caused by the fact that width and height measurements are stored as integers instead of floating point decimals. There’s actually no reason why they’re stored that way, except that the Adam Atomic (the creator of Flixel) never needed the decimal part of the width and height, so storing integer values made sense. I needed the decimal parts and the rounding errors were causing all sorts of ridiculous problems. I’m currently dealing with another issue that Flixel doesn’t handle – how to collision test for a “squish.” That is, how do you know if a player has been smashed between two objects?
Despite these hassles, using a game engine is a better way to go than building everything from scratch. First, you get a lot of features pre-built for you. Flixel handles all of my rendering code, object placement, and most of my basic collision testing. That’s a lot of code that I didn’t have to create from scratch, which saves me a lot of time. Additionally, there is a community of developers using Flixel – so, I can post questions to the community forums when I get stuck.
Developers tend to have strong opinions. So, it’s rare to find a framework that perfectly suits your coding style and workflow. This actually leads a lot of developers to create their own frameworks. A few years ago, when I was doing a LOT of Flash work, I developed an Actionscript3 framework that enabled our team to knock out flash websites and apps very quickly. It suited our workflow, which was very animation-heavy. I have seen similar approaches in other Flash frameworks, but ours was tailored to our specific needs.
I know some developers who will create an entire framework for a single project, but this seems like a lot of work to me if you’re not sure that you’ll ever reuse the code. I have a personal “rule of 3” when it comes to building reusable components:
- The first time I need something, I create the code and drop it in where I need it.
- The second time I need this same functionality, I cut-and-paste it from the previous project and probably clean it up a bit.
- The third time I find myself using the same code, I package it into a reusable component so it’s easier to implement in the future.
My Flash framework grew out of a collection of these components that I organized and refined over a few years.
If you build similar types of things over and over, you can create your own framework organically this way. Otherwise, I suggest using existing engines and frameworks. There is no need to reinvent the wheel for a one-off project. It’s also useful to see how other people handle various problems. I often find useful bits of code that I can swipe for my own projects. As much as using someone else’s game engine isn’t ideal, it still saves me a lot of time. I really appreciate the folks who open-source their frameworks and spend time maintaining them for the rest of us.
If you care to try Flixel, the most recent version is currently being maintained by the community on Github.
Here’s a link to my hacked version of Flixel. Use at your own risk!
