Latest Posts

  • Learning ActionScript 3? Here are some great books

    After publishing my review of the recent Flash Game Development by Example book (in which my complaints were validated by similar reviews from Iain and Rasmus) I received a number of questions both by email and on Twitter asking me books what I would recommend.

    The first thing I’ll say is that I don’t believe there are ANY good books that teach you how to code in AS3 by using game development as the means.

    There are some excellent AS3 books, and some excellent game development ones, but all those that have tried to combine the two end up either skipping vital AS3 details, or build such basic games you don’t really learn anything about game development in the process.

    Before I begin however this is important: Obviously I have not read every book there is on AS3. So my recommendations here can only be based on the books I have read and value. If you’re the author of a book not listed, that you think should be, send me a review copy. Here’s my list with links to the publishers sites (and no cheesy affiliate links!)

    Learning ActionScript 3 by Rich Shupe, O’Reilly

    I strongly suggest the excellent “Learning ActionScript 3.0” by Rich Shupe and Zevan Rosser. Even if you’ve been coding in AS3 for a while there are things this book can teach you. It leaves virtually no stone unturned. Read this from cover to cover and you will have touched on every aspect of AS3 you need. From the way events propagate, to text handling, bitmap filters and display list management it’s comprehensive and clearly written. The only issue is that the contents are a bit dry. By this I mean you’ll never actually create anything fun while reading this, and you won’t learn a thing about game structure. But to sink your teeth into AS3 they don’t come much better than this. The 2nd edition was published at the end of 2010 incorporating Flash platform changes that entails, so if you do seek out a 2nd hand copy, make sure it’s a recent one.

    I used to recommend Essential ActionScript 3 by Colin Moock (also by O’Reilly) but the freshness of content in this book kicks it one level higher.

    http://oreilly.com/catalog/0636920010401

    ActionScript 3.0 Cookbook, O’Reilly

    I’m a big fan of the O’Reilly cookbooks. They come into their own when you’re starting to learn a language and have the basics down – but just need to know in which package to look to find the solution to a given problem. For example if you want to know how to load an XML file you can just pick-up the cookbook and look for that in the index. The code examples are concise and well written, and coming from a variety of authors seems to help make them more relevant. It’s a really vital book. Yes you can Google, but if you are learning a language there is no way for you to evaluate how well written (or correct!) a Googled blog post is for example. The only issue I have with this book is that it hasn’t been updated since 2008. It was however the way I learnt AS3 (used with the Essential AS3 book).

    http://oreilly.com/catalog/9780596526955

    Foundation ActionScript 3 Animation: Making Things Move! by Keith Peters, Friends of Ed

    This is a brilliant book. There’s no other way to put it. It starts off with a great crash course in AS3 (take note authors, this is the correct way to do it) and then dives in to, well.. making things move! Making them properly move. None of this Flash IDE timeline stuff, but actual real physics that you can use in real games. And it’s not complicated physics either. It starts off very gently and then keeps layering it up. Bouncing, friction, gravity, velocity. Throwing objects with the mouse, collision, springs, the works. There is even a little chapter on faux 3D (which to be honest feels shoe-horned in, and isn’t very relevant today). You will learn both good structured AS3 AND very useful game development techniques from this book, which is why it’s essential reading. The only down side is that it hasn’t been updated for a while. There is a follow-up book (Advanced Animation) but it’s not as easy to get in to and feels a little more “edge case” in its application. Still a fascinating read though.

    http://www.friendsofed.com/book.html?isbn=1590597915

    With the above 3 books I honestly believe you can go from knowing nothing at all about AS3, to having touched all the important aspects of it, and even built some really cool things in the process. Use them in combination with a framework like Flixel and suddenly a LOT of the way Flixel does things will make a great deal more sense to you. Equally if you stumble across a piece of source code online you’ll have a much better idea if you’re looking at quality code or a piece of blog filler.

    Advanced ActionScript 3 with Design Patterns by Joey Lott, Adobe Press

    This was recommend by both Iain Lobb and Damien Altron. Be sure you get the correct book as there is a very similar titled book published by O’Reilly. The one you want is published by Adobe Press. The first half deals with general AS3 practises and the second half the use of design patterns. From the comments I’ve read it appears it’s very well researched and written.

    http://www.amazon.co.uk/Advanced-Actionscript-3-Design-Patterns/dp/0321426568

    I will follow-up this post with one listing my favourite AS3 Game Development books shortly. But really, get the language down first. Then make games. Not the other way around.

  • Flash Game Development by Example Book Review

    Emanuele Feronato is a familiar name to anyone who’s ever searched for something to do with Flash game development on Google. The tutorials he publishes on his blog are as ubiquitous as the platform itself. They provide nuggets of code usually meaty enough to accomplish the task at hand. Be it creating a Match-3 knock-off, a landscape generator or showcasing a new library. The complexity never really leaves the shallow end of the pool, which I suspect is the main reason beginners flock to his site.

    But with a book you leave the safety zone of “this is just enough” behind. When people have put down good money, the expectation levels are rightly higher. So it was with intrigue that I started reading Flash Game Development by Example. It covers the creation of 9 games across 300+ pages, which is an average of 30 pages each. Probably 28 more than he uses on his web site 🙂 I was curious what this extra space would provide.

    The first game we make is Concentration or “Pairs”, the classic card game. Everything is done in the Flash IDE at a size of 550 x 400, and it leads you step-by-step through creating an FLA, creating your Main.as, entering a trace statement to prove it compiles and then explaining what imports and packages are. The explanation for the Sprite package for example is “This class allows us to display graphics”. That’s true, and while I’m not expecting a detailed explanation at this level I did expect a little more. Emanuele then starts creating the game, kicking off with a loop to make an Array of 20 tiles. Every single line of code is explained – rapidly jumping through AS3 syntax as it goes. It’s as if the single line of source “for (var i:uint=0; i<NUMBER_OF_TILES; i++)” caused Emanuele to stop and realise he had better explain what a uint, a constant and a for loop is before he can carry on.

    The problem with this approach is you forget what it was you were building as you try to deal with a rapid onslaught of new information. And it doesn’t let-up. By page 19 the game is dealing with adding a Fisher-Yates shuffle algorithm. A quick trip back to the Flash IDE creates some tiles, and more code starts displaying them and adding event listeners for clicks. By page 31 you’re deep in the realm of indexOf Array checks, event.currentTarget magic value access and modulo operations. Nearly every line of code is still being explained but the pace is borderline frantic. And just like that, it ends. The game is complete, a few homework assignments are given to you and we’re on to Chapter 2.

    Chapter 2 is about building Minesweeper. So multi-dimensional arrays and iterative scanning for mines. It also contains probably my favourite quote in the whole book:

    “Just think about a function like a mad witch. You give her some strange stuff such as bat wings and lizard tails, and after making something mysterious she gives you a potion to turn someone into a frog. The great thing is once you’ve made your functions (witch) you don’t need to know how they do the magic anymore.”

    🙂

    However this is a bit of code taken from the function it teaches you to make:
    Read More

  • Flixel Power Tools v1.6 released including FlxControl

    I’m really  happy to have finally pushed v1.6 of the Flixel Power Tools from dev to master! The major new class is FlxControl. On the surface it may seem a bit pointless, after-all keyboard controls in Flixel are dead easy, right? But it actually wraps those up with the FlxSprite motion and physics. This means you just tell it how many pixels/second you want the sprite to move, and it’ll do the rest! Maximum velocity, acceleration, deceleration, gravity, firing, jumping and flipping all supported. There are 5 new Test Suite examples showing how to use FlxControl, including a platformer demo (the screen shot below), a 2-player on the same keyboard demo and a simple space invaders game.

    I’m particularly happy about one feature in FlxControl – the ability for a “fall jump” timer. In Mario games there is a very short period of time in which you can still jump even if you’ve just fallen off the end of a platform. FlxControl lets you set that value, so your game can feature it too! You can experience it in the Control Test 2 demo. The little chick sprite can fall-jump, giving him much greater air control. Of course, it’s optional.

    Also updated was FlxScrollZone with a new feature that made it work better with images containing alpha data. Finally a new Special FX Plugin – DropDown, which creates a nice way of revealing a title page or other in-game element.

    As usual grab it from github or click any screen shot to see the full Flixel Power Tools page.

  • Flixel Power Tools v1.5 – A monster of an update!

    The Flixel Power Tools are going from strength to strength, and last night I finally completed the v1.5 update, and it’s a monster…

    Hello github

    First of all – we’ve moved to github! After getting extremely annoyed at the downtime of my Google Code project I decided to bite the bullet and learn git. And I’m glad I did! As a result I have reorganised the whole project structure. It’s now cleaner, easier to navigate and doesn’t rely on any classpath dependencies. Hoorah!

    Comprehensive Getting Started Guide

    I’ll admit it – although the tools were pretty easy to use, they did assume a lot of prior knowledge to get up and running with them. This has now been addressed by way of a PDF guide. It takes you through the process of download, install and use, step-by-step. It’s included when you download from github, just look in the Docs folder.

    Revamped Test Suite

    The Test Suite was a great idea, but was getting cumbersome. So I have refactored it extensively. Tests are now stored in sub-folders relating to the tool they apply to. I’ve also dropped the “Flx” part of the test class names. There are lots of new tests, and the suite has grown in size vertically to accommodate the layout changes.

    Bugs, be-gone!

    Lots of small bug fixes across most classes. And lots more in-line documentation added. I don’t think there is a class / function anywhere now that doesn’t have in-line documentation with it. Some classes have had a few changes, for example the Color and Gradient classes now fully support alpha channels in all colours given, so check your code before wading right in – but if something like the FlxHealthBar starts looking strange after you update, it probably just needs the colour changing to AARRGGBB format.

    New classes!

    Of course there are some new classes too 🙂 FlxScrollingText takes the best parts of FlxBitmapFont and FlxScrollZone and merges them to create extremely flexible scrolling text fields. Just feed it with a FlxBitmapFont and you’ll get a Sprite back that you can stick  anywhere in your game, with fluidly scrolling text running through it. Update the text in real-time, have the sprite delete itself once the text ends (or wrap to the start), bounce it around, scale it, alpha, rotate it. Pretty cool really 🙂 3 Test Suite tests included.

    And finally the introduction of FlxSpecialFX. The more I worked on the Power Tools the more I realised they were splitting into two key areas: tools for your game, and tools that just created visual effects. So it made sense to me to start splitting them out – which is where the FlxSpecialFX class comes in. It’s a handler for the new FX Plugin system, into which I’ll carry on expanding and adding new FX (and hopefully the community will too!). Right now there are two FX plugins – Rainbow Line and Plasma, but lots more are coming 🙂

    Play with the tools over here and be sure to grab the new package from github and enjoy!

     

  • Flash Game Dev Tip #9 – Dealing with a lack of motivation to finish your game

    Tip #9 – Dealing with a lack of motivation to finish your game

    You are not alone

    Everyone suffers from this problem at one point or another: You simply can’t face the thought of working on your game. This is especially hard when making the game in your “free time”. It’s all too easy to think “what the hell” and double-click that Team Fortress icon instead of FlashDevelop. And even days when your head is saying “let’s code!” all that motivation can vanish the moment you open the source and realise that its been so long since you were last here it’s like staring at a foreign language, or a giant brick wall and you have no idea what to start first.

    There is no “single solution” to fix this. It’s extremely personal. Your reasons for not wanting, or being able to code will be as varied as the number of people reading this. But as I said at the start you are not alone – so I posed the question of how to deal with it to 13 fellow game developers and collated their replies. Hopefully somewhere in these insights you’ll find a technique or suggestion that helps you out. And if you have one that you personally use, not already mentioned, please post it into the comments.

    I’ll kick things off …

    Richard Davey / Photon Storm

    http://www.photonstorm.com

    I’ve come to realise that I’ve a game development mana reserve. When I start work on a game, my mana reserve is full. But as coding begins this reserve drops faster and faster. Sometimes if I hit a particularly troublesome spot in a game it can be enough to utterly wipe-out what reserves I had left, derailing the project entirely. But there are also the “wins”. Getting a significant part of the game finished, or adding something really cool. That helps re-fill my mana reserves and keeps motivation high. It’s a constant battle. To get the game finished before enthusiasm is depleted entirely, yet to have enough wins on-route that they keep things in balance.

    The “wins” however cannot be artificially placed into the project. They have to be unexpected and grow almost organically as a result of  working on the game. Equally the hits to my morale are never expected either. I never start coding expecting to stump my toe on a  bug from hell, but it happens.

    There are two issues here:

    1) Having the motivation to continue working on a game

    I think like a lot of people I’m most excited about a game during the very early stages of it. The feeling of bringing something to life, of getting the idea out of your head and into code – that’s a real achievement in and of itself. I enjoy the task of getting a working prototype up and running, often with really crappy code driving it. The thing to do at this stage is to try and work out for yourself if you should stop right now, and not even attempt to carry on.

    Use those prototypes

    There is nothing wrong in building a prototype and just leaving it at that. Of course if you’re in this for the money it’s not going to get you rich, but if like me you do this for fun then you shouldn’t feel any sense of “guilt” for having made just a prototype. If by this point you recognise that your enthusiasm is on the wane already then don’t just file it away for another day, thinking you’ll come back to finish it later on. Because almost certainly it will never happen. If you don’t have the enthusiasm or excitement at the end of this stage to take the game further, then you never will.

    Don’t waste it though. Think about how what you’ve made could be useful to others. Perhaps it’d serve as an interesting “I made this little demo” post for your blog or a forum. Or maybe it could be turned into a tutorial for a development site with little modification. You may be surprised at the response. I’ve had people see “demos” of work who suggested just one change, that radically altered the course of the game, resulting in it being finished and released. As I mentioned at the start, “mana refills” can come from anywhere, sometimes the most unexpected of places.

    Do something other than making games

    Making complete games is hard, there’s no doubting this. Even the most simple of games still require quite tedious boot strapping to make them suitable for release. But that “rush” and feeling of sheer joy you get when you finally publish doesn’t always have to come from making a game. As readers of my blog will know I work on a lot of game development projects such as my Flixel Power Tools or tutorials. I do this because I enjoy writing, but also because I remember what it was like being fresh to development – how I was a sponge, soaking up every last piece of information I could get my hands on.

    There is a real thrill in authoring this type of content too, and publishing it. So you don’t feel like making a whole game? No problem – could you make a demo that showcased how to make a sprite jump from platform to platform? The scale is significantly smaller, but the end result could be extremely useful to your fellow developers. And their feedback can be enough to spur you on during the more laborious development work you need to do.

    Of course the downside of all this writing is that it takes your time away from making actual games, as Ilija will attest to 🙂

    Public Beta Tests

    We ran a public beta test of a game called Kingdums. We just put a build of the game onto a web page with a big feedback form below it, and shouted the URL onto twitter. It was live for a week. The feedback we got was fantastic, because it under-lined a significant flaw in the game (that was in the back of our minds anyway, but made it prominent) and reaffirmed that actually, this flaw aside, people really enjoyed playing it. Other developers use public beta tests for similar reasons – lots do it to find out if their games have bugs they’ve missed, but it doesn’t just have to be about that. Sometimes you’ll get suggestions that highlight issues you didn’t see, and sometimes it’s just a good morale boost.

    It’s not just code that can be tested – you could post-up screen shots, character bios, even basic story arcs. All things that feed back into the game overall.

    Enforced Time Constraints

    Some people don’t understand the point of making a game in a limited period of time. Others relish the challenge. Personally I fall somewhere in the middle. I haven’t yet had a chance to take part in something like Ludum Dare, because I have a family life that stops things like that happening over weekends. But the times that I have made a game in a limited period of time (we’ve done it 3 times now) it has always worked for the better. Todo lists get cut down dramatically. Only the essential game aspects are given attention, and the time limitation really does focus your mind. Try it, it may appeal to you.

    Using a To-Do List

    You’ll see this suggestion raised time and again by the other devs below. Ilija and I use the free software Wunderlist. I like the fact I can add items from my iPhone or PC and have it all sync-up properly. We don’t have lists for prototypes, only for games deep in development. I find it pointless starting a list with “make an enemy manager”, that feels too early-on in the process for us.

    2) Dealing with “getting stuck” while coding

    This is the easiest to solve. If you have a coding problem, then you ask for help. If you don’t work in an environment where you can ask fellow coders for suggestions, then there are hundreds of really great game dev communities online. And you should join one and really participate with it. Help out other people suffering problems you may already solved, and post your problems up there also. More often than not someone will help, or at least direct you onto the right path that leads to solving the problem anyway. If you can’t solve the issue within a couple hours of trying, and can’t think of another way to approach it, then you need a bring a second brain into the equation. The longer you delay in asking for help, the more chance you have of never finishing.

    Don’t feel guilty

    You’re only human. Human’s need a fine balance between work, rest and play. And developers are terrible at balancing those three elements. There’s a famous producer graph showing “Price – Speed – Quality”, with the mantra that you can only ever have 2 of those 3 things. So “Speed + Quality comes at the expensive of Price”, or “Low Price + Speed means low Quality”.

    I feel that developers do the same with “Coding – Resting – Playing”. By “Playing” I mean taking time out from coding: watching a movie, spending time with your significant other, reading a book, playing Xbox, etc. Too much coding but the right amount of sleep usually means you give-up your “play” time. If you’re burning the candle at both ends, holding down an intensive day job and then coding all night, your Rest and Play can be sacrificed. If when you sit at your computer you find the code just isn’t flowing then stop. Don’t battle it, don’t trudge through. Just stop and do something else entirely (ideally non-computer based). Then try again the next day. If you’ve been working like mad all week, getting a few hours sleep a night, then pay off that sleep debt.

    Development is a roller-coaster of highs and lows. If you recognise you’re on a coding streak then enjoy it and use it to your advantage, but when it ends (and it will end) switch track quickly and work on something else. Then switch back again. The quicker you learn to recognise your “moods” the more useful you can make them. I’m not perfect at this yet, not by a long shot. I still have lots of “unfinished” games, indeed the artwork I used to illustrate my text above is all taken from games I’ve not yet finished, and there are plenty more. But I never sit idle. I do at least work and release. If I’m not making a game, I’ll write, and if I’m not writing I’ll help out in a forum. If I’m not in there maybe I’ll be playing a little Counter Strike. The point is that I feel I do balance them well, one doesn’t over-power the other. I just wish I had more hours in the day 🙂

    That’s me done with, now onto 13 other developers for their views on this subject …

    Read More

More posts to tickle your grey matter ...