- TextField.text can't be set to a number or object, only a String (unlike trace() for example, which will toString() anything you throw at it). There is no logical reason for this that I can see, and makes for some ugly code with String() casts everywhere. You can't really get around it by extending TextField either, if you want a designer to be able to manually move the textfield on the stage in Flash, which I always do.
- You can't tell if a key is down. I don't agree that this is a security threat, and it's a pain when you're doing games.
- No access to stage before addedToStage. I can't really see the reason why this is the case, and it can make code a lot more verbose, as you can't use stage in your constructors, leading to an extra layer of listeners and complexity. And it's worse if you're not actually extending DisplayObject. In my view, stage is a natural Singleton, and generally I treat it as such nowadays by keeping a static reference in one of my classes.
- Events and all those string constants. I always thought there was something fishy about ActionScript events (like how many custom ones you need), and the brilliant example set by Robert Penner's Signals has proved it to me. I've been using Signals on my latest project and filing bug reports (and the odd fix), which Rob pretty much always implements within a day. This is an awesome open source project that gets better by the day - you will never want to use Events again!
- You can't tell if the mouse is hidden. Why have a Mouse.hide() without Mouse.isHidden? It makes no sense, and if you call Mouse.hide() repeatedly it makes the cursor flicker, which again I can't understand as Flash should know not to hide it if it's already hidden. I have created a simple MouseManager class to get round this, but again, why should I have to. Also, I think there is a potential issue around right-clicking showing a hidden mouse without notifying you. While we're on the subject of the mouse, for games you really want to be able to set the cursor position, as you can I think in Unity3D, and have a truly custom right-click, as you can in Silverlight 4.
- The video API is just wrong. Do you know your netstream from your netconnection? None of these things make sense. It should just be videoPlayer.play("video.flv") right?
- The timeline can't destroy movieclips, only remove them from the stage, and if they have any listeners they can't be garbage collected, so playing timelines is a memory leak minefield.
- There are no convenience functions for anything, anywhere. Thanks guys.
Monday, 30 November 2009
8 things that annoy me about ActionScript3
Thursday, 12 November 2009
Using Git and Github on Windows
- Download and install "msysgit" from http://code.google.com/p/msysgit/ (from "featured downloads" on the right of the screen). This provides the core command-line Git functionality.
- To make life easier, download and install Tortoise Git from http://code.google.com/p/tortoisegit/ which is just like Tortoise SVN, which I use for SVN, and works great. It's completely visual and feels like native part of Windows.
- Download and install Putty and PuttyGen (I selected the installer for the full suite because I'm not sure exactly which things you might need) - you'll need this to generate an SSH key. http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
- Create an account on GitHub - https://github.com/
- Create a repository on GitHub.
- In "Account Settings" on GitHub, click on "SSH Public Keys" and add a new key. The title should be your email address. To generate the key itself, use PuttyGen, which you downloaded earlier, and copy-paste it in.
- Right click in the folder which you want to check-in to Git. Select Git Create repository here. Create it.
- Right click in the folder again. From the right-click menu, select Tortoise Git - Settings.
- Make sure Tortoise Git has found MSysGit.
- In Git - Config, add your name and email address - this should match your GitHub settings.
- In Git - Remote, select Add New. Add the private key from Putty that you generated earlier. The private key is a file rather than something you copy-paste. Get the URL and name from the "Source" or "Admin" tabs of your repo on the github website.
- Select all the files you want to check-in, right-click and select Tortoise Git - Add...
- Right click again and select Tortoise Git - Commit -> Master.
- Hopefully it should all upload and you're done!
Wednesday, 11 November 2009
Game Review: Bloodwych (Amiga, Atari ST)
Two people could play it at once, which was revolutionary at the time, and stopped my brother just punching me until I gave him the joystick. 2-player RPGs are brilliant (my wife and I had a blast playing through Balder's Gate Dark Alliance - certainly more fun than watching me ride my horse around Oblivion for hours at a time).
This is the bit where you choose your characters. My brother, of course, took the cool looking knight guy, the cool hooded wizard guy, the hot blonde chick and the cool looking ninja guy. That left me with a blue hermaphrodite thing, Sinbad, a smurf and a f***ing lizard. I didn't care though - this was the coolest thing I'd ever seen!
You can scoff at the graphics all you want, but most people were still playing 8 colour C64 games, so this is basically the f***ing Matrix. My brother soon found that he could threaten to beat me up inside the game unless I gave him all the best loot: basically he invented cyber-bullying 10 years before there was a word for it. I specifically remember one of my guys having to fight with a chicken drum stick.
We played Bloodwych every day and within a few months we had completely worn out the disk and both of the Atari's notorious joystick ports, so we never got to see the cool looking monster on the cover art, which probably wasn't even in the game because cover art was just lies back then.
Monday, 2 November 2009
Game Developers Radio podcast - Flash game design special (with me!)
Video of my talk from Flash On The Beach
FOTB09 - Elevator Pitch - Iain Lobb from John Davey on Vimeo.
Wednesday, 14 October 2009
My thoughts on Flash for iPhone
I was definitely in the “this is neat” camp when I heard the announcement – and here’s the reason: I’m maxed out. I have a list of over 40 ideas for new Flash games, plus probably another 40 old engines that I just need to reskin and launch. This is in addition to all my client work. Then there’s Unity3D which I have been investigating as a route into 3D games, which also requires that I brush up on my 3DS Max skills and C#. On top of all that there’s keeping up with Flash, updating my blog, giving talks etc, and that’s before I even consider my family life and anything resembling a social life. So really learning real iPhone development for the sake of joining the gold rush isn’t even an option or choice for me. But I do have the time to resize the odd game and test it for iPhone, and that’s what I’m going to do. Apple haven’t lost any business from me.
Monday, 28 September 2009
A 3 minute lesson in game design (my talk from Flash on the Beach 09)

Make it fun.
- When you're making games it's easy to get side-tracked by your awesome code framework or particle effect or whatever,
- but if you don't make a fun experience for players, what's the point?
Make it obvious.
- If you need to have an instructions screen on your game, you've already kinda failed.
- Talk to your players through the language of games.
- When you get the power-pill in PacMan, the ghosts go blue, their mouths go wobbly, they start running away.
- The player thinks – ah that's different, maybe I can eat ghosts now – ah yes I can. No instructions necessary.
- Players browse web games like they're flipping channels on cable TV.
- If they're on a site like Kongregate they've got the choice of 18 thousand games.
- So forget all the cut-scenes, menus and tutorials, get straight in to the action.
- Try not to mix mouse and keys. Pick one.
- If you're making a casual puzzle game, just use the mouse.
- If it's a platform game, stick to just arrow keys and spacebar.
- Only if you're going for a pretty hardcore audience is it safe to use mouse and keys together.
- I've worked on far too many projects that had months of planning, emails to clients, design documents, wire frames, PhotoShop mock-ups.
- Not until two weeks before the deadline, you actually start developing.
- The day before the deadline you finally finish it and play it through. Is it fun? No. But it's too late change it.
- So throughout the process, make prototypes, iterate.
- There aren't many games that can survive without characters,
- so even if you're making an abstract physics puzzle, you should be thinking about how you can make it feel human and approachable.
- While there's still time to make changes, put your game in front of real players.
- If you think you've got intuitive controls, players will be mashing the keyboard going “what do I do”?
- If you think it's too easy, to a new player it's probably impossibly hard.
- Don't just make games with Flash, make games for Flash.
- Flash games have there own genres, like physics puzzles and tower defence that have evolved to suit the medium.
- Don't copy other games, but work out what makes them fun.
Monday, 7 September 2009
I'm doing 2 talks in Brighton
- Tuesday September 8th 2009 - The Flash Game School of Wizardry, a mammoth 2 hour live-coding session, where I will be going through my personal philosophy and methodology for creating games. Free! Sign-up at FlashBrighton user group.
- Tuesday September 22nd 2009 - Wizard Needs Food Badly: A 3-minute lesson in game design, a lightning fast top 10 countdown of game design tips. Get tickets from Flash on the Beach.
Thursday, 27 August 2009
Podcasts for designers and developers
- Specifically focussed on the Flash Platform, there is only really The Flex Show and (I'm guessing for a limited time) also Summer of Flash. We have a great blogging community, so there should really be more. For Rich Internet Applications in general, there is also RIA weekly.
- The .NET world is frankly spoiled for decent podcasts, with Elegant Code, Hanselminutes, Herding Code, .NET Rocks!, Spaghetti Code and The Thirsty Developer. I normally skip the epsiodes devoted to the minutiae of .NET and listen to the more general chats about programming techniques, best practices etc.
- For Java, I've only really come across Java Posse, but it is excellent, and covers a broad range of topics, not just Java.
- Boagworld is really the one and only listenable podcast I've found about web design - like Flash this is a topic that I thought would generate more content.
- About programming in the general, there is the excellent Stackoverflow podcast with Jeff Atwood and Joel Spolsky, two very smart and funny developers.
Tuesday, 25 August 2009
Are you a Flash outlier?
- Age. What's the ideal age to be a successful Flash developer? From my observations, most the well known developers in the blogosphere and conference circuit are between about 32-38, meaning they were born between about 1971-1977. This is also the age range of most the CEOs, CTOs and Creative Directors of Flash shops, that I have met. Why is this the case? Well, these people were in their mid-twenties when Flash became popular. They had the skills and the life experience neccessary to grab chance, and establish themselves as experts.
- Mix of design and development skills. In the early days, there weren't really designers and developers in the Flash world, there were just "Flashers", so to have a mix of both skills was a definitely advantage. I'd argue that Flex changed all that, and largely for the worse.
- Able to work in Western Europe or North America. Flashers seem to congregate in certain geographical areas, such as California, South East England and Toronto. While there are Flashers in many other places, these areas are a great place to start your career because it's much easier to find work.
- Education. Happily I don't think it makes a huge difference where or even if you went to college. Flash is a real meritocracy in this respect.
- Able to write English well. Many of the most well-known Flashers are probably not the greatest developers out there, but they are able to communicate what they know effectively and this brings it's own rewards.
Tuesday, 7 July 2009
C# envy: properties
public int x { get; private set; }
Or if you want both public, it would be:public int x { get; set; }
private var _x:int;
public function get x():int
{
return _x;
}
public function set x(_x:int):void
{
this._x = _x;
}
Monday, 6 July 2009
A new manifesto for Flash games

Danc over at Lost Garden has just released an inspiring call to action for Flash games developers. This is probably the most important thing I have read about Flash games, ever. In it he makes a good case for something I've known for a while - that the ad-funded Flash games business model undervalues developers efforts by a factor of 100! If you don't want to read it, the jist is that indie Flash games creators need to grow a pair and start asking for some money. But I suggest you read it.
Thursday, 25 June 2009
Suggestions for RSS feed of Flash game developer blogs, and a look a Yahoo! pipes

Wednesday, 24 June 2009
Open-source ActionScript libraries for creating Flash games
- Glaze - super-fast, easy to use rigid body physics engine based on Chipmunk. Prettier syntax than box2D. Demo.
- Box2D - uglier (sorry) syntax than Glaze, but has more features (e.g. types of joint), and is better documented.
- PushButtonEngine - framework to build games on - doesn't do too much out of the box, but is an admirable attempt to standardise Flash game code structure. Demo.
- Collision Detection Kit - Pixel perfect collisions in Flash!
- Game Poetry (blog) and CheezeWorld (blog)- these excellent blogs post the source for many of their examples and tutorials on google code.
- PixelBlitz - engine for retro -stylee games. Blurb from Photon Storm.
- Flixel - another retro-engine. Cool Demo!
- PaperVision3D -if you want to go into the third dimension, this is the daddy. Also check out Away3D - it has some features that haven't yet made it to PaperVision3D. Hey, different strokes for different folks!
- Jiglib Flash - Physics in 3D!!!
- TweenMax - since fusekit was was sadly never ported to AS3, this tweening powerhouse has taken over the whole show. Not only is it great for animating your user-interface, menus etc, I have actually built whole minigames using only this library for all movement and animation. Also gives you quick ways to adjust brightness/contrast etc of images. Only downside is that it is time-based only so won't play nicely with your game if it has a frame-based tick - but this option has been added to the beta, and as you read this is probably now in the live version. If you need frame-based tweening, you can also check out GTween, although Grant is discontinuing the project.
Monday, 15 June 2009
Better rollovers in PaperVision3D
Friday, 22 May 2009
62% of developers are using FlashDevelop? That can't be right!
(It doesn't).
The poll is over there >>>
Monday, 18 May 2009
Unity3D hands-on first impressions
Today I got together with my buddy Adrian who is a big-shot special effects guy, with the aim of trying to punch through the Unity3D learning curve and get some kind of game going. (Adrian is using the Mac in the photo, and for fairness I should point out that he was pulling that face as a joke). Adrian does Maya so he was able to grok the Unity IDE much quicker than me, as there are a lot of keyboard shortcuts you need to know (e.g. press "F" to focus the IDE on a selected object). I, on the other hand, had installed Visual Studio C# Express, so I had intellisense for coding :)
Here is my effort - MatrixPong. I had intended to post the actual game, but it crashes Firefox (see below), so I thought I'd give it a miss. All in all it was a very worthwhile session, and here's what I learned:
- You really do need to learn the Unity IDE shortcuts, e.g. Q, W, E & R to switch between tools, F to focus on the selected object, ALT-DRAG to rotate camera around object, drag with right button to point camera.
- We could find no way to look through our camera in the scene view which was annoying.
- If you edit the scene while you have the game running or paused, as soon as you stop it reverts all the changes you made. This is a massive gotcha and you can lose a few minutes work every time you forget your game is running.
- Errors in you game can easily crash the Unity IDE and the browser plug-in. In fact they don't even have to be code errors. For example, in MatrixPong, when the ball goes off the edge of the playing surface, it will fall with gravity for about 10 seconds, then when its position reaches a big number (e.g. y = -1000000000) everything suddenly crashes. For a Flash guy this is a real WTF. Imagine if setting your movieclip too far off the stage crashed the browser!
- You get loads of stuff "for free" in Unity, most importantly collision detection and physics - this is a big advantage over the other 3D game development framework I have played with, Microsoft XNA.
- The documentation for scripting isn't that great and it's all JavaScript not C#, although all the method names are the same so it's pretty easy to convert in your head, you just can't copy paste. C# is a great language, but if you don't already know it, it might confuse you. For example you can't type "x = 1.173" if x is a float. It has to be "x = 1.173f". I have never understood this, but there you go.
- Thanks to Lucas Meijer I was able to set up Unity3D code completion in Visual Studio. Very cool.
- Everything in Unity3D C# extends MonoBehaviour and relies on overriding a bunch of event functions, e.g. Update and OnCollisionEnter. You don't actually use an override keyword though which makes it hard to know from example code whether functions are built-in or not. I couldn't find a good way to get a list of these functions while typing code though, I had to look them up from the website.
- MonoBehaviour has tons of stuff in it and I only scratched the surface of what it can do.
- There's also a big global god object called GameObject where you can find things from your scene. There are lots of global, not very OOP things in Unity. Get over it!
- Pointless observation: MonoBehaviour has a British spelling for behaviour, the first British spelling I have ever seen in a language API.
- I created 3 scripts - PongBall.cs, PongPaddle.cs and PongAI.cs. Each script was only about 5-10 lines of code, but that was enough to get the ball bouncing back and forth, the AI paddle following it and the player paddle controlled via keyboard. You drag these behaviours onto your game objects rather than having game objects that extend them. Objects have scripts rather than are scripts like they would be in Flash. Basically it's like Director, but in a good way.
- To devote the necessary time to get really into Unity I would need a paying gig, so could someone please hire me to make something with it? Thanks!
Friday, 15 May 2009
Could Flash autogenerate classes from IDE information at design-time?
Here's a "what if" post for any developer who works with the Flash IDE. Something that often bugs me is that when you want to access DisplayObjects which have been placed on the timeline of a MovieClip, you don't know what DisplayObjects are there, or their type. For example, say you have an animation, and nested 3 MovieClips deep in the animation is a "hand" MovieClip. You can access the clip with "throwAnimation.leftArm.hand", but while you are developing you can't be sure that this path actually exists, and you won't know the type of "hand". If you want to call a function in hand, you might end up doing something like: "Hand(throwAnimation.leftArm.hand).closeFist()". It works, but again you don't know while you're typing that "hand" actually is an instance of the Hand class.
One solution might be to create a ThrowAnimation class, an Arm class and a Hand class and set the linkages of each MovieClip in the library. These classes would simply contain public variables for the DisplayObjects they contain. Then you can happily type: "throwAnimation." (hit CTRL-SPACE in Eclipse) and your code editor will give you a drop-down menu showing all the variables of throwAnimation, including leftArm, hit ENTER and then get a list of leftArm's properties, including hand. The only downside is, you have to create 2 more classes just to get autocompletion.
Thinking back to my days doing Visual Basic, I think I remember that it autogenerated some code every time you added a button to the design view. Flash just needs to do the same thing. Think about it - all the information it needs is right there to autogenerate classes which know what DisplayObjects they contain and their type. It can get the instance names from the stage and the type from the Library. Then we happily know while we code that we are accessing DisplayObjects that exist. I think this is basically the same idea behind MXML and XAML - so maybe what we need is a just an XML-driven FLA format in CS5? Any thoughts?
Tuesday, 5 May 2009
Do you extend or compose Sprite, MovieClip and DisplayObject?
On my journey to try and be a better developer, I'm questioning some of the fundamental ways I work and organise code. Like most Flash developers (I think), I normally extend Sprite or MovieClip when I want to control something on the stage. But would I be better off creating a class that composes (i.e. controls via a reference) a Sprite or MovieClip instead? What are the advantages and disadvantages? Which are you doing? Leave comments please!
Monday, 4 May 2009
Game framework architecture - view components or MVC?
I'm trying to build a very light reusable framework for my games, rather than starting from scratch each time I start a game. I have a component driven architecture - e.g. Entity model composes a Position component, a Health component, an Ai component, etc.
My big question is whether my model composes view components to allow for more than one view of the model, or whether to use a truer MVC where the model does not know about its views, and they are managed externally.
I have tried both methods but if anyone knows the pros and cons of each approach and which is the industry standard, it would be great to know. I'd particularly like to hear from people who have tried both methods.
Wednesday, 22 April 2009
Creative Commons is a tease!
- Pretty much everyone is using the non-commercial license
- Because of things like Adsense, pretty much everything is commercial
Case in point: I love this set of CC sprites by Philipp Lensenn

They are brilliant, but to describe them as FREE as is misleading, because they're under a non-commercial license. Basically they're free, as long as you don't really want to do anything with them.
What's the solution? More people should use the commercial licence. But it wouldn't really be fair to, say, make a hit game and a bunch of money without any going to the artist. A better solution - contact the copyright holder and make a deal to share the money. But that scenario is no different than if the images had no CC license at all.
My solution:
We need to come up with some kind of "revenue share" license, like the royalties radio-stations pay when they play songs on the radio. This way the artist would get a cut, but you wouldn't have to contact them BEFORE you use their work, only once the money rolls in. Would it work? Who knows, but at the moment artists like Philipp might be missing out on a chunk of change because game developers are afraid to use his sprites for fear of breaking the terms of the license.
Thankfully, most code libraries are MIT licensed, which is very permissive, so you don't run into this problem with code. And don't get me wrong - so far I haven't personally CC'd any of my own artwork, but maybe if there was the chance of getting some pocket money from it, I probably would.
Monday, 20 April 2009
Flash Games: dimensions, resolution and screen size
High Resolution (i.e. 800px+ in width, often full-browser or even full-screen)
Positives:
- More immersive.
- Occupy a decent percentage of a high-resolution monitor.
- More room for gameplay elements and user interface.
- Greater detail possible in artwork.
- Artwork right-size to port to console
- Slower performance.
- No keyboard support in full-screen before FP10.
- No room for anything else on the page.
- May not actually fit on monitors of netbooks / older computers.
Positives:
- Much faster performance / less variation between new and old computers.
- Leaves room to sell advertising around the game (decide for yourself if this is a good thing).
- More flexibility for use on HTML pages - e.g. "Add this to my site" embedding etc.
- Pixel art looks better in low-res games.
- Artwork right-size to port to mobile / iPhone
- Games get completely lost on high-resolution monitors, especially laptops where the pixel-density can be much higher (e.g. on 15inch screen with a 1800 pixel width, the average Flash game is only a couple of inches wide)
- Less immersive, further away from the console experience
But hold on a minute! Flash is a re-scalable technology, right? So can't we make games that work at any size? Well, yes and no. Vector graphics scale nicely, but performance suffers at higher resolution. Bitmaps scale up smoothly but aren't so great scaled down (Remember to turn allow smoothing on in your library and/or code!). For pixel art there is the option of turning smoothing off, too. There is hardware scaling on full-screen mode, but text and some graphics start to look a bit strange to me. I think the ideal situation might be to be able to build your game at 1280x720 (720p) and scale down to the correct window size. This is how XNA handles both HD and SD TVs when publishing for Xbox. I don't think the current generation of computers is quite up to this in Flash though, without hardware acceleration. In general Flash does do a much better job at upscaling than you would expect, and if you build with rescalability in mind, it's a bit more work, but you can generally pull it off. Portals should maybe start offering the option to have alternative resolutions - like Flashkit used to!
Do we mind playing tiny games on our huge monitors? Should a Flash game be thought of more like playing a gameboy or iPhone within a window than a playing a traditional PC or console game? Leave your thoughts in the comments please!
Tuesday, 14 April 2009
Scarygirl: a game-changing Flash game

I have a bit of an inferiority complex when it comes to Flash as a games platform. I know from experience that Flash is a great tool for creating games, but I still can't stop myself looking for the next thing: XNA, iPhone, Unity3D, etc, etc. Maybe it's the lack of joypad support, maybe its the small window size, but something about Flash games just never seems as impactful as a console. I was trying to compose these thoughts into a blog post, when Scary Girl landed in my Twitter feed (follow twitter.com/iainlobb by the way). And wow is all I can say really. This is just awesome, and proof if proof were needed that Flash is the real deal for games. So I'm going to get over my tech envy for now, and replace it with some creative envy for this game... brought to you by the Australian tax payer I believe :)
Thursday, 2 April 2009
PushButton Engine - a game engine for Flash. But will anyone use it?

First off, I recommend you go over to Jeff Tunnel's blog if you want a great read about the business of independent games. Jeff knows a bit about games, having co-founded Garage Games, and his latest venture is PushButton Engine, an open source game engine / library for Flash. I had to re-read the description a couple of times to understand what they're trying to do, but basically it's an MIT licensed AS3 library with pathfinding, physics etc, that they eventually plan to make money from by selling add-ons to developers.
I've thought for a while that Flash gaming needs something like this, to make it is easier for newcomers to create more advanced games. So my first question is - who's the target market? And I guess the answer is I am, since I make my living from Flash games. But here's my problem with that idea - surely anyone who knows enough about both Flash and game development to find this project, learn the API and make a decent game can already apply these concepts through their own code? Potentially this project could save you a lot of development time (for example I wouldn't devote months to creating my own rigid body physics engine) but some of the mechanisms it includes, such as health, teams and spriting are so intrinsic to a game, that I could easily see a developer fighting against the API. There's also a multiplayer API in the works, but that market is already saturated with decent products (although I believe there's still a gap in the market for an unbranded, hosted multiplayer platform).
I'm going to give the engine a good test when I find some time, so stay tuned.
Thursday, 19 March 2009
Please help me give away my source code!
Post answers and links in the comments PLLLLEEEEEEEEEEASE.
Help me Flash RSS junkies, you're my only hope.
UPDATE:
Here is a test of using http://formatmysourcecode.blogspot.com
public static function formatTime(seconds:int):String
{
seconds %= 86400;
var hours:int = seconds / 3600;
var minutes:int = (seconds / 60) - (hours*60);
var secs:int = seconds - (hours*3600) - (minutes * 60);
var timeString:String = ((hours<10)? "0"+hours : hours)+":"+((minutes<10)? "0"+minutes : minutes)+":"+((secs<10)? "0"+secs : secs);
return timeString;
}
Friday, 6 March 2009
10 reasons I prefer FlashDevelop to Eclipse and FDT
So here's 10 reasons I prefer FlashDevelop to Eclipse:
- FlashDevelop is free. FDT is quite expensive.
- FlashDevelop starts auto-completing as soon as you start typing. In FDT you have to type "this." to get the auto-completion menu. UPDATE: Sorry, you can also press CTRL-SPACE, but it's still an extra step.
- FlashDevelop automatically adds import statements. Eclipse doesn't, as far as I can see. UPDATE: I think it should have done but was badly configured on the Mac I was using.
- FlashDevelop's project window automatically finds new files. In Eclipse you have to add the folder manually, then tell Eclipse it's a source folder. UPDATE: Again, this was partly due to bad configuration, but Eclipse convoluted enough to let this happen easily.
- FlashDevelop projects can be moved around easily. Eclipse has confusing hidden project files.
- FlashDevelop renders fast. Text in Eclipse has a delay before formatting correctly. UPDATE: This is probably down to the beat-up old Mac I was using ;)
- FlashDevelop has a cute quick-find search box. I couldn't find this in Eclipse.
- FlashDevelop has zero learning curve - I picked it up instantly. I have wrestled with Eclipse for a week and still don't feel I've cracked it.
- CTRL + ENTER in FlashDevelop switches to the Flash IDE and publishes. Eclipse doesn't do this. UPDATE: Can be done with a free plug-in. Probably better to use FlexSDK and asset SWCs anyway.
- CTRL + the mouse wheel changes the text-size in FlashDevelop. I had to use google just to work out how to change the font size in Eclipse!
Monday, 2 March 2009
Flash development - are you doing it wrong?
- Don't use code for layout. If you are setting the position of all your visual elements with code, rather than using the Flash IDE, you are doing it wrong. Designers like to "nudge", "align" and "tweak" layouts, and if you have to change a number in your code and republish the swf for every nudge, then you're probably in for a long night. If you have a data-driven site (e.g. with a variable number of menu items), you may have to do some dynamic positioning, but keep it to a minimum.
- Don't write code on the timeline. Why? Because you can't search it, open it in an external code editor, version control it or merge it, that's why! Version control and a decent editor (ie. Flexbuilder, FDT or FlashDevelop) will save you many hours of development. These editors have great auto-completion features, and a version control system such as subversion may just save your job one day - when Flash corrupts your FLA or you accidentally overwrite your whole day's work. The only good reason to write timeline code is calling functions or dispatching events during timeline animations (e.g. dispatchEvent(KICK_BALL) when the animation of the foot reaches the ball), but again, keep it to a minimum.
- Write lots of small classes. When transitioning from timeline scripting to OOP, a classic mistake is to make one or two big "god" classes that control most of the functionality. If you're doing this you haven't really transitioned to object-oriented code at all. Each class should do only ONE thing, or to put it another way, there should only ever be one reason to change any of your classes. This seemed very prescriptive to me at first, and I still find it difficult, but I've learned to love it! How long should a class be? Well anything more than about 500 lines seems like it could be broken down more. In any particular project I normally have at least a few classes that are only 5-10 lines long. Think about your project as a set of self-contained components that you could re-use if you wanted to.
- Use ActionScript3 whenever possible! I've met a couple of people who are still defaulting to AS2 for "simple" stuff. Er, why? Better to get your head into AS3 mode as much as possible, especially on the easy stuff. How else are you going to learn? AS2 is rubbish! You may still have to use it for some banner-ad networks, etc though :(
- Don't use the main timeline to organise the "flow" of your site. I used to swear by this method as a way to organise my sections - creating a separate class for each screen, and putting each screen on a different frame. Move to a different frame and Flash will automatically destroy the old section and create the new one. Easy! Only problem: doesn't work in AS3! It will remove the section from the display list, but it will stay in memory, running its ENTER_FRAME, probably throwing errors, and generally doing the naughty. The solution? Create and destroy all your screens / sections from code - e.g. mainMenu = addChild(new MainMenu()); removeChild(mainMenu); mainMenu.destroy(); etc.
- Tidy up after yourself. Keep your FLA tidy. Name your layers, name library items sensibly and keep them organised. Delete empty/guide layers. At the end of the project, delete all your traces, unused code, and any commented out code -they will only confuse you later.
- Test extensively. Test driven development for a Flash developer should mean running your swf and clicking on everything really fast until it breaks, then fixing it and doing it again. The more complex the application, the more ways there are to make it do something unexpected, throw and error, or generally crap-out.
- Know how good you are. This one goes a few different ways. On the one hand, don't be cocky and let your ego write checks your body can't cash. Don't commit to mad schedules or deadlines. Make sure there's contingency time built into every project, because you can pretty much guarantee something will go wrong at some point. On the other hand, don't be lazy or complacent. Don't look for excuses not to change your code or design. If a colleague suggests an improvement, don't just go "No, it doesn't work like that", but think seriously about the cost/benefit of the idea. Keep improving your knowledge and learning new technologies, because if you don't, the industry will eventually leave you behind. Know what you're worth. If your boss is driving round in a sports car while you do all the hard work, you're probably doing it wrong.
- Don't use anything obscure. Sometimes I'll make an update to a project that was created by another developer, and I'll experience some weird behaviour, missing files or unexpected errors, and it will because the developer has chosen to use some obscure feature of ActionScript or the Flash IDE. In Flash CS3, it might be menu settings like changing the view preview quality and everything on the stage looking weird, or turning off "export hidden layers" and half your site unexpectedly disappearing. Everyone SHOULD turn OFF "Automatically declare stage instances" though, as it's very confusing to not have all your variables explicitly declared. Try not to use weird language features and optimisations, like backwards loops unless they're completely necessary. Name your functions and variables with full English words please! That includes writing "event:Event" instead of just "e:Event". How can you search through text for a one-letter variable?!
- Sweat the details. Polish counts for a lot in Flash sites, so the more time you can devote to little finishing touches, the better. Consider things like: fading in-and-out on page transitions rather than just jump-cutting from one page to another, adding custom options to the right-click menu, disabling the Tab key, optimising the file size and creating a decent preloader.
Thursday, 5 February 2009
I'm now available for freelance Flash work

It's a new career direction for me - from next week I will no longer be with Bloc and will be available for freelance Flash work, so if you've seen what I do and would be interested in working with me, please feel free to give me a shout at iainlobb[at]googlemail[dot]com
I've had a brilliant 4.5 years at Bloc, but I'm excited about getting out there and working with some new people, and maybe even fitting in some of my original gaming ideas too. Wish me luck everyone!
I've done a quick relaunch of iainlobb.com, to show some of my favourite projects while I work on a more creative portfolio site. Ooh, also I'm on linkedin now, so if we've met you can look me up on there too - http://www.linkedin.com/in/iainlobb
Thursday, 29 January 2009
Cheezeworld - another great blog about making Flash games

Following on from yesterday's recommendation of Game Poetry, here's the excellent Cheezeworld blog, with in-depth discussions on game Entity frameworks, collision detection, game Maths and lots more, with loads of great source-code for you to, err, borrow...
Wednesday, 28 January 2009
Game Poetry - absolutely the best blog about making Flash games

How did I miss this one? The Game Poetry blog has literally dozens of great articles about creating Flash and/or games. Sensible advice combined with a nice writing style make Urban Squall's little blog a great read. More like reading a book really, but in a good way.
Tuesday, 27 January 2009
Super ActionScript3 optimisation and a type-safe tweening engine - goodies from Shane McCartney

A couple of months back I worked on a project with super talented Flash developer (and all round nice guy) Shane McCartney. A few days ago I read his blog for the first time and found some awesome stuff on there including Tweensy - a type safe and super-fast tweening engine and not one but two great posts on optimising ActionScript3 scripts for better performance. Cool stuff!
Thursday, 22 January 2009
Unity3D for PC - I, for one, welcome our new 3D overlords!

I'd heard this from an "insider" a while back, but now it's official (thanks Ryan) - Unity3D development is coming to PC. 900% more developers should mean 900% more games, which will lead to client and user acceptance of the technology. For some of the work I do, at least, it will mean an end to worrying about poly-counts and clipping bugs, and more time to make cool games! Sweet.
Wednesday, 21 January 2009
JavaFX - first impressions from a Flash developer (me!)

First impressions of JavaFX, having used it for about an hour. Can't be bothered with proper sentences for this! Here's the bullets:
- The code IDE - NetBeans 6.5 - is great.
- There's no visual editor that I could find - export from PhotoShop, Illustrator. For free versions try Paint.NET and Inkscape.
- The language (JavaFX Script) seems like MXML and ActionScript rolled in to one language. A very different programming model to how I work. You never really write thing = new VisualThing(30, 20), it's all done with literals, so more like thing = VisualThing{param1:30, param2:20}.
- That takes some getting used to, but I imagine if there was a good reason to use JavaFX for a project I'd be fine.
- Certainly much easier to get started with than normal Java applets.
- You can also use straight Java classes.
- The plug-in update experience is still pretty horrible compared to Flash and even Silverlight.
- Lots of the demo's are using Java Web start, which is also horrible.
- Couldn't find anything about easy embedding - what's the Java version of swfobject?
- Run-time performance seems fine and renders graphics nicely.
- This technology has picked up seemingly zero traction amongst Flash community. Maybe will be a slow burner like Silverlight? Certainly Sun haven't thrown loads of money at Flashers like they did with Silverlight. (They probably can't afford to).
- I hope it's not a flop because competition within the plug-in space can only be a good thing, but we'll see.
- Nice range of 2D effects like we got with Flash 8 - drop shadow, blur etc
- No 3D as yet, but it's on the roadmap.
- Properly free and Open Source I think.
- You can also develop Flash / Flex for free with MXMLC compiler, so that's not a reason to use over Flash.
- Mobile version coming soon - don't know which platform supported yet - not iPhone or Android so who cares!
- Now that I've sniffed around it I have no reason to use it, so back to Flash for now! Wish Sun the best of luck, because the technology actually seems ok.
Monday, 19 January 2009
Notes on Designing and developing multi-user Flash games

I was very pleased this morning to see that an attendee of my recent FlashBrighton talk on creating multi-player games has written up some very comprehensive notes, so if you want to know what I talked about, head over to ELECTROBUNNY's blog right now:
Read attendee notes on Designing and Developing Multi-User Flash Games.
If I get time I'd like to write it up myself, but who knows if I will, so enjoy!
Friday, 9 January 2009
Designing and developing multi-user Flash games - my session at FlashBrighton on Tuesday (13th January 2009)

Seb of FlashBrighton / PaperVision / Plug-in Media fame has very kindly invited me to talk at the FlashBrighton user group, so I will be pontificating on multi-player games (like Zwok, above, the game I developed for Bloc/Sony) on Tuesday. Here's the details:
Iain will tell you everything you need know to start creating multi-user Flash games: from a humble high-scores screen to real-time game-play and persistent worlds. He'll show you design and development lessons learned from real-world projects. Specific topics will include:
- Choosing a server platform;
- Sign-up and log-in;
- Community and chat;
- Game lobbies and match making;
- Turn-based vs. realtime gameplay; and;
- A look at which kinds of games are most suitable for multi-user play.
Tuesday January 13, 2009 at 7:00pm
Check out the upcoming page for more info.