This week long game project is markedly different from the week I spent on Pierre and the Fish a couple of years back. Back then I felt like my mind was on fire, and threw everything I had at the project. This time, a bunch of minor ills have made me feel a bit more sedate. Nothing serious ( add indigestion to lack of sleep), so I’m not actually sick, but it means this project is more about pace and perseverance than passion. That’s not a bad thing; I won’t burn myself out that way. And I’m sure I can rekindle and regulate the necessary fire once I’ve got back up to speed.
Day 2 was spent relearning the basics of Flash and game development in general. I’ve got a copy of the book ActionScript 3.0 Game Programming University by Gary Rosenzweig, which is a good primer. It’s even got the code for a turret-based shooter game within it, so I’m virtually guaranteed to get something working on time.
I spent the day working through the basic examples: “Hello World” and all the little demos that show how to do each core element of game-related functionality in Flash (display, input, sound, timers, animation etc.). This wasn’t so much to rote learn the specifics (I’ve got references for that), but to prod my neurons into remembering how to make games. I’m very rusty, so this took all day.
The best thing I remembered about Flash and ActionScript 3 is that it uses an event-driven programming paradigm very similar to the one I developed myself for my own 2D framework. For those unfamiliar with event-driven programming, it’s where the program flow is dictated by when key events happen; i.e. when someone presses a mouse button or when a second has elapsed, then do this. You typically do this by linking functions (called listeners) to events, such as myButton.addEventListener(MouseEvent.CLICK, clickButton);, where myButton is the object that you want to deal with mouse clicks and clickButton is your listener function. Event-driven programming is perfect for GUIs and I find it works a treat in games too.
Today (start of Day 3), I’ll get to work on building the playable prototype. Having some source code as a base will help, although I plan to write it again to help jog my game development memory. My current checklist for the day goes like this:
Read through the bits of the book that describe the turret shooter game and take notes. Look at the reference code within Flash as well.
Roughly plan out the basic core of the game on paper.
Write the code and get it running with crudely drawn placeholder art
If I have extra time, I’ll look at the game as it stands before deciding what to do next.
Now I’ve got my laptop back, I can continue to play around with Flash. Although I am planning to continue on with Flash games, I also want to start learning basic animation. Sooner or later I’ll need to use animation in my games anyway, so it’s about time I get my feet wet with what Flash is renowned for.
Eventually I want to get to animation humanoid figures; nothing too realistic, most likely made out of simple vectorised shapes ideal for simple games. Here’s some old concept art for the kind of look I’d like to go for:
However before animating a character like this, I think I need to work on something simpler. From an on-line conversation with John Hattan I’ve decided that animating a character made from a single simple polygon is a great first step at character animation. I’ll give this a go very soon.
Before I can move onto something like that, I still need to work on the very basics. I’ve been reading through my copy of The Animator’s Survival Kit by Richard Williams (he was Director of Animation on “Who Framed Roger Rabbit” as well as many other things). It’s a great book on traditional animation techniques and something I’m going to refer to a lot over the next few months. From that, I’m starting with the traditional first animator’s exercise; animating a bouncing ball. Flash will make this easier than if I had to use a camera, but I’m going to eschew some of the more helpful Flash tricks like making objects following guides and tweening and do this first exercise by manipulating the ball by hand. It’s an exercise to get a feel of the basics such as spacing and timing.
I’ll keep a log of my progress here in my journal for prosperity’s sake.
Here is my very first draft of the bouncing ball in Flash. I can see where I’ve screwed up the shadow with a bunch of simple errors, and early on in the leading fall and the first bounce I forgot the basic principles of physics it seems. It needs some cleaning up.
The next game in ActionScript 3.0 Game Programming University is a shooting game called “Air Raid”, where you move a cannon from left to right to shoot down aircraft. However I’ve decided I’d prefer to branch out a little and make something else up vaguely in the same area. I settled on an old school style arcade scrolling shooter along the lines of Galaxian or Galaga. I figure it’s time to start to learn from trial and error by making more of the decisions on the program structure and programming.
So far all I’ve got is a few choice fonts (from Larabie Fonts like with the other games; Ray Larabie has brilliant free fonts for games) and a scrolling star field. The star field has taken me a little while to do. It’s got through a few iterations and I’m still not very happy with it. It’s a little bit jerky even though I’m using time based movement, and I don’t know whether that’s a limitation of Flash or I’m doing something wrong.
My first approach to the star field was to have an array of star sprites that move down the screen. My second approach was to draw the stars individually onto a single star field sprite every frame. I actually tried both approaches at the same time as I wasn’t sure which would be best. I found that there didn’t seem to be much of a difference between the two - they both were okay, but they both stuttered in movement.
My next approach was to render all the stars at creation to sprite layers saved as bitmaps, and to scroll the layers down the screen. I used two identical sprites per layer so I could have them seamlessly wrap from top to bottom. There were some weird motion effects on the two sprites where they weren’t moving at quite the same speed, which I suspect was due to floating point errors. I’ve now got them working on a variant of fixed point and got both sprites moving in lock step, but there’s still a bit of animation stutter.
I might be overreacting since it isn’t that bad, but I’m curious as to whether there’s a way to getting the scrolling silky smooth in Flash. For now it’s good enough, and I’ll move onto planning out the game.
Additional: I’ve just noticed that the PNG screenshot of the Flash file is several times larger than the Flash file itself. I might as well just post the whole darn thing instead of a still picture!
The thumbnail link now goes to a copy of the Flash file. It might be nice to have a couple of copies of works in development to compare against.
It’s the long weekend, and instead of sleeping in I’ve finished off my second Flash game, Code Breaker. This is from the fourth chapter of the Game University book; the gameplay is essentially the same, but I spend a while modding it extensively to get a feel of how to layout things in Flash.
The game is essentially the same as the board game “Mastermind”; the computer chooses a random code of coloured panels, and you have to deduce the code. Click on the grey panels to cycle through colours to make your guess and hit the Done button, then lights will give you clues on the code. A green light indicates you’ve got a coloured panel in the right spot in the order (but it won’t tell you which one!). A red light indicates you’ve got a coloured panel in your guess that’s somewhere in the code, but you’ve put in the wrong spot. You’ve only got ten guesses to try and crack the code.
One thing that mightn’t be obvious is that the default grey panels can be left in your guess, but are never in the secret code. You can use these to your advantage if you only want to focus on a bit of the code at a time.
Tell me what you think; I’m going to start looking into what I’ll make next.
It took me a little bit longer than I expected, but I’ve got a Flash game up and running. I’d forgotten how many little things crop up when making a game, such as making sound effects, testing and all the other random things that get in your way. Having 4E6 announcements along the way didn’t help!
Here’s a link to a webpage for the game; it’s pretty much the same as the one that Flash spits out during its publishing phase as I haven’t yet decided what format I’ll go with for these things.
The game itself is a simple tile matching game; find pairs of matching tiles by clicking on them. It’s pretty much the same as the game described by Gary Rosenzweig in chapter three of his ActionScript 3.0 Game University book, except I prettied it up a little bit.
I’d love feedback on the game! I’ve tested it myself over the Internet and it seems to work fine, but if there’s anything obvious I need to fix let me know. I’m new to whole Flash thing so I’m sure I’ve committed a few blunders in there.
I know this is just after my poll result post, but since I’m using WordPress now it makes better sense to split unrelated topics off into their own posts. I get email notications on every reply, so it’s not as if someone’s useful comment will get lost along the way.
I spent a chunk of the weekend working through the first two chapters of ActionScript 3.0 Game Programming University. These chapters cover the basics and a bunch of universal elements, many of which are analogues of the sorts of techniques I’ve been using in plain vanilla C and C++ style games. In fact, ActionScript’s interface seems pretty close to what I was building towards in my own game library, such as the display list, event listeners and even the method for storing local data.
This week I’m keen to get started on making games. My plan is to work through a chapter of the book a day if I can, which roughly equates to a game every evening. I’ll also try to do all the artwork too, as I need to get to grips with that aspect of Flash and Illustrator as well. Some days I’ll have to skip game work, and I’ll only have a few hours every evening, but I think it’ll be enough time with the book to help me.
Obviously only spending a few hours per game doesn’t lend itself to producing anything too spectacular; I expect some pretty bland games over the next week. But I’ll see what I can get done each day.
This evening I’ll get started on chapter three, which describes the process of making a tile matching game in Flash. We’ll see how it goes.
Today I’ve unexpectedly received the copy of Gary Rosenzweig’s ActionScript 3.0 Game Programming University I had on order from Amazon. I wasn’t expecting to receive this for another week or two. I’ve only had a chance to skim over the book this evening, but it looks like a very nice coverage of using both Flash CS3 and ActionScript 3.0 for games. It mainly teaches through example, so I’m going to shift from my original plan of hacking my way through making a game or two myself this weekend and work through the book.
So far my ActionScript learning has been mainly through reading the Adobe documents about the language, trying to a grasp of the fundamental concepts. I’m pretty impressed with the scope of ActionScript from what I’ve read. It does appear to be extremely object oriented, to the point where everything appears to be based on the object model - even functions, which can be given attributes and values just like class instances.
This weekend I’m hoping to have enough time to work my way through the first few games explained by Gary Rosenzweig. I’m debating whether I should download the graphic sets he’s got on his website or whether it will be a better exercise to make my own.
