My recent excursion into Flash game development has been fun, to say the least. Certainly, I’ve finally been able to dive into more creative areas of Flash that I haven’t touched as much as I would have liked. It’s also enjoyable to be in charge of all aspects of a project from concept to conclusion. As much for self-exploration as for passing on knowledge, I want to share a little bit about certain aspects of my recent workflow. It won’t be a full inside-out dissection, but more a peek at some highlights that I think might be particularly interesting.
The Whiteboard
No matter what stage of game development in which I’m currently working, I keep a small hand-held whiteboard around. Most of the time, it just sits on my desk or the closest table, but it stays nearby for good reason. Firstly, it helps me immediately visualize current tasks that might be hard to fully imagine in my head. If I’m in the zone, I don’t want to run off searching for something to write on. I want to stay focused, draw on something that’s nearby, and instantly produce results. If something doesn’t look right, all it takes is a quick swipe to erase, and I can try something new.
I’ve found the whiteboard to be most useful when I get the very first idea for a new game. I’m not yet ready to code up a quick semi-playable prototype. I just want to physically see what has vaguely formed in my head. It’s very much a creative task where a simple drawing (that doesn’t even necessarily show interaction in any way) can make the idea more solid. It’s also the first line of defense for deciding if an idea is actually worth pursuing further.
As I mentioned, I’ve been using a small whiteboard. It’s common for software developers to have larger ones on cubicle or office walls nearby. Those are great too, especially if you’re visualizing complex UML architectures. The games I’ve been building are generally quite simple, so I haven’t focused much on code architecture. For that reason, a smaller whiteboard gets the job done. The biggest advantage of a small whiteboard comes from the fact that I’ve been working from different locations almost every day. It’s nice to have a whiteboard that is portable.
Prototypes
Early in development, new ideas need to be tested. This process can go anywhere from a simple drawings on a whiteboard (as mentioned earlier), to semi-interactive proof-of-concepts, to fully-featured demos that only need refactoring and better art before turning into production code. Which of these prototyping choices is needed should be determined on a case-by-case basis. Generally, the more likely it is that a feature will be very time-consuming or difficult to implement, the more complex your prototype should be.
Later in development, features that didn’t need prototypes to ensure that they weren’t blockers may still benefit from quick prototypes outside the game’s main codebase. When one of these features comes up as my next task, I’ll often create a new project in my IDE and play around with some ideas. This not only ensures that I don’t mess up any of my existing code (obviously, this can also be handled through version control rollbacks instead), but it also helps me focus on the single task at hand without all that other code to distract me. One possible benefit from this separate project is a cleaner API, in terms of reusability, because I’ll have a harder time tightly coupling this new code to the existing code in the main project.
For one game I built, a match-3 puzzle game, I made several prototypes to validate the gameplay. They led to some very important changes that improved the game mechanics quite a bit over time. It started with a whiteboard drawing that seemed to validate what, in my head, I envisioned to be a very fast-paced and fun game. However, the first functional prototype with interaction showed me that matches happened too often, and that made the game extremely easy and quite boring. I simplified the controls a bit in the next prototype, but I added a timer-based game mechanic that still kept the matches paced as quickly as before while speeding up other aspects of the game to ensure that the player had some challenges that required him or her keep up.
These changes I made in each prototype helped to make the game a little more fun. As pieces started fitting into place, I could discover other parts of the game that needed tweaking for each successive prototype. In the end, the game mechanics got more and more basic, but they focused strongly on what actually made the game fun to play. So far, this process of simplification in the prototype stage has helped me improve every one of my games as they moved from conceptualization to actual development.
Content Creation Tools
I have a wide variety of tools that I use to develop my games. For my first game, Chroma Circuit, I did all of my development in Flex Builder, and almost all the graphics are programmatic (other than some assets used in the main menus). That game had certain strict geometric requirements that made it difficult to build some of the game’s elements visually. Ultimately, I chose to organize the final code (which has several branches, for reasons that I’ll talk more about later) in such a way that it’s easily built with a short Ant script.
For my second game, Gridshock (still in development at the time of this writing), almost all the graphical assets were created using the vector tools in Flash CS4. I still wrote my code in a Flex Builder ActionScript project, though, since it provides a much better code editor. It’s worth noting that I tried using Powerflasher FDT for a while, but it didn’t quite fit my style of development. Still, I mention it because can provide a similar workflow in place of Flex Builder. For this game, I chose to compile the SWF in the Flash authoring tool instead of with the Flex SDK, but I could have embedded the assets in code and stuck with Flex Builder for all development-centric tasks instead. Mainly, I went with the Flash authoring tool as the compiler because had the urge to try a workflow based around a FLA file rather than only a document class. I can’t say that I encountered many disadvantages, other than switching windows more often to go between Flex Builder and Flash CS4, so I may try this workflow again with other games.
For audio editing, I’ve been using a combination of Apple’s Garage Band and the open source tool, Audacity. It’s worth noting that when I was a Windows user in another life, I enjoyed working with Adobe Audition a bit more, but Audacity has been good enough for me on my Mac. All of my sound effects are derived from royalty free sounds that I purchase for a small fee online, but most of them receive some tweaks. In fact, I’ve often made collections of related sounds derived from the same original audio file as a way to offer some better aural continuity in a single game.
Version Control
Of course, using a version control system is software development common sense, but for many folks who use their free time to create casual games or do any other type of development, it might be a forgotten detail. Allow me to highlight a couple notable reasons for considering a version control system for games.
For me, one of the biggest advantages of using version control for Flash games is related to sponsorships. If your game is popular with sponsors, you might get a primary sponsorship and one or more non-exclusive, site-locked sponsorships. This means multiple versions of the same game, and if you’re using version control, you’ll be able to manage these separate versions with branches. Need to make a change for one particular sponsor? Just edit the files in that version’s branch, and it won’t affect other sponsored versions. Need to make a change to the core game? Do it in the main branch, and merge those changes into the sponsor-specific branches as needed.
For any type of development you do in your free time, it might be a good opportunity to check out one of the various free version control systems you possibly haven’t used yet. Distributed systems like Git and Mercurial have been gaining in popularity recently, and many prominent open source projects have switched to them from centralized systems like CVS or Subversion. This may be a sign that the business world will switch eventually too, so it’s a smart move to begin exploring DVCS now, if you haven’t already (I personally haven’t yet, actually, but it’s on my list of things to do).
It’s worth noting that if you compile games (or any other type of project) with the Flash authoring tool, the binary nature of a FLA file makes it potentially difficult to use with version control systems, try to keep as many assets externalized as you can. Obviously, that includes all source code that can be put into class files, but maybe even images and sound files if they change often enough. Basically, ensure that changes analyzed (diffed) by the version control system are focused to the specific asset files and not on one giant centralized FLA file. This should help to keep your repository history from taking up massive amounts of space, and you’ll find it easier to rollback changes to specific assets while keeping others in their current state.
Conclusion
Again, I’m not trying to cover every detail of my daily development workflow, and probably went into more specific details in some areas than I did others. The process of explaining some things certainly helped me to better understand some of my new processes. It even helped me compare how I’ve been building games a bit more critically to my previous workflow with reusable components. Thanks for reading.