Game Development Category
20th Sep 2010
I’m a big fan of Flixel. Sure, it has its idiosyncrasies. But for rapid game development, or certain styles of game (fast paced pixel pushers) it’s perfect. One of its powerful features is the native tile map support. To create a tile map you can either bang one together in Notepad (if you’re pretty insane) or use a mapping tool. Some of the more popular ones are Mappy and Tiled, but neither were created for Flixel, or even Flash, and their feature sets are sadly quite lacking.
Enter DAME. Created by Charles Goatley this neat AIR app allows you to build complex 2D tile maps quickly and easily. As it uses Flixel for its rendering engine you know that whatever it looks like in Dame, it’ll look the same in your game too. I’ve been using it for several weeks now, during which time the developer has actively listened to feedback on the Flixel forum, and fixed bugs and added powerful new features.
You can put down multiple map layers, each with custom scrollfactor values and varying block sizes. Onion skinning, resequencing and editing is easy. One of it’s most powerful features is the handy matrix tool. By defining a grid of tiles you can then “paint” intelligently using this grid, and it’ll map all of the sides together sensibly. This allows for very rapid level generation indeed. With the new 1.0.5 update you can even assign custom tile connections, meaning you can set interior tiles as well. Hard to explain, but super easy to use, and once you have experimented you’ll be in tile mapping heaven.
Sprite layers are another great feature. Sprites can be imported and all of their Flixel attributes set, as well as any custom properties you may need. Sprites can be positioned anywhere, not just on the tilemap grid of the current layer, and can be rotated, scaled, flipped and duplicated. They can also be set to follow paths, which you can drag out and draw easily using polygons and splines. So if you had a platform sprite that you wanted to make follow a certain movement pattern, just draw it as a path and then attach the platform to it.
Text can also be added to the map (again any place, size or orientation). And shapes – both circles and boxes – can act as “triggers”. So you are able to draw a shape over an area of your map and have it trigger an event when the player enters it for example.
There are several exporters included (a complex and a simple one), and you can easily just export the map data as CSV if you wish to use Dame in a non-Flixel game. In fact you can even use Lua to script your own export system!
Dame is still very new and as such has a few teething troubles. But I would still encourage you to check it out and participate. The developer is friendly, responsive and open to ideas – lots of which I’ve seen implemented extremely rapidly. All quality attributes in my book.
6th Sep 2010
For the sake of transparency I just want to state: Friends of Ed offered me a free copy of this book for the purpose of reviewing it. However I declined as I had already pre-ordered my copy from Amazon, as I’m a great fan and friends with the authors Jeff and Steve Fulton. That doesn’t mean I’m going to treat this book with kid gloves or sugar coat my review however.
Dissecting a mammoth
Jeff and Steve Fulton, the pair responsible for the ever popular 8-bit Rocket web site, home to many tutorials on Flash game development, decided to combine their collective knowledge into one single tome. And this is the end result.
The book is split over 12 chapters which make up the majority of its 630+ pages. The chapters are split into two parts: Basic Game Framework and Building Games. It kicks off by going through their “Second Game Theory” which basically says your first game will always be utter tripe, and things only really start getting interesting from your second game and onwards (or if you are like me, your 10th game onwards). But it does cover some basic concepts such as proper object-orientated coding, but always in a game context. That is what I like most about this book, every snippet of information relates to making games, not some random computer science terminology you’ll never care about or commit to memory.
It then dives head first into building a game framework, including a solid and re-usable state machine, game timer and event model. By page 15 you have finished coding your first game, and while it’s a simple click counter it all runs from a well defined framework that is re-used and expanded upon throughout the rest of the book.
The second game is “Balloon Saw” in which you control a spinning blade with the mouse, and must take out as many floating balloons as possible. Again it’s simple, but it introduced more important new concepts: level progression, player controls, collision detection and scoring. By page 30 it’s all over, the lessons are learnt, you’ve another game under your belt and they waste no time in jumping into the 3rd game: Pixel Shooter.
Once Pixel Shooter is over you’ve got a complete space invaders style game finished, and more importantly they don’t dwell on every aspect of it – but only those aspects that differ from the previous game. I’m a big fan of learning through iterations, and that is certainly how this book approaches things.
Once you hit Chapter 2 it’s all about strengthening the framework you’ve already put in place. They add lots of powerful new features such as Custom Events handlers, a Basic Screen handler, Buttons and a Score Board (which is more the in-game UI for scores, not a Mochi Leaderboard type affair). Several pages are dedicated to the package structure, creating the game stub (which is done via FlashDevelop) and just setting your project up in a nice and clean way. Again I’m a big fan of this approach, and I have my own “template” project structure that I roll-out for all new games I write which matches theirs very closely. You don’t have to follow their structure to the letter (although it would be useful if following all of their game builds in the book), but by all means take from it the parts you find most useful, and settle on what works best for you. But the final message is the same: don’t be messy.
By page 100 the framework is in place. This is quite a hard-going chapter, and while vital for the rest of the book I can see a lot of developers getting that glazed look in their eye as they pour through page after page of class set-up and variable declarations. As important as it is I can’t help but feel that it may have been better to keep up the earlier frenetic pace of game building, and drip-fed more of the framework in the same manner.
Once the framework is in place Chapter 3 creates the “Super Click” game, an iteration of the very first game made in the book. It starts off by getting the reader to create a really brief game design document. All it asks you to do is write a very short snippet about what the game is, and define the basics such as the name, the objective, a description of play and creating a list of required assets/logic/variables.
It may seem long-winded to be doing this for such a simple game, most of which you argue you could just “remember” rather than write down. But GDDs are a tried and tested practise found in the industry. Any game developer I have working in my team will all have to write GDDs before they touch a line of code, and Jeff and Steve are the same. So if you plan on making Flash games as a “pro”, don’t skip this part.
Taking some Flak
As you may expect by now Chapter 4 is all about creating yet another game. This time a homage to Missile Command only with boats and planes. Jeff and Steve are children of the 80s and the Atari blood runs deep through their veins. You’ll see this scattered through-out the book, not least of which is a whole page dedicated to the history of Missile Command and it’s variants opening this chapter! As a fellow Atari fan I loved these sections, but I can see why the younger developers reading the book may care a lot less.
Flak Cannon, and indeed all remaining games in the book, use sprites from Ari Feldman’s now infamous SpriteLib collection. It also gets all sound effects from the SFXR app. So sadly it’s going to look and sound quite dated before it’s even left the gate. Now I’m a massive retro gaming fan, and I have utmost respect for the “classics” and reinventing them in Flash. But even I don’t feel that SpriteLib is a strong enough graphical resource for a book like this. Jeff and Steve would have benefited massively from employing the talents of a real pixel artist, who could have created something beautiful for each of the games in the book. I don’t think that visually any of the games portray just how solid and robust a framework is powering them. My concern is that developers will take one look at the games on offer and visually dismiss them, asking why they look so “old”. This is a crying shame, as internally they are as fresh as can be, employing all of the modern tricks and techniques you need for a flash game these days. It’s just the surface gloss that doesn’t match.
Work your way through the Flak Cannon game build and at the end you’ll have a really powerful Sound Manager class added to your arsenal, along with an understanding of vector movement and angles in Flash. This is where my second biggest criticism of the book stems: there are many absolute nuggets of code gold buried in the 630 pages of this book, but they require some serious digging to extract. Although the index and contents do a good job of explaining when you’re about to learn a new technique, such as Line of Sight, AI or 2D Cameras, being able to extract those techniques out from the game in which you’re learning them is not an easy task. There’s very little “throw this code into the IDE and see”. For example the minimax-styled AI routine used in the game Dice Battle is so tightly ingrained into both their framework, and the game itself, that you’d have a harder than necessary time extracting it for your own project.
It’s all about post-retro, baby!
The love of all things bitmap starts with the Flak Cannon game, and really doesn’t let-up from there on. By the time you hit Chapter 6 (“No Tanks!”) you’re well down the road of tile editors, Mappy, sprite sheets and blitting. There is no denying that this is the fastest way to shift graphics around in Flash, but it’s not the only way. And it may feel very alien for devs coming direct from the Flash IDE to even bother with the likes of a sprite sheet and non-timelined animations. The tilemap system introduced in chapter 10 is again all about the blit and “old-school” tilesheets.
Personally I don’t have a problem with this, but I think it’s important for devs to realise that when coming to this book that is the approach they are going to be taken down. And while it’s a tried, tested and very fast route to pursue, it’s also not the only one. There were many times reading this book that I felt it should have been called “The Essential Guide to Building Bitmap Blitted Games in Flash”, because quite frankly there is no other book that covers this subject in the kind of depth the Fulton’s do. And I doubt there ever will be (unless they publish a 2nd edition!)
Towards the end of the book Chapter 12 deals with a host of important topics that you rarely see mentioned in any other Flash game book. They cover making money from your game, via both Mochi Ads and licenses / sponsorships. Securing your game with site locking and encryption, marketing, pre-loaders and Mochi leader boards. I thought this was a really nice touch, it just makes it all seem more “real” – as these are all the kinds of things that new Flash game devs will go through, and may not yet be aware of.
Game Over Man, Game Over
I truly admire Jeff and Steve for having had the balls to even write this book in the first place. I know just how much hard work it was, and how much effort they put into it. Does this cloud my judgement somewhat? Perhaps, but ultimately it’s up to you to decide if this book will be a “good fit” or not. Personally I’m a firm believer that you can never have too many game development books, and this is one that certainly has a place on my bookshelf. There are quite a few typos and spelling mistakes to be found (“MoveClip” being a popular one!), and even their game Super Click says “Click the blur circles” at the start (it should be “blue”). But I can overlook these small things. Hopefully they don’t extended into the source code too!
Yes it’s very “hardcore” about the approach (blit-mapped to the max), but only because they care about performance. They cover a lot of advanced game making topics, and a lot of subjects that no other book even looks at. They teach you and they teach you rapidly, pulling no punches, and without much filler.
If you’re the sort of developer who just “dips into” books, and extracts only the bits you need at that point in time, then you’re going to have to work a lot harder with this title. The content is there, but mining and then refining it into a usable state will take longer than perhaps should be necessary.
If however you have the tenacity to work through this book from start to finish, then I have no hesitation that you’ll come out the other end knowing a great deal about game development in Flash. You’ll have a whole ammo case full of fantastic routines to use, all sitting on-top of a solid and easily expanded framework. And to me that’s worth the cover price alone.
Special Offer: Buy the PDF eBook version and get 25% off by using the code PHOTONSTORMECN
6th Jul 2010
Last week I attended the Children’s Media Conference with lots of other people from Aardman. It was a 3 day mix of presentations, panels and meeting really interesting people. And everyone there had something to do with the children’s side of the media and entertainment industry. I just wanted to share a few insights that I picked up there. Some are obvious, some less so …
1.) Children are no longer just watching TV, they expect to interact with it. On their phones, via MSN, on YouTube, etc. And often do these things simultaneously (watching a show while chatting to friends about it). The distinction between TV and online is a non-plus for them. They have an extremely rich media diet.
2.) Traditional broadcasters (and “offline” producers) are increasingly worried they are taking too long to resolve the provision of content. And children are just going online instead. The world is changing faster than a lot of them can cope with.
3.) Children prefer “home grown” material – i.e. they don’t want to hear American voices in their cartoons. The same applies to games, only to a much lesser extent.
4.) Broadcasters recognise that the future is on-demand, and in the long term, online. The BBC specifically made a point that they were perfectly aware that digital is the future.
5.) Lots of Children love manga! (no surprise there) The style of artwork allows them to clearly see the emotions that the characters are experiencing. And manga / anime characters do actually show emotion, unlike most US made cartoons in the same area. They find the super powers and stories generally more exciting, and want to be part of that fantasy. There is a really strong “collect, compete, play” association with most popular manga/anime (think Pokemon, Yui Gi Oh or Bakugan). Manga/Anime is less concerned about dealing with emotion and more complex subjects.
6.) “Transmedia” is now what they are calling the latest iteration of “new media”. But it’s all just media really. Transmedia (like before it) is just the means of telling or experiencing a story across multiple platforms.
7.) “Games Bibles” are vital, no matter what scale game you are working on. Matt Costello gave a brilliant (although sadly very brief) talk about how he created the game bibles for games like Doom 3 and Just Cause 2. They should start off as a paragraph, explaining the concept behind the world in which the game lives. And then expand from there, eventually encompassing as much detail as possible in order to bring the game alive. Bibles shouldn’t just focus on the game itself, but look into the backstory and what could happen in the future, should the series run or adapt across to a different media (game made into a TV show or comic for example).
8.) Girl Gamers: Girls love tech! They adopt it way ahead of boys. By 8 years old most of them will own a gaming device (like a DS), by 10 lots will have a mobile phone of their own and a laptop/PC. By 11 they’ll have Facebook accounts (and boys will have XBLA accounts). By 13 most have personal iTunes accounts or equivalent. Between the ages of 9-10 is when most girls peak at their interest of gaming. They are competently using online services (for social and gaming aspects) and use of their mobile is massive. Age 10+ and they mostly now focus on social spaces and social networking. To them Facebook IS a game. Creating private worlds is key, the ability to build a social space away from their home.
9) Games that can tick the following subject boxes appeal strongly to girls aged 10-13: Manipulation (!), Relationships (Sims), Problem Solving (puzzles), Responsibility (pet games), Private Worlds, Role Playing (Imagine Teacher), Identity, Risk Taking. In reality most games fail to keep their long-term interest. A quote from a 10 year old: “I classify my phone and my laptop as my toys”. The Blackberry mobile phone is huge for girls and is often their top “most desired” item. This is due to the social nature / features it provides (Blackberry messenger). Social networking for them becomes obsessive around age 12. By age 13 they want cues from the real world in their games.
10) Graphic Novels and Comics are making a huge come-back for children, and are no longer mostly for adults! Publishers like Walker Books are reporting sales up by 29% over the previous year. They are finally coming “back to kids” – picture books aimed at 8-9 year olds (such as Savage by David Almond) are breaking new ground. Visual literacy is just as important as reading ability. Jamie Smart gave a brilliant talk about how he can release a new comic strip on his web site, and earn a decent living from the merchandise surrounding it. The team at Pulp Theatre are releasing graphic novels through their Alien Ink range, aimed at teenagers and issues they find hard to talk about. Has been a huge success, now sponsored by Channel 4. Again they did the whole range of releasing online and on Facebook before going into print form. They took the comics to where the kids hang out, they didn’t expect them to “come find them”.
Please bear in mind that figures given should be taken in the context in which they were delivered (i.e. are probably only relevant to the UK)
Despite the heat wave it was a great conference. And interesting to see how other people are applying the same kinds of professional skills that we have (from web development to game design) and applying those to entertaining and educating children. Perhaps even yours?
30th Apr 2010
Given all the current Flash vs. HTML5 furore going on at the moment, I thought I’d throw this into the pit and let it smoke:
There are some demo games on the site, which are also the example games in the download. None of them are going to set the world on fire and all are easily re-created in Flash at much higher frame rates. But I have full respect for the developer who created this project, and I’d love to see where it progresses.
The only reason I won’t invest any time in digging deeper is that the example games don’t work on Internet Explorer (and nor does the author claim they will). And like it or not IE is still the major browser of choice. As a result this is confined to “nice curiosity” rather than “contender” for the time being.
Final thoughts: It’s going to be years before HTML5 is a viable platform for building games, but the day will come. Nothing can prevent it. However I firmly believe that Flash will evolve with this, and there is no reason at all why HTML5/JS can’t become a new publishing target for the Flash IDE.
Of course I firmly hope that Adobe will wake-up and give game developers what they’ve been asking for for years from Flash Player itself. The video battle is over Adobe – you started a whole new wave of technology on the web when you pioneered it. But time has moved on and the browsers have caught up. Leave video behind and start empowering us game developers before you lose us too. We are your final real foothold Flash Player has on the web today. Flash games are still the one area where there are no real contenders, but we regularly have to scale back our games because we know Flash Player can’t cope. We’re hitting the limits of your technology, pushing it as hard as it will go. This is a dangerous place to be.
All of your RIA movements are admirable, but they offer nothing that cannot be achieved via many other different options. Unity know game development, and they know game developers. But their plug-in will never gain critical mass.
Support us or lose us Adobe.
24th Apr 2010
It still pains me when I see Flash developers coding huge chunks of ActionScript in the IDE or some text editor that offers precious little more than syntax colouring. I don’t consider the code insight of editors like FlashDevelop a “nice to have”, I consider them vital in making me a productive developer. I can spot syntax / structure errors faster, I can jump back/forth between methods/classes. I can see an overall organisational tree of of my project, allowing me to organise my classes as best I need.
I find the mentality that this is somehow “wrong” more than a little disturbing. It’s like HTML developers who claim they only use Notepad, as if that’s some kind of badge of honor. It’s not. It’s a badge of stupidity.
For quick tests the IDE is fine. For anything serious do yourself a favour and use a proper tool. You may be surprised at how much faster you get stuff done as a result.
In light of this I was really happy to read that Flash Develop 3.1.0 is out. It has some awesome new features, multi-project support being my absolute favourite. Here is the official change list. Download link at the bottom.
- Real MXML completion implemented
- Flash Player 10.1 and Flex 4 support added
- Initial simple refactoring support added
- Global excluded directories added to Tasks
- Embed generation now added for all filetypes
- Proper file encoding behaviour without BOM added
- HTML ZenCoding implementation added (Control + B)
- Output panel is now searchable (Highlight, F3 and Shift+F3)
- Simple multiproject support with batch compiling added (1*)
- Compiler constants and timestamp added now automaticly
- Code completion is now fed with classes from SDK sources
- Japanese localization added (Settings -> SelectedLocale)
- HaXe on demand completion added (patch from filt3r)
- Additional keyword groups added to the config
- Code completion improvements and bug fixes
- General UI improvements and bug fixes
All about Photon Storm and our
HTML5 game development services
- Tutorial: Making your first Phaser game
- Phaser 1.1.3 "Arafel" has landed with a shadery splash
- My HTML5 Game Development In-depth session at the Montreal International Games Summit 2013
- Phaser 1.1 is released! New API docs, 150+ examples and hundreds of updates
- Phaser 1.0 and the journey we took to get there
- Wide-eyed, quacky, flappy, pre-school adventures!
- We're now Nintendo Approved Wii U HTML5 developers
- Our largest HTML5 game to date: Wolfblood: The Mystery of Stoneybridge for CBBC
- Assembloids comes to the Atari XE
- Whattaheck: The HTML5 demoscene
Filter our Content
- Cool Links
- Flash Game Dev Tips
- Game Development
- Geek Shopping
- In the Media