Monday, 30 November 2009

8 things that annoy me about ActionScript3

  1. 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.
  2. 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.
  3. 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.
  4. 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!
  5. 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.
  6. 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?
  7. 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.
  8. There are no convenience functions for anything, anywhere. Thanks guys.

Thursday, 12 November 2009

Using Git and Github on Windows

Github is all the rage for source control / hosting OpenSource projects right now - which is a great thing, because for end-users who just want to grab a .zip file of the code or report an issue, it's really easy to use. If you want to check your code in to Git though, and you're on Windows, it can be hard to know where to start. I just went through the process of setting it up, so I thought others might find this useful. Here's the steps I took:
  1. 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.
  2. 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.
  3. 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
  4. Create an account on GitHub - https://github.com/
  5. Create a repository on GitHub.
  6. 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.
  7. Right click in the folder which you want to check-in to Git. Select Git Create repository here. Create it.
  8. Right click in the folder again. From the right-click menu, select Tortoise Git - Settings.
  9. Make sure Tortoise Git has found MSysGit.
  10. In Git - Config, add your name and email address - this should match your GitHub settings.
  11. 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.
  12. Select all the files you want to check-in, right-click and select Tortoise Git - Add...
  13. Right click again and select Tortoise Git - Commit -> Master.
  14. Hopefully it should all upload and you're done!
Don't ask me any difficult questions, because I'm surprised I got this working myself, but good luck! I'm liking Git so far.

Wednesday, 11 November 2009

Game Review: Bloodwych (Amiga, Atari ST)

Like most things, RPGs were better in the 1980s. Take Bloodwych; I re-read the review of this game in ST Format about a hundred times because I didn't believe anything could be so brilliant. I bought it "mail-order": this meant that for no good reason it took 28 days to turn up, and you couldn't even complain about it on Twitter because it hadn't been invented.

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.

Of course, because it's dead old you can play it free now by finding a ROM and an Amiga emulator. Enjoy!

Monday, 2 November 2009

Game Developers Radio podcast - Flash game design special (with me!)

I was recently on a special 2 hour edition of The Game Developers Radio podcast with host Joseph Burchett, Ryan Henson Creighton of Untold Entertainment, Daniel Cook of Lost Garden and indie developer Edmund McMillen. It was a great laugh to record and has some great pointers about making Flash games too - I learnt a lot recording it, hope you get just as much from listening, so listen here.

Video of my talk from Flash On The Beach

As I blogged previously, I gave a 3 minute "elevator pitch" at Flash on The Beach this year. I've already posted my notes and slides, and now for your viewing pleasure, here is the video:


FOTB09 - Elevator Pitch - Iain Lobb from John Davey on Vimeo.


You can see more elevator pitches and some other great talks by the likes of Grant Skinner and Mario Klingemann at:


Wednesday, 14 October 2009

My thoughts on Flash for iPhone

Keith over at bit-101 just published a very thoughtful post on the newly announced Flash to iPhone publishing. I wrote a reasonably long comment, so I thought I'd just do a quick republish here. These are my thoughts:

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)



Update: You can now watch the video here.

I'm back from Flash on the Beach in Brighton. There are loads of great write-ups of the conference coming out, so you don't need another from me, but here are my slides and notes from my 3 minute "elevator pitch". While I'm writing I will just say it was great to meet all my fellow pitchers, and I think we gave a rockin' session - in the main theatre no less, so probably about 600(?) people saw it. Here's my slides (click on slide to advance):



Here's what I said:

I'm Iain, I make Flash games. Here are my tips for making Flash games, but hopefully you can apply them to whatever it is you do.

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.
You've got 10 seconds to sell your game.
  • 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.
Match your control scheme to your audience.
  • 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.
Evolve your game.
  • 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.
Stick a face on it.
  • 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.
Playtest!
  • 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.
Respect the medium.
  • 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

Thanks to the tireless work of Seb Lee Delisle, Jo Summers and John Davey, Brighton is totally Flash seminar central these days, and I'm giving two talks very soon in Brighton:
  1. 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.
  2. 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.
Looking forward to both of these. If you'd like a Wizard/Flash related talk at your user-group or conference, drop me an email: iainlobb@googlemail.com

See you there!

Thursday, 27 August 2009

Podcasts for designers and developers

A good way to learn something while you would otherwise be bored commuting or doing the dishes is to listen to podcasts by other designers and developers. There aren't a huge number devoted entirely to Flash, but you can also learn a lot by listening to how people do things in other technologies, so here are some good podcasts grouped by theme. All these podcasts are free; the best way to listen to them is to subscribe in iTunes. You can find most of these podcasts on the iTunes music store, or failing that in iTunes go to "Advanced / Subscribe to Podcast" and paste in the feed URL.
  1. 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.
  2. 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.
  3. For Java, I've only really come across Java Posse, but it is excellent, and covers a broad range of topics, not just Java.
  4. 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.
  5. About programming in the general, there is the excellent Stackoverflow podcast with Jeff Atwood and Joel Spolsky, two very smart and funny developers.
Well, that's all the ones on my battered old iPod - I recommend checking a few of them out. Any suggestions for me? Stick them in the comments...

Tuesday, 25 August 2009

Are you a Flash outlier?

Just finished Malcom Gladwell's book Outliers (in audio form - you think I have time to read a book!?). The book is about success, and how external factors converge to give some people an advantage for success in a particular field. The best example in the book is the fact that in the late 1960s Bill Gates was probably the only teenager in the world to have unlimited access to a computer terminal, thus giving him a massive head-start on everyone else his age. So this got me thinking - what factors give one Flash designer or developer an advantage over another? Obviously no single factor can determine success, but I think the examples listed below don't hurt.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
Anyone else read this book? Can you think of any more factors that come into play? Suggest them in the comments!

Tuesday, 7 July 2009

C# envy: properties

Recently I found out that in c#, if you want to put a variable behind a public getter and private setter, so that it can be read but not changed, you can do it on one line! Here it is:

public int x { get; private set; }
Or if you want both public, it would be:

public int x { get; set; }

In ActionScript3 this would be:
private var _x:int;

public function get x():int
{
return _x;
}

public function set x(_x:int):void
{
this._x = _x;
}
The c# way is so much nicer - feature request Adobe!

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



Since the excellent site FlashGameBlogs, which aggregated many developer blogs, has mysteriously stopped working, I am trying to fill the gap with a new rss feed. I'm using pipes and feedburner. Pipes is one of the most unusual pieces of software I've ever used - a visual programming environment for creating mash-ups - all running within the browser with just javascript.


Anyway, this is the call for requests. Please have a look at the feed and tell me: have I missed anyone? I'm looking for feeds of bloggers who write mostly or entirely about Flash and other web games (e.g. Unity3d) - be that coding, art, business, whatever. Comments please!

Wednesday, 24 June 2009

Open-source ActionScript libraries for creating Flash games

For some reason the incredible power of Open Source is on my mind today. In light of that, here are some open source(ish*) ActionScript libraries I've come across that can help you make games. I haven't tried them all, but maybe you will? *check the licenses before using.

To get code from google code you may have to use a subversion client. On PC use the free TortoiseSVN.
  1. Glaze - super-fast, easy to use rigid body physics engine based on Chipmunk. Prettier syntax than box2D. Demo.
  2. Box2D - uglier (sorry) syntax than Glaze, but has more features (e.g. types of joint), and is better documented.
  3. 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.
  4. Collision Detection Kit - Pixel perfect collisions in Flash!
  5. Game Poetry (blog) and CheezeWorld (blog)- these excellent blogs post the source for many of their examples and tutorials on google code.
  6. PixelBlitz - engine for retro -stylee games. Blurb from Photon Storm.
  7. Flixel - another retro-engine. Cool Demo!
  8. 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!
  9. Jiglib Flash - Physics in 3D!!!
  10. 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.
What have I missed? Leave comments!

Monday, 15 June 2009

Better rollovers in PaperVision3D

I found a little perculiarity in the latest release of PaperVision3D today, and came up with a fix, so I thought I'd post it. The way it currently works, rollovers and rollouts may not be detected if you have a moving camera (which I normally do - hey it looks cooler!).

To fix, all you need to do is open org.papervision3d.core.utils.InteractiveSceneManager and delete or comment out line 236 if ( hasMouseMoved() ) in the handleMouseOver function and line 247 if( !hasMouseMoved() ) return; in the handleMouseOut function.

Now you will get nice responsive mouse events even if you have a nice drifty camera. I have tipped off Seb from the PV3D via twitter so I think those clever people are going to look into it.

By the way, if you haven't tried combining PaperVision3D with TweenMax, I highly recomend you do! I've had some freakin' incredible results that I wish I could post (but I can't).

Friday, 22 May 2009

62% of developers are using FlashDevelop? That can't be right!

That provocative title is just to draw your attention to the voting box over there in the right hand column where you can vote for your favourite ActionScript editor. As I write this, it says 62% of you are using my favourite piece of software, FlashDevelop. I don't really believe this, considering the response I got when I stated my preference for FlashDevelop over Eclipse. So vote please! The future of Flash depends upon it.

(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?

UPDATE: Chalk this post up to my own ignorance - Simon Cave has pointed out that you can basically do exactly what I proposed by just exporting a swc and compiling with the FlexSDK. Obviously that has it's own advantages and disadvantages, but for the sake of this benefit I'm probably going to move over to that workflow. Here's the original post anyway....

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?

I got such a great response from my last help request that I'm posting another:

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 have a question for my learned readers - if anyone has an answer, please leave a comment. Here it is:

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!

I think Creative Commons licensing is pretty cool. If Flickr and CC images had existed when I was at university doing interactive art projects and learning design, it would have been a massive help. But unfortunately, I think 2 factors have aligned to make it a bit useless to me. These factors are:
  1. Pretty much everyone is using the non-commercial license
  2. Because of things like Adsense, pretty much everything is commercial
If you post an image on your blog, and your blog has ads, that's basically a commercial use, right? If you make a Flash game with CC non-commercial artwork, you shouldn't even upload it to a portal, as the portal will sell ads around it and so make money. Look at Aral Balkan's stitch-up by Sys-Con as an example of the mess that CC can get things into. Should I even post CC images on my blog? It doesn't have ads, but isn't it kinda part of my business?

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

What's been on my mind today is the size of Flash games. Not the minutes of gameplay, number of levels or the file size, but the amount of physical screen-size the game occupies. There are 2 competing forces pulling in opposite directions here - the world of slick experiential websites as showcased by thefwa is trending towards high-resolution, full-screen, immersive experiences, and many of these sites are games. On the other hand, there is the world of game-portals and indie-developers keeping resolutions lower, where the game only occupies a part of a larger HTML layout. Here's some positives and negatives of each approach:

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
Negatives:
  • 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.
Low Resolution (i.e. 400-700 pixels wide):

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
Negatives:
  • 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
It's a tricky problem with no right answers. I think a wide-screen format of something like 760x400 works quite well across all devices and is a good compromise. I haven't checked the exact numbers, but many portals are still restricting to around 640 pixels wide, presumably so they can sell add-space around the game and maximise the number of devices that can see the content, and Kongregate needs to fit in their chat window, for example. I think this restriction is a bit of a shame.

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!

I have loads of great ActionScript snippets that I want to share with the Flash community. Unfortunately I cannot get code to appear in any decent way on Blogger. If anyone can help me get the cool snippet window which everyone else seems to have on wordpress to work on my blogger account, that would be sweet, and I will shower you all with great code. (well not that great, I wrote it).

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

I know this is well-trodden ground (e.g. FDT Vs. FlashDevelop on flashmech), but I've finally spent some time with Eclipse and FDT, and to be honest I can't really see what the fuss is about. Of course Mac users don't really have the option of using FlashDevelop (except under emulation), but for PC users, I just don't see the advantage of Eclipse. Obviously the PowerFlasher guys have done a great job on their part, but Eclipse is just too unintuitive for me.

So here's 10 reasons I prefer FlashDevelop to Eclipse:
  1. FlashDevelop is free. FDT is quite expensive.
  2. 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.
  3. 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.
  4. 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.
  5. FlashDevelop projects can be moved around easily. Eclipse has confusing hidden project files.
  6. 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 ;)
  7. FlashDevelop has a cute quick-find search box. I couldn't find this in Eclipse.
  8. 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.
  9. 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.
  10. 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!
If anyone can counter any of these points it would help me a lot, as I have to use Eclipse for the next week, so please leave comments!

Monday, 2 March 2009

Flash development - are you doing it wrong?

Inspired by years of working with Flash and with other Flash developers (ninjas and newbies), here is my checklist of how to do things "the right way" in Flash and ActionScript (don't really know about Flex - you crazy guys do whatever you like!). I really want your comments on this one. Am I way off the mark? Do I go too far, or not far enough? Leave a comment please! Here they are:
  1. 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.
  2. 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.
  3. 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.
  4. 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 :(
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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?!
  10. 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.
Hope you found something useful here - trust me, I've learnt these lessons the hard way! Leave a comment if you agree or disagree with any of them, I want to know what you guys think.

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
The Werks
45 Church Road
Hove, England BN3 2BE

Check out the upcoming page for more info.