Monday, 28 February 2011

Podcast Episode 3 - Molehill and Processing with Jer Thorp

The unstoppable juggernaut that is The Creative Coding Podcast continues on its inevitable rampage of destruction, this week flattening Molehill and making mince meat out of Processing. Special guest Jer Thorp jumps on board to crush those who would oppose us. Listen now!

Friday, 25 February 2011

Hackathon contest winners announced!

A while back I announced a Flash game contest I was helping to judge, and gave away some source code to get you started. Over 500 people downloaded the source code - however not one of those people managed to enter the contest! No matter though - six intrepid developers did get their games finished and in front of the judges eyeballs. Head over to Mark's blog to find out who won and play the games. If you didn't win - don't worry, there was something to like about all the games, and all entrants get a copy of FDT.

Tuesday, 22 February 2011

How to make a whole game in one day

There are game jams and Flash game competitions seemingly every weekend these days. While I don't really like the idea of pinning my eyes open with matchsticks and coding all night, I do like the idea of getting a complete game finished and released in a single day. I sometimes get a day or two of downtime between client projects, and rather than using this time to experiment on bunnies, I've been trying to work out how feasible it is to release 1 or even 2 games in these gaps.

My first couple of attempts have overrun by about double, and still aren't released (I'll keep you posted), but I have learned a few things along the way that I thought were worth sharing. I've also picked the brains of some other friendly developers for some suggestions (you know who you are, so thanks!)

Here's what I've worked out so far:
  • The game can't have more than 1 level that you need to design. So a single maze like Pacman would be ok, but you can't have every level be different.
  • You can't require any complex artwork. You need to use either free art, cheap stock art, art you already have kicking around, or art you can put together in 1 or 2 hours.
  • You need a game engine to start off with. Flixel and Flashpunk might work for you, but I prefer to use my own engine, which I have been revising and improving for well over a year. It's still nowhere near "finished", but I'm not writing much low-level code for each new game.
  • You need a template .fla and/or FlashDevelop template already set up so you don't have to write any boilerplate for Mochi-ads, screen management, preloading etc
  • Your game must have a way of automatically progressing - with either randomly generated levels, or a simple way of getting progressively harder automatically. Players expect to go on a journey of increasing peril, but that's hard to "author" in just a few hours, so automating it is the only way to go.
  • Your game can't introduce you to any programming techniques that you've never done before - e.g. new type of collision detection. Learning a new technique is a fine way to spend an afternoon, just don't expect a game at the end of it.
  • The game must have reasonably similar gameplay to an existing game, so you're not working every aspect of game design out from scratch. If you add even one or two elements to a game that are completely novel, you've done more than most. Combining game mechanics from different games that you enjoy seems like a logical starting point.
  • Don't try to make all the code you write reusable - just get the game done, you can always come and copy bits out of it later.
  • Don't throw your idea out half-way. Once you come up with your idea and started coding, you might as stick with it and do the best job you can to make it fun. Even if it doesn't turn out to be the new Tetris, at least you will have another completed game under your belt.
If you've got any more suggestions and lessons-learned from your own game-jam experience, please post them in the comments.

Thursday, 17 February 2011

BunnyMark compiled from ActionScript to HTML5 with Jangaroo

Jangaroo is a cool opensource project that lets you compile AS3 source code into JavaScript, and as it emulates a subset of Flash player features, you can even use it to port existing Flash games and apps to HTML5 Canvas. I talked about my experiments trying to get it working in the first episode of my and Seb's podcast. I wasn't having much luck at that point, but since then Frank from the Jangaroo team has given me loads of help to get all my demos working, even editing my code and fixing parts of the compiler for me! What I think I didn't stress enough on the podcast was that this project is still very much a work in progress / public alpha - I think it has a lot of potential.

So here I present BunnyMark via Jangaroo and HTML5 Canvas!

BunnyMark - blitted version - 30fps (Windows Vista / Chrome) - Pretty fast!
BunnyMark - bitmap version - 8fps - Really slow for some reason. (any ideas Frank?)
BunnyLandMark - blitted version - 30fps - Pretty fast!

How to communicate between game objects.

Over on Richard “PhotonStorm” Davey’s blog he proposed a simple way to communicate between objects in your game using a “Registry” a class with static variables storing all the major systems of your game. So, for example if you wanted to create a spray of blood when an enemy is hit, in the enemy’s hit() function you would include the line Registry.fx.sprayBlood(x, y) and the FX object stored in the Registry.fx variable would create the blood spray and handle updating etc.

In the comments on Richard’s post, I pointed out that this isn’t a very object-oriented approach: these are basically global variables by a different name. I have used a similar approach myself on quite a few games projects, and overall it works well and is a quick way of getting things done. I have, however, encountered two problems with it.

Firstly, you can end up with all you code in one huge blob or “god class”. For example, if the FX class is responsible for handling any possible visual effect you would want to create, it could end up getting very big. But, other than academic notions of “good” and “bad” code, there’s nothing especially wrong with having big classes. They may be a bit harder to maintain and reuse, but nothing to worry about too much.

Secondly, using static/global variables as a communication method means you can be limited to having only one “game” in a single project. Now in most scenarios this wouldn’t be a problem, but it’s normally best not to assume you will only ever have one of a particular class of object. I’ve worked on several Flash projects that were collections of minigames in a single swf. Where I was relying on static variables in some of my base-classes and utility classes, I started to see clashes between the different games.

Ok so how do I handle the same problems? Well, say an enemy needs a reference to the player in order to chase after them. Rather than looking up Registry.player, I would just have a “player” variable in my enemy class and I would pass in the value of player when I create the enemy, or once I know the player exists. Or if the enemy needed more than a couple of different references from game in order to work, I would just pass in a reference to the game itself, and let the object access whatever information it needs. As Richard points out, the downside to this approach is that you end up with a lot of references in different places. This isn’t really a problem if you null your references when destroying objects, but it is more work, and you can leak memory if you’re sloppy with it.

Secondly, pretty much everything in my game extends a base Entity class. I have a main Game class that manages all these entities. Game has a method called addEntity(entity:Entity) which adds any new entities I create to the array of entities. Every frame I loop through all my entities and call their public update() function (to pause the game, I just don’t run this loop).

So say I have a SpaceShip object that creates a Bullet object every time it fires. How would I let the game know? I wouldn’t call Game.instance.addEntity() because I may have more than one mini-game that extends my base Game class in a single project. Instead, the base Entity class has a function addEntity(entity:Entity) which dispatches an AS3Signal with the entity value. My game is listening for this signal, and directs the entity to its own addEntity function. You could also use an event to achieve the same effect. Now any Entity can itself create more entities and add them to the game.

How would I use this to solve the problem of creating a spray of blood? I would create two Entity classes. One class is BloodDrop which is a single particle of blood. Every update() it moves based on its speed and falls with gravity, and after 30 frames it fades out and destroys itself. The other class is BloodSpray, which lives for a single frame, and in that frame just runs a loop creating 100 instances of BloodDrop, setting their initial position and speed, and calling addEntity(bloodDrop). Now to add my spray of blood in the enemy’s hit() function, I simply create a new BloodSpray, set its position to match the enemies position and call addEntity(bloodSpray). All the entities know how to update and destroy themselves and are pooled for reuse.

This won’t solve all the communication problems in your game, but it will solve a big chunk of them, and now your code is neatly organised into distinct Entity classes which each perform a single purpose.

Happy coding! I think my next conference/user group talk might have to be one about organising game code :)

Friday, 11 February 2011

Podcast Episode 2 - iOS, Android, Windows Phone 7 and more!

Me and Seb are back with another episode of The Creative Coding Podcast. This time it's a mobile devices special, with iOS, Android and Windows Phone 7 under the spotlight. For your aural pleasure: The Creative Coding Podcast - Episode 2. Enjoy!

Friday, 4 February 2011

Molehill + Scaleform = hardware accelerated 2D in Flash?

This post is pretty much an open letter to Adobe, so if you know anyone who works there, please send it to them. I've had what I think is quite an interesting idea, and I think it's one that Adobe should have a long think about. The Flash player is about to add hardware accelerated 3D rendering with "molehill". The demos that have been released so far look great - amazing 3D scenes rendered with no impact on the CPU. All the rendering is handled by the GPU, leaving the CPU free to process your game logic, including physics, collision detection and AI - which allows for more advanced gameplay (and stops Flash-haters fixating on how much of their precious CPU the "bloated" Flash plug-in is consuming).

However, this will only apply to 3D games. In fact 2D games - which we must not forget are what has made Flash the number 1 gaming platform on the web - will see no benefit from this release. What's the message from Adobe here? That 3D is the future of gaming - 2D is not important, or at least 2D games already have good enough performance. But when you consider that native 2D iPhone and Android games have similar (if not better) performance than 2D Flash games on much inferior hardware, you can see there is plainly massive room for improvement. Now look at the iPhone and Android appstores, where there is a genuine choice between 2D and 3D games. The charts are dominated by 2D games like Angry Birds, showing that 2D is still the dominant style for casual games.

Ok, so what can we as game developers do about it? Well, we could make all our 2D games using bitmaps rendered on 3D planes, and so leverage the GPU rendering of "molehill". Now our CPU is free for game logic. But what have we lost? Well for starters the display list with it's powerful nesting features, filters, textfields, use of the Flash pro IDE for layout. In short everything that makes Flash what it is.

So what can Adobe do about it? Well, there already exists a technology called Scaleform that renders the Flash vector engine using GPU accelerated 3D by tessellating 2D graphics - effectively turning them into flat meshes of 3D polygons that the GPU is designed to render fast. This technology is used to make 2D user interfaces for console and PC games. Now, I'm no expert in scaleform or graphics hardware, but it seems to me that this technology or something very like it could feasibly be integrated into the Flash player, meaning whole Flash scenes and timelines could be rendered largely on the GPU. This would keep the Flash pro IDE as a relevant product, and take Flash beyond being the most popular platform for 2D games, to being the best platform for 2D games.

In 2008, along with many other developers, I asked Adobe for joypad support in Flash. At MAX last year, Adobe finally announced their plan to add this feature. I'm just as certain that I'm right that Flash needs hardware accelerated 2D.

This video shows how much power the GPU brings to Flash - wouldn't it be awesome to have that much power in our 2D games? Comments / reasons why I'm barking up the wrong tree are greatly appreciated! :)