Categories
Programming

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.

Categories
Programming

Getting Back Into Flash!

My Flash Environment

It’s been a couple of years now since I wrote a Flash game. They’re fun and easy to write and don’t take much time. For me the fun is in the design and programming. The result of the process might be a playable game–but I make no promises.

I’ve taken down all my old work, since it was out of date and I barely functioned anymore. That’s the problem with programming: The platforms keep changing. The Flash CS 4 of today is a whole new ballgame and I need to get up to speed quickly so turned to my favorite Flash platform how-to author: Colin Moock. I think I have every book he has written on ActionScript that is published by O’Reilly. Since beginning of the 21st century Mr. Moock has exhibited genius when writing about Flash programming.

Moock’s current Flash programming book is Essential ActionScript 3.0 from 2007 which is old by Internet standards. But I’m a couple of years behind the times and EAS3 got me up to date quickly: Subclass Sprite and Shape not MovieClip, how to use events, how to animate, how load resources, how to redraw the stage intelligently. Nice stuff that is scattered all over Adobe’s support site. Apparently there is more Internet info on Flash and its buddies ActionScript, Flex, MXML, and Air then on the Mac OS X APIs!

One technology I want to use in my game is Moock’s Union Platform. It looks like a quick and elegant way to incorporate multiple users into my game. We talk a lot about the power of social networking and data mining but under all that talk is the power of multi-user applications. I remember years ago when I worked at Apple asking Kurt Piersol what comes next after OpenDoc (the hot technology of 1997) and he said MUDs: Multi-User Dungeons. And I said Huh? Isn’t that a buch of guys fooling around in a fantasy world online? Yep, he replied and smiled mysteriously.

12 years later I get it. Any with Moock’s help I’ll put MUD goodness into my little Flash project 🙂