Always Start with Da Face!

Very rough layout--subject to change!

The hardest part of creating a Flash game, after figuring out the idea behind it, is to figure out what it will look like. Once you have those two tasks out of the way the actual coding is easy: The design tells you what to code.

But first -> Inspiration!

Since this game will feature multi-player interaction I’m going to borrow from the greatest of all multi-player games: World of Warcraft. In WoW you get to battle monsters and other players rendered in an epic 3D virtual world. Sweet! In my little game you’ll do the same, only with dots instead of the epic 3D. A lot of WoW-play boils down to a race between DSP (damage per second) and HSP (healing per second). So that’s what my game will do: Let players discover who can keep their little team of dots alive while killing the other guy’s dots.

Like the game the UI will be inspired by Blizzard’s magnum opus as well. On the left will be unit frames that display the health, mana, and experience of your team. On the right will be unit frames that display your opponent’s stats. In the center will be an animated dot-view of the action. Across the bottom will be command frames: Click these guys and you can target and attack bad dots or help your good dots. Lose and you hang your head in humiliation. Win and you gain experience to progress to the next level. Maybe even some loot will drop!

At this point I have a rough idea and a very rough UI design. I like to work it that way. I’ve found it’s a big waste of time to spend hours designing something what will just end up trashed as the concept evolves. It’s time to code…

I’ll need four major classes: An application class to manage everything, A view class to display stuff to the player, a state machine class to track what is happening to who, and a game engine class to control all the action. (This architecture is called Model View Controller (MVC) and is at the heart of almost any well written GUI application.)

Questrian Flash Project Files

I’d like to use a hash map to store the current state of my objects in the game. I don’t really need the efficiency of a hash map. But my ideas are very rough right now and things are going to change. Store keyword-value pairs will make managing change easier than hard coding properties into ActionScript classes. The Adobe documentation suggests I use the Object class to create a fake hash map (associative array) or use the flash.utils.Dictionary class. But I won’t get cool Java-like collection interface convenience functions 🙁

Luckily I found: AS3 Data Structures For Game Developers by Michael Baczynski. Thanks Michael! This library includes Hash Maps, Queues, Trees, and Stacks and more. Hard to believe ActionScript 3.0 doesn’t include them by default.