A quick glance at my game development workflow

by Josh Tynjala

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.

2 comments

Thursday, April 23rd, 2009

Flash Player Bug: Removing an event listener in another listener for the same type fails

by Josh Tynjala

Update: My bug report has been marked Not a Bug by Adobe. As Joeri mentions in this post’s comments, and Charles Liss explains in the bug report comments, Flash Player makes a copy of the event listeners internally when dispatchEvent() is called. It’s by design that a call to removeEventListener() will affect the original list of listeners, but it will not affect the copied list. I followed up with a request to describe this behavior in the API documentation so that others who run into the same weird behavior might have a better chance of learning why Flash Player seems to be behaving incorrectly.

I’ve been struggling off and on for days trying to figure out why a certain display object that I’d been fading in and out sometimes got stuck with partial visibility. Even when I explicitly set the alpha value to 0.0 or 1.0 after removing the animation and all its listeners, there was still the occasional situation where it would clearly receive a different value. I finally tracked down the following bug in Flash Player. If two functions are subscribed to the same event type from the same event dispatcher, and the first listener removes the second listener, the second listener is still called by Flash Player.

The following class demonstrates the problem.

package
{
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.EventDispatcher;

	public class EventErrorTest extends Sprite
	{
		public static var dispatcher:EventDispatcher = new EventDispatcher();

		public function EventErrorTest()
		{
			dispatcher.addEventListener(Event.COMPLETE, dispatcherComplete1Handler);
			dispatcher.addEventListener(Event.COMPLETE, dispatcherComplete2Handler);
			dispatcher.dispatchEvent(new Event(Event.COMPLETE));
			dispatcher.dispatchEvent(new Event(Event.COMPLETE));
		}

		private function dispatcherComplete1Handler(event:Event):void
		{
			dispatcher.removeEventListener(Event.COMPLETE, dispatcherComplete2Handler);
			trace("1");
		}

		private function dispatcherComplete2Handler(event:Event):void
		{
			trace("2");
		}
	}
}

The expected output is as follows:

1
1

Instead, my output console displays this instead:

1
2
1

Clearly, the second listener is still called the first time the event is dispatched. If you move the call to removeEventListener() to the line before the first call to dispatchEvent(), the output appears as expected.

I discovered this bug while using Grant Skinner’s excellent GTween library for AS3 in the current game I’ve developing. In my game, certain animations may be paused following the completion of other animations. Since (internally) all GTween instances listen to a static timing object, pausing a GTween inside an event listener attached to another GTween causes the supposedly-paused GTween to update the target’s properties one last time.

If you happen to be using GTween, and you encounter this same issue, adding the following line at the beginning of handleTick() in GTween.as should fix the problem:

if (_paused) return;

This event bug has been filed in Adobe’s public Flash Player database. You’re welcome to vote for it.

11 comments

Tuesday, March 31st, 2009

A preview of my first Flash game: Chroma Circuit

by Josh Tynjala

For the last couple of months, I’ve been quietly (or not so quietly, if you follow me on Twitter) developing a Flash game. Like a lot of software developers, games were what made me want to start programming in the first place. Finally, after getting a little burnt out and needing a bit of a break, I decided to spend some time focusing on making writing code fun for me again. After about a month and a half of exploration, I finished my first Flash game, and it’s called Chroma Circuit.

Screenshot of Chroma Circuit Title Screen

Chroma Circuit’s Title Screen

The basic idea behind Chroma Circuit is that, in each level, you need to match up colors on neighboring elements. Generally, this is done by rotating them, but some other mechanics are introduced later on. The game works a lot like a jigsaw puzzle, in a way, if a bit faster paced. You need to align the colors for every element on-screen before you can advance to the next level. To rotate an element clockwise, you just click it with your mouse. Hold shift, and it will rotate in the other direction. Several of my testers independently called it “addicting”.

Three-Sided Rotating Elements

As the game progresses, levels contain more and more elements, and new elements are introduced over time. Three- and four-sided elements that may be rotated are the most basic types that appear when the game first starts. Later, transfer elements change colors and pass colors to different parts of the level to test the player’s spacial memory. Finally, in the last several levels, a new “bomb” element is introduced. Bombs must always match the colors of their neighboring elements, or they will explode, and you’ll be forced to restart the level.

Watch out for The Gauntlet!

The game contains 18 hand-crafted levels that I spent a lot of time tweaking and play-testing. I had so much fun putting it all together (especially the number of mathematical challenges required to draw the elements programmatically!), and I’m excited to get started on my next game. Chroma Circuit can now be played on my Bowler Hat Games company site, and at various distribution partners across the web. If you think it’s fun, please share it with your friends!

6 comments

Thursday, March 12th, 2009

Open Source Flex Component: PopUpInitializer

by Josh Tynjala

At Adobe MAX this year, I got an idea for an interesting little Flex component. It took me a while to get around to implementing it, but I finally found some time. At the time, I had been building several quick prototype applications with floating information windows that needed to be added to the PopUpManager immediately when the application was initialized. Seeing as these were prototypes, I wanted to be able to do this rapidly without making new class files for each window, and if possible, I’d like to skip calling any methods on PopUpManager from a Script block. Basically, I wanted to throw as much as possible into one MXML file, and then have some component that’s smart enough to add my components to the PopUpManager. With those requirements in mind, the PopUpInitializer was born.

Here’s some example code that adds a TitleWindow to the PopUpManager using PopUpInitializer:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:toolbox="http://www.flextoolbox.com/2006/mxml">

    <toolbox:PopUpInitializer>
        <mx:TitleWindow title="An Example Pop-Up"
            x="50" y="50" width="200" height="200"/>
    </toolbox:PopUpInitializer>

</mx:Application>

It’s a simple class that implements IMXMLObject and makes liberal use of compiler metadata to make itself act like a regular UI container. For example, it uses the [DefaultProperty] metadata to pass the UIComponents to a controls property without having to specify that property name, and the [ArrayElementType] metadata to specify that the controls (there may be more than one) must all be of type mx.core.IUIComponent. Once it receives the list of controls, it waits for the application to be created, and then tosses them all up on the PopUpManager. A cleanup() method is added for convenience to remove all the controls from the PopUpManager, if desired.

Download the component SWC, an example, and the full source code from my Google Code repository. API documentation for PopUpInitializer is available as part of the common documentation with my other “Flex Toolbox” controls like ZoomFrame and PopUpThumbnail. As with most of my other open source code, PopUpInitializer is available under the terms of an MIT-style license.

Start the Discussion

Monday, March 2nd, 2009

Pages: Prev 1 2 3 4 5 6 7 8 ...46 47 Next