Last week I tried to make a game for the 10-second theme on experimentalgameplay.com.

This is what became of it.

The first few lines of code on this were written during my short stint at the indie art jam during gdc, back then it just drew colorful triangles all over the screen. However, the actual game I tried to make didn’t work at all, and I just ended up sitting and toying with it as a stupid drawing application for a good thirty minutes (incidentally about a quarter of this thing’s total development time).

So, I declared it a failure as a game (even though I still want to explore the, uh, spatial relations of triangles a bit more) and made it into a drawing app.

To draw you click a triangle and drag to one of it’s three neighbours, that will copy the color from the first one onto the second. Repeat as needed.

As an added feature it serializes the whole image into a string with every move you make and puts that in the url. This has two benefits, the bigger one being that you can easily send what your stuff to your friends, but it also makes your browsers back and forward buttons act as undo/redo. Here’s one I made.

It has two twitter buttons in the lower left, one to tweet your creation, the other one searches for other people’s posts tagged with the #triangles hashtag, making sharing a bit easier that it ever was with isotope3.

Here are some more amazing pieces of art:

• Blank slate
• Big plaid
• The V

So I decided to try and keep track of what I spend my time on, because I do have a conscience and I will undoubtedly feel bad about wasting my own time.

Keeping a time sheet quite possibly the most boring thing you can do, but fear not, there’s a program called Procrastitracker that does this exact thing for you (PC only). I first got to know about this sweet little app through hello games talk at the gdc.

It’s really simple and there’s virtually no setup, just keep it running in your taskbar and it’ll spy away on you.

This is my last five and a half days of work, yellow is surfing, blue is communication (im/email) and green is work. I’d say I spend roughly half my day surfing, and about a quarter of that is spent in small five minute increments on facebook. Embarrasing to say the least.

Hopefully this can shame me into hanging around facebook less and doing more actual work.

In other news, glorg is coming along nicely, albeit a bit slower than I’d hoped. I’ve been expanding the way of handling states I started with my last post and hooking that up to an animation system to visualize the states, now I can map animations to different states and do transitions and all kinds of sweet stuff.

I’ve spent the day toying with a new way to do the battles in glorg. I wasn’t really happy with the way they worked in the version I submitted to gamma, but nor could I figure out a good way to make it more interesting.

So, somewhat inspired by Ben’s writeup on his devblog for Aztez I decided to figure out the different states the combatants could be in. This graph illustrates the original battle system:

States with an asterisk mean that the player can exit them when he wants to. So the only choice the player has here is  when to exit the idle state, leading into the attack. Then he has to wait for the post attack to finish before getting to the idle state again.

This means that any time spent in the idle state is time you could be making damage, so the best strategy is to bash the button like an idiot. While that is good fun for a minute or so, it quickly becomes pretty tedious, especially since there was no real way to be good at it.

Today I made this graph (along with a small test application) :

As you can see this is considerably more complicated. The player starts out as idle, being idle now also means blocking, something that wasn’t possible using the old system. So if you do nothing, you’re still reasonably safe.

Once the player presses the button we move into the charging state, this makes the character lower his guard, opening up for damage, but the longer he holds the button the more powerful his attack will be. Once he releases he goes into the pre-attack followed by the actual attack and then the post-attack. These phases are primarily for animation purposes, but they also affect how much damage you will take if hit during them.

If the player charges for too long or is hit during any of the non-blocking phases he will be dazed for a short time, leaving him open to attack.

The problem I am facing now is to illustrate all these states using animations. My battle prototype uses simple colors and it’s quite confusing at times, but hopefully it will all make sense once there’s a little monster flailing around a rabbit on a stick instead of a stupid box changing colors. As always.

The GDC is over and I’m taking a new step in life. I am taking a year of from work to do my own thing, and today is the first day. This feels both fantastic and terrifying all at once. Doing this I really do hope I can get some real work done on my games, I’ve got a bunch of ideas lined up I want to try out, but first I intend to try and finish up glorg.

GDC was just as amazing this year as last. I sort of want to make a long list of all the fantastic people I met, but I worry I will forget someone and it’ll look a bit too much like namedropping, so I’ll just stick to a “best-of”:

• Cactus acceptance speech, I have rarely been so worried what he’d do, luckily it turned out pretty damn hilarious in the end.
• Hearing Alexander Bruce repeatedly yell “Faabs” out the hostel window.
• The Gamma IV party
• The improvised party at Erik’s place
• Being drunk at a place like the Exploratorium
• Petri being a Garth lookalike.

Firstly, I learned so much from the summit last year. Hearing people successfull in making a living of their love for making games is absolutely delightful. It’s also very inspiring in a quit-your-job sort of way.

Another reason I go is the excellent indie community, just the thought of meeting everyone has me all giddy with excitement. It’s perhaps only a bit unfortunate that this happens at an event with a minimum pricetag of $500, but, being a part of a larger conference certainly has it’s benefits.

My third reason is to celebrate. I’m taking a year of from work to do freelancing work and make some games. Exactly how much I’ll be doing of each still remains to be seen, freelancing is quite attractive as it’s a much safer livelihood than games atleast from the outset. But I’d be lying if I didn’t say that I at least hope to get two or three games done during this year.

If you too are in town for GDC (or the Flash Games Summit) please do drop me an email so we can meet up somewhere!

The theme for gamma this time was one button game. That means one button, no joysticks, no mice no nothing. Just on and off. Very interesting. I ended up reworking the game I was currently making, originally ment to be something completely different, to fit the theme and I think it turned out quite nice.

I can’t publish it until I know if it’s selected, however there was 154 games so the competition is going to be just brutal. If it is selected I get to show it off on the expo floor of GDC.

This is what the game looks like:

Inspired by Petri’s timelapses I kept chronolapse running as soon as I worked on the game. It’s taken me 2836 screenshots (that’s one per minute) to make this. That works out to 47 hours of work. I put in the last 36 seconds or so of work (in video time) during the nordic game jam.

Now all there is to do is wait, and maybe fix a few bugs…

I made a game for the experimental gameplay project, it’s called leaf.

This is one of those games I got started on a while back, and figured I’d finish quickly but never really got around to it after the first day of hacking away at it. When I heard that the theme for december was going to be “art game” I knew this game would be a perfect fit.

The idea came to me when I was walking home with the game’s theme-to-be playing on my ipod, I saw leaves tumbling to the ground and uttered the words all game designers have come to hate “I should make a game about that”.

Once I got home I played the song and pitched the idea to my friend Jonas, mostly to get some feedback, but also to trick him into doing the graphics.

Things happened, pictures got drawn, days were spent on stupid, stupid scrolling bugs and this is what became of it.

Play it and tell me what you think!

(Quick link to the game on FGL)

This is moonbow. A game I started working on on the flight to GDC this year. True to form I had no idea where I was going with it then and it has changed and morphed quite a few times since then. I’ve been saving the different versions throughout development, but those will be in a later blog post.

I’m going to try something new with this game, normally I’ve just put my games up here and been done with it. This time I figured I’d give Flash game license a try. I’ve been talking to a few flash game publishers before, and negotiating a price really is a huge hassle. I’m a bit hesitant to what sites like FGL will mean for flash games, it might be a good equalizer, also it might reduce them to become even more of a commodity than they already are. But there’s only one way to find out.

If you have an account on FGL you can play the game there. If not you’ll just have to wait (or hit me up on twitter).

By now we’ve got almost all the basic building blocks to make a simple game. All that is missing is how to get some input. Last time we touched on it a little bit using the mouseX and mouseY properties.
Those are the most straightforward to get at, but other inputs aren’t very complicated either. Let’s start with the mouse button.

Note that it’s mouse button, not buttons, one of the limitations of the Flash platform is that you only have access the to the left click.
Right click gives a menu, and there’s no getting around that.

To get the most of out of this part we need to start with making a Player class. Check back in part three for how to add a class but name it Player this time. Add an instance of the player to your Main class and make sure it’s on the stage. If you’re too lazy just get the prepared project here.

Getting input brings us back to the event handling we started with in last part, in your Enemy class’ constructor add an event listener for MouseEvent.CLICK:

addEventListener(MouseEvent.CLICK, handleClick);

Once this is done we add the handler method, use the neat CTRL+1 autocompletion or just type this out (copypaste is cheating).

private function handleClick(e:MouseEvent):void {
	trace("clicked enemy");
}

Give the Enemy a click, and gasp at the fantasticness of the traced output. You will notice that if you click outside the enemy nothing is traced. This is because we are listening for clicks on that specific object. If you add multiple enemies they will each have their own handler for clicks.

Sometimes this is great, other times, not so great. What if you have a whole bunch of enemies and want to do something in your main class when any one of them is clicked. You can use this exact method and let the enemy call a function on your Main class, but that’s not very pretty code.
Adding a listener to each one from the Main class is a possibility, since a handler can handle events from many “dispatchers” (things that broadcast events are called dispatchers). But, we don’t want to repeat ourselves unless we absolutely have to.

So, we’re going to do it the neat way. Add another listener, this time in the Main class. Do it the exact same way, but let’s put a different trace in so we can tell them apart:

private function handleClick(e:MouseEvent):void {
	trace("clicked in main");
}

For this example to work we’ll need a couple of extra enemies. Since we don’t really need a reference to them we can do it like this:

for (var i:int = 0; i < 5; i++) {
	var tmpEnemy:Enemy = new Enemy();
	tmpEnemy.x = Math.random() * 800;
	tmpEnemy.y = Math.random() * 600;
	addChild(tmpEnemy);
}

What we do here is first a small loop, this is a classic for loop, if you need to read up on what the arguments are a quick googling should help you out. Then we create a temporary variable to hold a reference to the enemy we’re about to create. We use that to position the enemy at a random spot on the stage. Math.random() returns a random number between zero and one, we multiply that with the stage size we’ve set in the project properties (800×600 is the default in FlashDevelop). The Math class contains all the math related methods, so we’ll see more of that in a later parts of these tutorials.

Run it and give any Enemy a good clickin’, you should see both the trace statements in your output. The attentive log reader notices that the enemy’s trace always arrives before the main trace. This is because of something called event bubbling.

This means that when a object added as a child to something receives a click (or any other event) this event will bubble up the hiearachy to it’s parent. The parent will in turn bubble it further and so on. Thus, by listening for click events on our Main class we’re getting all clicks in the whole application. Almost.

The click registration respects the objects shape (it doesn’t handle images with alpha though). A good way to visualise this is to set the enemys propety buttonMode to true. This will give you the hand cursor whenever you’re in a position that would click that object.

If you want to listen for all clicks you will need to add a listener to the stage. This will give you all clicks even those that aren’t really on anything, but we’re not going to need that right now.

Knowing what got clicked is real easy when you’re only listening for clicks on a specific object, but as you’ve seen that’s not always the case.

You have probably noticed that the event handling functions accept an argument. I (and Flash Develop) almost always name this e:

private function handleClick(e:MouseEvent):void

But you can name it however you want, it will have to be there however  since that’s where all the information about the event goes.

You can use FlashDevelops autocompletion to take a look what properties are available, there’s quite a lot of them. We’ll focus on the one named target for now.
The target is the object that initally dispatched the event. In our case that will be either one of the enemies or your new Player class, assuming this is the listener we set up in Main.

This property is an object which is one of the most basic datatypes in Flash. This is because the thing that dispatched the event could be of any type. To get at the actual Enemy we’ll need to cast it.

If all you care about is what class the target was you can do it like this:

if (e.target is Enemy) {
	trace("run away");
}

This is pretty straightforward, the is operator compares the target to a class and evaluates to true if it’s a match. But there are other neat tricks you can do which are especially useful if you want to do something with the target.

Try assigning your enemy to a variable in the handler:

var targetEnemy:Enemy = e.target;

The compiler will whine about this, since we’re trying to put a generic object into something that’s meant to hold an enemy. To get around this we need to specify that this infact is what we want to do:

var targetEnemy:Enemy = e.target as Enemy;

Now, if this succeeds the enemy will be accesible via the variable, if it fails the variable will be null. This combined with the fact that in actionscript everything can be evaluated as a Boolean lets us do like this:

var targetEnemy:Enemy = e.target as Enemy;
 
if(targetEnemy) {
	targetEnemy.y += 20;
}

If you click the player the cast will fail and targetEnemy will be null. null will evaluate as false, and a reference will be true so we can safely do stuff with our enemy inside. Neat, huh?

The compiled size of the same actionscript file will vary with up 4 bytes between compiles. You can really just bring up the command line and recompile the same file a couple of times and it will be 4098 bytes the first time and 4094 the next. Very strange. I tweeted about this suspecting some kind of metadata was stored inside the file, someone told me this shouldn’t be the case so I let it go. Turns out metadata is stored, and more than you’d think. A standard swf compiled with mxmlc can have these values:

• contributor
• creator
• date
• description
• language
• localized-description
• localized-title
• publisher
• title

The mysterious bytes come from the fact that there is a timestamp embedded, this will affect the compression of the swf making it compress a few bytes smaller if you’re lucky and a bit bigger on other occasions. These have default values, and these may be useful to keep track of stuff, they’re just a bunch of bloat to a 4k game. Luckily they’re a piece of cake to get rid off. Add these options to the compiler to set them all to be empty:

-contributor=''
-creator=''
-date=''
-description=''
-language=''
-publisher=''
-title=''

(In FlashDevelop you set these options in Project Properties -> Compiler Options -> Additional Compiler Options) However, the swf will still be up to three bytes bigger on occasion, I think the time still gets in there somehow. Nevertheless, this shaves of a whopping 40 bytes on my current version of asteroids4k!

Wow, when I  got started on this whole tutorial thing I never expected it’d take four parts just to get to the enter-frame part. But here we are.

This post will be about making stuff move. But before that we’ll need a quick primer on Events. They is one of the mainstays of actionscript, especially version 3.

The basic concept is that an event can come from any place at any time and whoever listens gets notified. This is what drives Flash at it’s core, everything that is done is in response to an event.  There are events for alot of things and they’ll come back in pretty much every step from here on, so listen up.

To get things moving about we need to run some code each frame. The way to do this is to set up an even listener for the ENTER_FRAME event:

addEventListener(Event.ENTER_FRAME, handleEnterFrame);

If you type this out in the constructor for your Main class you will notice that FlashDevelop gives you a whole bunch of suggestions, these are all events you can listen for, but right now we want the ENTER_FRAME one.

The second parameter is the function that will handle this, you can name these whatever you please, but I find it good practice to prefix them with handle just to make it clear what they do.

Next we need to add this function we are refering to, if you want to you can place your cursor over the function name and press CTRL+1, this will invoke the contextual code generator that will create that little snippet for you. If not just type this code out below the constructor:

private function handleEnterFrame(e:Event):void {
	trace("enter the frame!");
}

Now run your code, if everything’s okay you should get a flood of enter the frame in your output window.

Now we can start making stuff move around, try adding to one of your enemies properties:

enemy.x = enemy.x + 1;

When doing things like this i normally use the shorthand for adding to a property, it does the exact same things, it’s just a little bit less long winded:

enemy.x += 1;

If you run the code now, you should have a moving gnome!

While this is very neat, it’s not very interactive. Let’s get my favourite input method involved.

Each DisplayObject (in this case your Main- and Enemy class) has a pair of properties called mouseX and mouseY, these are the relative position of the mouse pointer to their registration point:

enemy.x = mouseX;

Now it should be a walk in the park to get the gnome to rotate and follow the mouse pointer. For an added challenge try making him rotate around his nose instead of upper left corner.

In the next part, number six, we get some interactivity into the mix.

Last time we got our first enemy on the stage. Now we’ll take a quick look at embedding other formats into your classes. Grab the gnome here to the right and put him in your assets folder.

The syntax is basically the same to embed other formats (png/jpg).

[Embed(source='../../../../../../assets/gardengnome.png')]

FlashDevelop will generate this little string for you if you doubleclick your wanted image in the Project panel. Place the [Embed] tag right before the class declaration as we did last time.

If you compile and run now you will get a runtime exception from the player. This is because our enemy is still defined as a Sprite, and sprites are vector based. We need to change the base class to Bitmap. Do that, and make sure your imports are in order before you compile. Now it all should run just fine again.

Flash does not resize your image, it will be embedded in it’s full resolution. So make sure that it’s a proper size before embedding it, resizing it in code will just add unnecessary bloat to your file and will affect performance.

Having to change the base class like this can be a bit of a hassle, especially when you have multiple levels of inheritance going (maybe a baseclass like GameObject). So there’s a cleaner way to do this. Create these two  properties on your enemy:

private static const GfxGnome:Class;
private var gfx:Bitmap;

The first one is both a static constant, this means this property is attached to the actual class, and not to the instances of it you create. Wether you make them private or public is up to you, I prefer having things private until otherwise needed, so that’s what I went with.

For now we set the base class for the enemy back to Sprite. But instead of having the [Embed]-tag before the Enemy class we put it before the GfxGnome class. This will make the gardengnome.png attach to that class instead.

Now we need to instantiate that into our gfx property. We do that in the constructor like this:

gfx = new Enemy.GfxGnome();

Since GfxGnome is attached to the class and not this specific instance we need to specify that by using Enemy before it’s name.

If you run your code now you will notice that nothing is showing up. This is because we need to add our graphics as a child, right now they’re just hiding out in memory somewhere.

Adding the graphics as a child works the same way here as it did in our Main class where we first added the Enemy:

addChild(gfx);

Now you should be all set for getting graphics into your games. If you got lost somewhere on the way, the project files are available for download.

Next time we’ll make stuff move around!

Other entries I enjoyed are:

• 4kpillars. A very cool looking game, the flying on a sphere mechanic works great.
• Falling with style a technically very impressive entry, I’ve always loved pilotwings.
• Ghost4koin really makes me wonder how they managed to fit that in 4k
• Pie is maybe the most complete of the entries, also great!