Over the last few weeks I have been learning ActionScript on the job. I come from a C# and C++ background and would like to share a few tips for programmers experimenting with ActionScript 3. This is by no means a complete resource on the subject and I will correct this article based on feedback in the comments.

Types

ActionScript 3 has 32 bit integers but no 64 bit integers, signed or unsigned. The Number class is a IEEE-754 double-precision floating-point number, so does not cover the same range as a 64 bit integer (53 bits vs 64 bits). There are also warnings about performance in Adobe Number documentation.

Arrays are “sparse arrays” which are not necessarily a block of consecutive memory. An ActionScript array seems to be more like a table, where each position has a “next” redirection for the following defined value. There can be holes in the indexes that are undefined. The documentation warns against using a class to create associative arrays and suggests using the Object class instead. See Adobe Array documentation for more details.

Vectors are “dense arrays” where each element has a value. All elements are expected to be the same data type. Vectors seem closer to what programmers from other languages may think of as an array. The Adobe Vector documentation lists pros and cons of using vectors over arrays, one of which is performance.

Without the /g global flag regular expressions (The RegExp class) only matches the first item.

Operator == vs ===

There are a few more operators to look out for in ActionScript – a few existing ones have their meaning changed too. [Adobe Operators Documentation]

Lets start off with ‘strict equality’ (===) versus ‘equality’ (==).

The == operator attempts to convert things to a common form for comparison and in the case of objects, arrays and functions falls back to being compared by reference. In short a string with the value “1″ will match a numeric type with the value 1 through an implicit conversion.

The === operator still tries to convert between different numeric based types (Boolean, int, Number and uint) but not for anything else. Variables representing anything else are compared by reference.

Operator >> vs >>>

There are two types of shifting types to think about and in C++ the shift is context sensitive on the type.  The logical shift moves all bits in the operand.  In C++ this is what an >> operation does on an unsigned type; in ActionScript to do the same operation use the >>> operator.

The alternative type of shift is an arithmetic shift which happens in C++ on signed types.  Both C++ and ActionScript use the >> operation.

0111 1111 1111 1111 1111 1111 1111 1111 = 2147483657 = max value of 32 bit signed int

1111 1111 1111 1111 1111 1111 1111 1000 = -8 int or uint 4294967288

0111 1111 1111 1111 1111 1111 1111 1100 = 2147483644

1111 1111 1111 1111 1111 1111 1111 1100 = -4 int or uint 4294967292

1111 1111 1111 1111 1111 1111 1111 1110 = -2 int or uint 4294967294

1111 1111 1111 1111 1111 1111 1111 1111 = -1 int or uint 4294967295 = max value of 32 bit unsigned int

So the bit patterns between -8 >> 1 and -8 >>> 1

1111 1111 1111 1111 1111 1111 1111 1000 = -8 Input

1111 1111 1111 1111 1111 1111 1111 1100 = -4 Output ActionScript >>

0111 1111 1111 1111 1111 1111 1111 1100 = 2147483644 Output ActionScript >>> or unchecked C# >>

Note how >> keeps a 1 on the first bit, where >>> puts a zero in the left most bit.

For further information, see the code examples in Adobe documentation.

Conclusion

This article is ripe for expansion. Please link to other resources in the clients, and if any other authors want to discuss this, go ahead!

EDIT: Please read the comments, people have already been contributing good tips. :0)

Idempotence within a system means that repetitions of an action do not effect the outcome. I am not going to go in to the etymology or the mathematical definitions of the concept, but I will attempt to explain why as a programmer this is interesting.

The Audition

No matter how many times a function is performed with the same inputs, the output is the same. The time has come for the audition, the curtain raises, enter stage right the programmer, beaming at the audience.

Programmer mutters under her breath the reassuring mantra “arrange, act, assert” takes a bow and shows the audience a few empty boxes. She has done this all before; she knows what to expect. She requests a few valuable items from members of the audience and through a myriad of different impressive feats, these items fly through the air and land in the boxes. Then she shows the results to the audience members who respond with enthusiastic applause.

Between each routine, the programmer arranges everything back to a known starting point, emptying the boxes. She requests a single item from each audience member. Using magic, she transports each item to a box. She shows the approving audience that yes, the right item is in the right box then returns it.

This kind of magic is possible when the audience is well behaved and predictable. A request for one item results in one item given.

There’s a few unfamiliar faces who come in late and sit at the front. They heckle, they have their own magic. Programmer on stage thinks she can handle them using the same tricks she has always known. Amazon sisters SQS and SimpleDB know differently.

The Heckle

Some of the Amazon web services like SQS and SDB promise that something will happen at least once. While the programmer is used to receiving one or more item from the audience, she starts noticing something a little strange about the things coming from these Amazon hecklers. At some point in midair it appears that one unique item becomes two or more. She has to work harder to catch these clones.  She is glad she was prepared and had asserted what she was expecting; or those clones could have flown by unnoticed and turned in to nasty dangerous bugs.  The kind that have crept up behind others and caused nasty injuries.  She hates bugs.

What value is there in letting this disruptive element to the show?  Are these non-idempotent Amazon services providing any benefit? There are two forms of scalability to consider – up and out.

Scaling up is a more traditional solution. This requires adding capacity to a service provided on a machine which is achieved by means of adding memory, processors and hard drive space.

Scaling out is to add more (cheaper) machines to handle traffic to a service. Instead of one mega server machine, many drones can provide the same service while it may appear as one mega machine to the outside world. Keeping the worker drones synchronized is difficult. While eventually all the drones will know what the others have done, the overhead of synchronization means they will not know instantly.

Server capacity can be added by adding another drone during peak demand. Drones can be quietly dispatched when they are no longer required, saving energy and money. A well architected system is more resilient because a new drone can take over seamlessly from a failed one.

The challenge of potentially large lag times before data is consistent forces a programmer to think differently. Similar challenges exist in writing well-behaved multithreaded systems; except here there are more things to go wrong during data transmission and storage.

Solutions

There were two approaches she decided to take in order to deal with these clones.

For tricks where a single item was expected back, she arranged a box to vaporize the old when receiving the new. This was a simple variable overwrite; each new unique value had a unique box that was created if it did not exist.  If it did exist, the contents were replaced by the next received item.  Unfortunately that did not solve tricks that required aggregation. The vaporizing box was no good for keeping count of things.

The second approach she attempted was to remember the items she had already seen and throw the unexpected clones off stage. This was okay when she could keep all that information in memory. There was a limit to how many unique things she could remember before she has to ask for timeouts. She had to start to use a list to check against things she has already dealt with to weed out the mischievous clones.

The programmer was just one consumer; the audience producing the items to store away could scale out to hundreds… thousands… millions. While some of the audience were okay with waiting, others grew unimpressed and left. Being an idempotent consumer was turning out to be a bottle neck.

The trick with different models of watches all going to the same box no longer worked. The audience would believe six watches were thrown, but the box would could contain many more – it was cluttered with clones.  Some audience members only cared if they could get their watch back, but for the accountants in the audience the total was important.

Timing and order was a challenge.  Sometimes item clones would pop out of the air a long time after receiving the original items. Things would pause midflight and arrive inexplicably after things thrown later.

The hecklers were introducing all kinds of complexity to what used to be a simple routine. Things would be dealt with eventually, but it was getting difficult to predict the end of an act.

Conclusion

So the imagery is a little silly but with any luck if you are a programmer with any level of experience that did not know what idempotent meant… you have some idea now. Writing scalable idempotent consumption of a service that sends the same thing more than once can be tricky.

The Amazon Queue Service (SQS) may deliver a message more than once. Amazon SimpleDB may repeat a unique result across different query pages. A simple for each bar do foo will not suffice if foo should only be executed once per bar. Foo must be idempotent, or the collection of bar filtered.

The two common approaches I covered boil down to uniquely identifying everything and storing using that identity, and processing things stored by tracking the unique identify of things already processed.

Keeping track of data acted upon is necessary for things that should only happen once. For example, a cash machine should only ever deduct the money taken out of an account for a unique withdrawal transaction once; otherwise the account balance would be incorrect.

Work can be split up by techniques that involve using “shards” and “map reduce” – both out of scope for this particular article. Though as a note, the reduce part of map reduce in implementations I have seen must be idempotent.

Programmers with a functional language in their arsenal probably have an edge here over those purely from a purely object-oriented background because of the way those languages make you think about data.

Keep in mind two things if you are considering data processing to cloud technologies. Keep the word “idempotent” in mind and pay attention to the “at least once” small print in the documentation. Secondly some services only promise to be eventually correct – decide when that is good enough. Do your users really need to know what the state is as of right that second, or is a minute ago good enough?

I am still learning myself, so if you have any insight or articles of your own please share them in the comments.

Matthew Hanlon is one of my friends back in the UK that has taken that leap of faith… he founded an independent self-publishing game studio. This guest post from Matt details the development of the studio’s first release “Endless Lines“. The rest of this post is from Matt’s perspective (with an editorial pass from me).

A Studio Is Born

It has been about a month since I released Endless Lines so I thought I’d take a quick look back at its five weeks of development.

At the start of June I left my job at Lionhead Studios where I’d been working as a gameplay programmer for the previous seven years.  I went straight from school to university, spent six years at university and then immediately joined Lionhead.

At 30 I was suddenly in a world without a set structure for the first time since I started primary school at the age of 4.  Fortunately I was best man at a friend’s wedding the weekend I was leaving Lionhead so I spent far more time worrying about the speech than being scared about leaving my job.

The Plan

My plan was to start with a small, simple project I could complete on my own.  My goals were to:

• Get used to working at home rather than in an office environment.
• Get used to working on my own rather than part of 70+ person team.
• Finish something to prove to myself I can see a project like this through to completion before moving onto larger, more ambitious games.

I chose to use SDKs and middleware wherever possible to save reinventing the wheel.  These things aren’t a magic bullet that will do everything for you but they can significantly speed up your development process if used correctly.

My advice to anyone doing this themselves is to talk to others using an SDK and look at a wide range before deciding on one.  Every SDK and piece of middleware has its limitations and flaws so be sure to check their forums. Of course you have to know what you’re making and what your target platform is before you go looking for an SDK…

A Concept

The initial concept for the game that would become Endless Lines was an idea I had last Christmas. I thought about action puzzle games for the iPhone and control schemes based around the touch screen, rather than those using button controls or virtual D-pads.

I had an earlier concept filed away in my head about a falling block game where the blocks have lines on them.  The player arranges these blocks to form a line across the play area or forms a loop with them.

These two ideas merged into a game where there is a full board of blocks. The goal is to create paths/lines from one side of the board to the other. This is achieved by moving the columns up & down rather than the block itself.

Corona SDK

After playing around with a few SDKs for iOS development I settled on Corona by Ansca Mobile.  Corona is a 2D SDK targeting iOS and Android platforms, ideal for my needs.  It uses the Lua language – another positive for me as that’s what all the AI written for Fable 2 & 3 used. I’d spent the previous five years with my coding split between C++ and Lua.

I imagine most people with experience of developing games evaluating Corona have the same reaction as me – Where’s my game loop? How do I set up objects? How do I associate this function with this thing, input?

Corona is designed to make development quick and easy, especially on the graphics and interaction side.  Once you get a handle on how it works, it becomes very easy and fast to work with.

I’ll give you some examples of what I mean.  Retina support is all taken care of for you as long as you supply a .png & a @2x.png and use the correct display function. For Open Feint leaderboards I would set aside a day to get them into the game… but a few lines of code later and it was done.

The best thing about Corona is the community that has grown up around it. The community share code and help each other out.  There are people giving away chunks of code just to help the community. For example if you want some code to manage the scenes in the game then look no further than Ricardo Rauber’s Director class.  How about some extensions to SDK functions and a great wrapping of the save load system? Then check out CrawlSpace Games’ CrawlSpaceLib.  I took advantage of both of these. If you are using Corona you should check them out too.

There are some things I think need improved with Corona. A visual debugger would be a most welcome addition, but I’m not going to go on about it as they are constantly updating and improving the product. They are very good about listening to feedback.

Prototype

I took a couple of days to make my technology choices with confidence after familiarising myself with the SDK and looking at other people’s code. Now it was time to start my game.

After the first day, I had a basic playable prototype up and running:

Not a looker with the titles quickly drawn in Paintbrush (some of the edges don’t even match up) but it was functional. The columns could be moved and the game recognised paths, but didn’t remove them yet.

Path Finding

Since it was designed for mobile platforms, I was always concerned with the code for the path-finding taking up too much CPU time.  The path-finding code had to do two things:

1. Highlight blocks that are connected to the left edge of the board and therefore are part of a possible path.
2. Recognise a complete path from the left to the right side of the board.

The first uses a simple flood fill style recursive algorithm to find which blocks are connected to the left edge of the board.  If a block is connected to the left edge, then it checks all the blocks around it. If it is connected to any of those, they then perform the same check.  This continues until it’s flagged all the blocks that have a connection to the left edge.

There is only a complete path when one of the blocks in the right most column is flagged as having a connection to the left edge.  When this is the case, code is run which finds the path across the board from right to left only looking at blocks that are flagged.

Splitting it this way gave me code which never impacted the game’s performance. It was written once and remains unchanged.

Evolving Design

A significant change from the original concept was allowing the rows to be moved as well as the columns.  During the first couple of weeks of development if a path was detected, it was immediately removed. This was changed so paths weren’t found until after the player have finished moving; paths were cleared on the player’s terms.  These two changes allowed the creation of longer, more satisfying, high scoring paths.

This type of gameplay lends itself very well to timed gameplay modes.  To me Blitz and Sprint are the core of the game, Zen is essentially a practice mode which I considered not including.

The time-focused core modes made the special blocks almost pick themselves.  There are three of these blocks:

• Multipliers – These appear when more than a certain amount of blocks are removed in one go.  They simply increase the points value per block.
• Bombs – These take out all the blocks in the row and column they are in.  Originally they just removed the blocks surrounding them but that wasn’t enough of an incentive to make players go for them.
• Locks – These prevent the row & column they are in from being moved.  These are ideal for Sprint mode where the player is trying to reach a target score as quickly as possible because they are a small obstacle to be overcome along the way.  Locks were also in Blitz mode, but just removed all the fun from the mode when they appeared so were removed.

In Sprint mode the sequence of bombs & locks is always the same for each of the three targets (each target has a different sequence).  This was suggested by my flat-mate when testing the game. This way everyone has the same challenge so times are achieved based on skill rather than luck helping them get the quickest time.

Art

My biggest worry was always the art. For this game, I was doing everything myself so I had to pick an art style I could produce.  In the end, I decided to try and make the blocks look like they were physical board game tiles.

The art was always the slowest part.  I decided to add an email feedback button to the main menu, the code to add this functionality was trivial, creating a button that looked good and read well took hours.

I got very familiar with Photoshop again and abused all the tricks I’ve picked up over the years.  I’m happy with the work I produced for the game, but in the future I will be looking for an artist to work with.

The only thing I didn’t do myself was the music, which I licensed.  This was quicker than doing it myself but it still took two days going through various music licensing sites listening to samples.

Release

Five weeks after I started Endless Lines, I submitted it to Apple.

The main aim of this first project was to get used to working like this rather than as a cog in a big machine and it worked.  I’ve released one update for Endless Lines so far. There will be more but right now I’m working on a couple of other projects.

During most of the development of Endless Lines I kept “normal” working hours. As things went on, I worked at the weekend and did a few hours in the evening but nothing crazy and it was never a chore; I wanted to work on it.

Overall I’m happy with how Endless Lines turned out, especially given its short development time. It’s picked up some good reviews; you can find the links in previous blog entries (here and here).

About This Article

Matthew can be found on twitter as @thebag1981.  Another Lionhead Studios alumni Kieran Nee (@kieran_nee) has recently joined Matt at Bit By Bit Games.   The original version of this article can be found here on their blog.

Danni Evans and Paul Evans (@paulecoyote) edited the article for AltDevBlogADay.

Flying

Check-in as soon as you are allowed; default allocated seats are often terrible unless you have high status with the airline. SeatGuru.com can give you a good indication of what a good and bad seat is. Seats nearer the front tend to be preferable; if a connection becomes tight you will want off that plane as soon as you can. A little time can make the difference between gate open and gate closed.

Use e-tickets when you can – print them out and keep them with your passport. If you do not already have a travel wallet to keep that stuff together, consider it a worthy investment. Keep it somewhere you can easily double check when you leave the house, car, taxi, plane, etc.

For a long trip you may want to ask your own bank if they have preferential rates for booking some dollars early and compare the rates + fee to the Post Office. Check if the fees and rate for just taking out money from a cash machine with your debit card are unreasonable, if not you might just want to just wait and see if you need any cash. If you do take out cash abroad, take out enough to see you through rather than across lots of transactions, as there does tend to be a per-transaction fee. Do not wait until the airport to exchange money, their rates can be quite bad.

If you are flying out for an interview double check the dress code expected in the interview. In game industry interviews it might hurt you more to overdress rather than to be too casual as far as “cultural fit” impressions go. However, do not go as far as packing dirty clothes!

For clothes you are expecting to wear at an interview, use dry cleaning bags. If you have stayed in a hotel before you can usually find these in the wardrobe. They help keep clothes wrinkle free, especially if you hang things up when you get to your destination. For smart trousers, use those hangers with the clips. On the way back you can separate dirty from clean clothes with the dry cleaning bags.

Choose an airline you think you will use the most and stick to it, members of frequent flyer programs are more likely to be upgraded. Get a decent carry-on suitcase that is close to the maximum size of your selected airline. Do not go to the size limit, connecting flights may have smaller overhead bins. Go for a midrange or better case; cheap suitcases are often badly designed and made of inferior materials. If you are unsure test it out by rolling it around the shop to get a feel for how it will be like wheeling around an airport (perhaps at speed!)

Pack light. Choose one book and one magazine, you will not have time to read more anyway, no matter your intentions. If you want more to do save up for a Kindle or use another multipurpose device you are already travelling with. Audio books ripped to MP3s are another good concession to your “not enough to read” tendencies.

Only pack one pair of jeans, and pick smart ones. Jeans are great because they can be worn more than once without becoming disgusting, but they are bulky. Be sensible about how many changes of t-shirts and underwear you pack, if you need more, you can buy some cheaply at your destination.

Gadgets – pack only your most slim line multipurpose device. Pack a charger for that and a multipurpose USB charger/cable for your phone, MP3 player, etc. Do not take your desktop replacement laptop if your netbook will do. Make sure you have Skype credit and the application running in the background; some airport Wi-Fi hot-spots allow you to use Skype credit to pay for Internet access. A compact Bluetooth headset can be useful for making calls to just about anywhere via your computer and a Wi-Fi connection – save on roaming fees!

When packing, try and keep one change of clothes within easy access. If something is spilled on you during a flight, you will be glad of it. Even if it’s a particularly uncomfortable flight and you find yourself sticky, a change of clothes can really help you feel not so grotty.

Try to never check any baggage. If something does go wrong you have everything you need with you. You will also be easier to place on alternate flights.

Many airlines let you take a carry-on and a personal item (such as a backpack). Some even allow a laptop case on top of that. If taking a laptop I suggest getting a slim neoprene bag that can fit in your carry-on just in case. Check with your airline first. It would be a shame to check a bag after taking all the trouble to avoid it.

Have the airline’s phone number in your mobile phone. If your flight does get cancelled and you need to find an alternative flight and the queue is long, queue up and phone out at the same time. Often the person at the end of the phone line can help you almost as much as the person you are queuing to see.

If someone on your plane has a cold, you want to do your best to avoid it – the last thing you want is to be jet lagged AND have a cold. For this I suggest Vicks First Defense spray… it actually works really well and can be taken preventatively. If you wait until the first signs, then it can be just as effective.

Eyes tend to get dried out on planes, but there is a kind of eye spray you can pick up from Boots called Optrex ActiMist. You spray it on closed eye-lids and it seems to do just about as well as eye drops you put directly in your eyes. It is expensive but has a longer shelf life then normal eye drops. I have yet to find a good place to get an American equivalent. It is an easy way to feel more refreshed while travelling.

Do not bother with those travel pillows, they can take up a ton of room that can be put to better use. I expect you can improvise something to prop your head with (like an airline blanket) if necessary.

Do take your favorite headache medicine with you. Avoid taking medicine with caffeine on the plane though, you should aim to get as much sleep as possible. Buy a cheap travel shaver (Phillips do a pretty good AA powered one) if you normally wet shave, or just buy a disposable razor when you get there. Remember to keep any creams or liquids (including toothpaste) to travel size.  Keep in mind that if you are staying at a hotel they will have many things you are tempted to pack anyway. Try and fit your creams and liquid containers in to a small transparent resealable sandwich bag before you go; with any luck it will be the correct size or smaller. Keeping them separately in a bag will also help prevent any spills in your luggage.

There are a few ways you can help shift in to the destination time zone temporarily. A few days before you go try getting up and going to bed an hour or two earlier than normal… which might be easier said than done.

One thing that I found out quite recently that works for me to combat jet-lag is to time meals properly while travelling. Your metabolism can give your body clues about what time of day it thinks it is. On the plane refuse meals or eat light for meal times that do not match with your final destination time zone. Again sleeping on the plane helps, though do not use alcohol to induce sleep; that will just leave you dehydrated!

Over to you

I am sure you have your own flying tips, why not share them in the comments?

I supported the Gameduino Kickstarter project and my reward was recently sent to me by the creator of the project, James Bowman. The community around this device so far is small but friendly. It includes electronics and programmers buffs from all kinds of backgrounds.

The Kit

One of the things that struck me when I first opened the box was how exposed everything seems! At some point I would like to either buy a case or mod something to hold the device; but as I have just moved from the UK to the Austin area in to a little apartment, I do not have the tools to fashion something myself just yet.

Here you can see the interfaces of the board. The ArduinoUno has a connection for USB and another for power. The Gameduino board provides a VGA connection and audio jack. The final board is a Joystick shield from SparkFun.

I put a pen in shot to give a sense of scale to the pictures.

The boards communicate to each other via pins and slots which can be seen in the picture above. The shields are designed in such a way that plugging things in the correct way feels natural. On my kit, the audio jack and USB are stacked directly in a way that makes it impossible to push the board all the way home; however, the pins are long enough that it does not matter.

After I constructed the device, the next thing I wanted to do was sit on the sofa with it and play on the television. After asking a few questions on the Gameduino answers forum I decided to try and use sixteen feet of VGA, USB and audio cable. I skipped buying a power supply as my television has a USB port – so I could buy a USB extension cable that is cheaper, less bulky and more generally useful.

Despite the length of the cable and low power draw of Gameduino, it works nicely (well for me anyway!) over that distance. So when playing the Gameduino, it only needs to be connected to the television – though granted via three cables. During development I use the laptop USB for both power and data transfer, while the TV acts as my screen.

Above you can see the boot screen of the Gameduino (which is on the right side of the Kinect under the television). It also plays a nice chord on startup.

Specifications

ArduinoUno (source)

Gameduino (source)

Why

I wanted to get back to basics a little bit. My favorite language these days is C# but for a long time it was C++.

I believe constraints can force creativity in some interesting ways. Necessity is the mother of invention after all. The Gameduino is constrained with its specification, though has many interesting quirks I look forward to learning about. For example, the co-processor needs instructions in Forth!

Next

Practicing skills and learning new things is always more interesting when trying to accomplish something rather than just going through exercises. I plan to have a little game of my own running on it in time. I have not got that far yet, but below is a sneak peak.

Jan Boon has written an excellent emulator “gdemu” that provides a pretty good simulation of the hardware that has been allowed me to develop in Visual Studio without deploying to the Gameduino each time. I forked it on google code, but as I am also teaching myself git and git flow I imported that over to github.

I have started to get used to the processing based environment provided for Arduino. Projects are called sketches and basically include all the c/c++ source and header files in a folder. It is an IDE that provides a way to compile and upload your program, plus serial monitor which is helpful for sending debug messages. I do not think there is a way of stepping through code on the device without more hardware though.

My aim is to try some test driven development with the Gameduino now I have explored it a little. Ideally I would like my own project to be built and deployed to the device via a single line on the command line or a double click of an icon… I am not there yet though.

If anyone has any Gameduino projects to share or has worked on similar devices, please say something in the comments. It would be nice to know that people are reading this!

Further Reading

• Gameduino site
• gdemu Gameduino Emulator – Jan Boon (via forum)
• Gameduino Reference Manual (pdf) via Derek
• Gameduino Tutorial via Fungus
• Arduino development environment
• Gameduino Coprocessor
• Gameduino Reference Poster
• Gameduino sample programs and library
• Gameduino Python Package
• Gameduino for Artists
• Gameduino Answers
• Gameduino twitter – tweeting and retweeting community activity with the Gameduino
• Gameduino articles by Mark VandeWettering
• Gameduino sprite tutorial by David Roberts

The “Micro Talk” format

Every participant is given ten minutes to talk. A time keeper near the front of the stage flashes up cards when the speaker is near the end of their session so they can wrap up the talk. There is also a longer message for when a speaker goes over that limit.

There are variations where the time limit is less strict.  Sometimes there is a defined period of time for Q&A that may be filled. I recall as part of my Bachelors degree we had strict time limits and a QA for presentations on projects; so those from an academic background may be familiar with this style already.

Ten minutes is time enough to cover a large subject at a very high level or a very specific topic in detail. This forces focus and sets the pace for all the talks.

For the speaker ten minutes should be relatively easy to fill about something they know about. If anything, reducing things down to ten minutes may be an issue.

For the audience ten minute bite-sized chunks of content should be digestible even if it is something individual members have little interest in.

Creative Day 2011 at Lionhead Studios

A similar format was used for Creative Day at Lionhead Studios.  We did not use the term “micro talks” but that is what the format was at the core (though without the very strict time keeping). Everyone who participated was given a short time to introduce their project and demonstrate it. Some ran under and some ran over but every presentation got part or all of the audience interested. Each team was given a couple of days of studio time to complete their own project (and as much of their own time as they wanted of course).

The Lionhead event has been quite well covered in the industry press. The project I worked on was one of the lower profile ones that just gets a mention in Edge. I worked with developer Pete Coward and musician Kai Chi Chan on a reimplementation of Populous in HTML5, which used a multiplayer server implemented using node.js.  Our proof of concept was implemented in a few days.

The demo itself had a few technical problems due to us trying to improvise a wireless network.  It got a bit overwhelmed by a cinema full of developers trying to connect to it with laptops, iPads and mobile phones… but overall the presentation was well received and the multiplayer capability was demonstrated. We kept things going long enough to show Peter drowning little people by lowering some land in to the ocean, which got a good laugh.

It was an emotionally charged experience presenting to all the talent of the studio – especially considering some of the mind blowing things that were demoed before we were up.  Keep in mind that most of the people presenting were not at all used to being in the public eye. In the relatively safe environment of that cinema full of colleagues, everyone shone. Every single presentation had something interesting to give and add to the day. People really got to know each other better that day.

If IGDA Guildford ever gets going again – meetings in this format should happen.  There are enough people working there to support it!

IGDA Austin Micro Talks (2011-06-25)

My first IGDA Austin meeting was in the micro talk format and provided a great introduction for me to some of the people in the chapter.  The talks took place in a television studio and were recorded – so should end up on YouTube at some point in the future.  See the austingamedevs.org website for further details.

John Henderson acted as master of ceremonies, introducing each speaker and announcing breaks between the speakers. At the end of the breaks he took the opportunity to introduce some of the volunteers around the hall that were running the event.

Jon Jones opened up the evening with a talk about making yourself more attractive on the job market by differentiating yourself. His example used a character artist portfolio with a few stereotypes that got laughs from the audience. The drive of the talk was to be a little different by thinking creatively and to actively network. Many of his own career advances had come from networking and he said that he pushed himself to get out there. He made special note to try not and make enemies, as you never know how that will come back to bite you later.

Denis Loubet made a presentation about how much luck there is involved in creating a profitable iPhone game. He made his presentation without aid of slides. The message I took away from that was that it was better to prototype an idea and ship early before investing too much, as you can never be quite sure where lightening will strike. Rovio made a few games before their success with Angry Birds.

Sara Jensen Schubert’s session was about using a spreadsheet to balance progression in an RPG. Consistency was highlighted as an imported factor in progression. Second to that was modeling enemy stats close to that of the player to make things easier to manage later on. It immediately reminded me of systems I had seen used around Lionhead that our tools supported. I think Sara and my friends back in the UK, Mike West and Kalev Tait – would have a good talk about their various ideas for balancing.

Fred Schmidt made the case for how awesome Austin is, the history of the area and how the creative industry fuels the economy. There needs to be more engagement across the educational, public and private sectors to better support the many small companies doing amazing things in the area.

Damion Schubert spoke about the power of innovation – where it is useful and when it should be reined in. Innovation can take many forms, from simplification of an idea to something completely new. An innovative game should be explainable in a sentence and have true resonance with the audience. Swing big, make sure the players get to use your innovation and support it through every other element of game play. Remember that an idea is only innovative if it is better, and that it should be less expensive than making a “me-too” product.

“From Startup to Survival” by Quoc Tran was an interesting study in what can make the difference between success and failure in a start up. It boiled down to focus, underdo the competition and release early. Remember that resources are limited and that if cash is a problem, ship sooner. The feedback generated and market position achieved by shipping sooner is more important than a complete feature set.

Carl Canga made a presentation about how important investing for retirement is. Despite the presentation slides not working, Carl went on to make a well rehearsed presentation. It was certainly a sobering talk for me and something I will make a priority as soon as my means allow it.

Conclusion

Presenting and demonstrating things in front of an audience even just for ten minutes may seem daunting but there is no doubt in my mind it is worth it. It is a great introduction to public speaking and one I personally intend to try again. I encourage you to try it out – either at your studio, an IGDA meeting or wherever you can.

The conversations during the breaks at events like these are also invaluable. It is a great way to make friends and eventually introduce people who can help each other out. Get yourself out there!

Never under estimate how important it is to communicate the knowledge you have to other people. What you write or present will never be useful to everyone – but even if you help a few people out, it is worth it.  Why not try writing for #AltDevBlogADay?

About this article

I wrote this in Star Coffee in Round Rock, TX while slowly drinking an iced mocha. It is written from my own notes made in OneNote last night and some others that Danni (my wife) made. While writing this I’m listening to a Blue Grass jam session. I’ve only been in the Austin area for a few weeks – and although I am still adjusting to the baking hot weather it has been a good experience so far. I have no doubt that this place is another great creative hub.

XmlSerializer versus DefaultValueAttribute

The DefaultValue attribute is useful for giving hints to the user interface controls, particularly ones that inspect objects such as the PropertyGrid.  It allows objects to be created using their  default constructor then have their default value set later by the control responsible for it.

The XmlSerializer also takes this value in to consideration when writing an xml representation of the object.  If the class member being serialized has a value that matches the value declared by the DefaultValue attribute it skips writing the value all together.  Less written, less to read back – looks good.

XmlSerializer does not restore the value of DefaultValue to a member when reading an xml representation of an object, it uses the default as defined by the member type (null for classes, 0 for integers, etc.). This is the potential source of confusion; you cannot rely on the XmlSerializer to create perfect deep copies of your objects. It does not assume missing xml means “use the default value attribute”. XmlSerializer has implicitly set the expectation on your code to restore the default values from the attributes.

Demonstration

I have embedded commented code in the post below that demonstrates the above.  I have also uploaded it to github.

// See Clue class to change demo behavior.
// Uncomment one of the fixes below to observe different behaviors.
// Search for FIX1 or FIX2 to see where the changes have been made.
//// #define FIX1  // Do *not* use DefaultValue attribute, taken in to account serializing but not de-serializing.
//// #define FIX2  // Set default value of variable to same as DefaultValue attribute during construction.
 
namespace AsymmetricXmlSerializer
{
    using System;
    using System.ComponentModel;
    using System.Diagnostics;
    using System.IO;
    using System.Text;
    using System.Xml;
    using System.Xml.Serialization;
 
    /// <summary>
    /// Class to be serialized and demo point for asymmetric XmlSerializer behavior.
    /// </summary>
    [Serializable()]
    public class Clue
    {
        /// <summary>
        /// Comment out DefaultValue attribute and it will succeed.
        /// </summary>
        /// <remarks>Set variable to 'Nothing To See Here'to to work around.</remarks>
#if !FIX1
        [DefaultValue("Nothing To See Here")]
#endif
#if !FIX2
        public string text;
#else
        public string text = "Nothing To See Here";
#endif
    }
 
    /// <summary>
    /// Demo program for asymmetric XmlSerializer behavior with DefaultValueAttribute.
    /// </summary>
    internal sealed class Program
    {
        public static void Main(string[] args)
        {
            // If initial value is the same as DefaultValueAttribute for variable declaration,
            // it is not persisted by XmlSerializer.
            Clue clue = new Clue();
            clue.text = "Nothing To See Here";
 
            // Buffer for writing.
            StringBuilder buffer = new StringBuilder();
 
            // Don't need namespaces.
            XmlSerializerNamespaces no_namespaces = new XmlSerializerNamespaces();
            no_namespaces.Add(string.Empty, string.Empty);
 
            // Don't need xml declaration.
            XmlWriterSettings writer_settings = new XmlWriterSettings() { OmitXmlDeclaration = true };
 
            // Serialise the clue...
            XmlSerializer xml_serializer = new XmlSerializer(typeof(Clue));
            StringWriter string_writer = new StringWriter(buffer);
            using (XmlWriter xml_writer = XmlWriter.Create(string_writer, writer_settings))
            {
                xml_serializer.Serialize(xml_writer, clue, no_namespaces);
            }
 
            string serialized = buffer.ToString();
 
            // Show serialised version of the clue...
            Console.WriteLine("Clue text value: {0}", clue.text);
            Console.WriteLine("Clue serialized: {0}", serialized);
 
            // Deserialise the clue...
            Clue clue_read;
            using (StringReader sr = new StringReader(serialized))
            {
                clue_read = (Clue)xml_serializer.Deserialize(sr);
            }
 
            // Show clue 2 on console
            // Reset and reuse write buffer.
            buffer.Length = 0;
            using (XmlWriter xml_writer = XmlWriter.Create(string_writer, writer_settings))
            {
                xml_serializer.Serialize(xml_writer, clue_read, no_namespaces);
            }
 
            string reserialized = buffer.ToString();
            Console.WriteLine("Read Clue text value: {0}", clue_read.text);
            Console.WriteLine("Read Clue serialized: {0}", reserialized);
 
            Debug.Assert(clue.text == clue_read.text, "Written & read clue's text should match");
        }
    }
}
 
/* NOTES
 * FIX1: Don't use DefaultValueAttribute.
 *
 * You would want to use DefaultValueAttribute to avoid persisting the
 * default value to the xml representation.
 * Although this does prevent the default value being persisted, on read the
 * DefaultValueAttribute is ignored so the value is never set to that of
 * the DefaultValueAttribute.
 * DefaultValueAttribute is also used for value hints for UI.
 * See: http://msdn.microsoft.com/en-us/library/2cws2s9d.aspx
 *
 *
 * FIX2: Use DefaultValueAttribute AND default value at construction.
 *
 * To use DefaultValueAttribute and have the object be recreated
 * properly when reading it back, you must to explicitly set the
 * default value during construction of the object being read.
 * Using this method means the xml is concise and the object
 * is accurately recreated.
 */

I am most familiar with Perforce for source control these days because that is what we use for a lot of the code at the studio, so I also took this as an opportunity to try and host something on github: https://github.com/PaulECoyote/js1k/tree/master/3.oregon

Unlike compiled languages that can use excellent crunching software like Crinkler to compress the executing code down (excellent article about the process), the interpreted source code has to be 1024 bytes or less.  As JavaScript has 16bit character strings, submissions had to take care they were within the byte limit rather than just counting characters.

Design

First of all I have to admit it, I never played the Oregon Trail game on the Apple II.  I was born and grew up in the UK where I used great 8-bit machines like the Oric-1, Acorn Electron, BBC Micro (at school), Spectrum and C64.  Apparently there was a version for the C64 but I missed out.  Helpfully the demo organizers linked to a play-through on YouTube (just to warn you, there’s some raw language in there).  So one Saturday morning when I got up way too early for my own good, I decided to watch it.

Apparently people often die of Dysentery (eek!) while playing, though that did not happen on the play-through I watched.  I thought of trying to do a simple inventory management trade game, but the sheer volume of text and inputs made me think again.  I then thought I could do something about crossing the river but some people had already made something similar to what I was thinking.

Finally I settled on the idea of traveling down the trail itself.  There was already a nice wagon graphics demo there but with no game play, so the idea was unique enough.  A lot of the game during the play-through seemed to center around a wagon travelling down a trail and stopping at landmarks and rivers.  Crossing rivers involved complex decisions that would take me down the complex text simulation route again.  I decided that my wagon in 1848 had a crazy inventor that fitted the wagon with excellent suspension and a spring wound so tight that it provided a KITT like turbo boost to jump rivers.  It was my little game, I could have some creative license!

Implementation

I started out by looking at tutorials at the MDN.  First I drew a background using a linear gradient with the help of this tutorial.

Next up I wanted to draw a wagon, I decided to keep it simple and use rectangles and circles to keep the source code simple.  After that I wanted to show movement, so next up was drawing a tree moving along the landscape.  The drawing shapes tutorial helped me figure out how to create the shapes and I wrote the game update function within an interval set every twenty milliseconds.

So I had a wagon that looked like it was moving, then I wanted a river.  I experimented with a few different shapes but a thickly drawn blue line took up little space and got the feeling across of the river.  I animated this at a slightly different speed to the tree to try and get the feeling across that the tree was in the background and the river was in the foreground.

The game never ended, so collision detection with the river was next – as the wagon never moved along the x axis, it was quite simple.  Then to implement the turbo boost – collision with the river only happened when the wagon was at ground level.  Playing the game at that point there was a way to multiple jump… which was kind of fun but made the game too easy.

When the wagon collides with a river the game comes to an end.  Refreshing the browser auto starts a new game.

I needed to display the score next which made it feel more like a score attack game.  The game seemed too easy to me though, so I made the river slowly grow.

Looking at the file size it was over twice the 1k limit, so time to shrink the file.  First I removed all the comments, then all the whitespace.  Still way over.  Renaming the variables to single or double character names shrunk the file to just under the 1k limit.

Future

• Use some kind of automated code shrinking tool. packer by Dean Edwards looks like a good place to start.
• Animate the wheels
• Have scrolling hills going at slower speed than the tree in the background to add more feeling of depth
• Use mechanized abbreviation to shrink the code further, as explained by Marijn Haverbeke.
• Experiment more with git – gitflow look interesting

Conclusion

It was a fun little experiment and a nice project to learn a few new things.  The source code is here – I am sure there are a hundred ways to improve on it.  The other entries in this competition can be found here.  Visit js1k.com to see the entries for all three of the competitions that have happened so far.  It really is incredible what can be done with so little source code.

The Challenge

Here’s a challenge. (For those of you that haven’t already written your next posts.)

A very human problem and one that censors many of us all too often, is the fear of looking stupid.

I challenge everyone to confront that fear head on. Think of that something that you wish you knew more about. That you feel slightly insecure about. And rush in head on. Talk about your fear. Admit it. And share your thoughts. Share what you do know. And what you wish you knew. Invite people to help you grow.

Shine some light into those dark areas of yourself. ;)

I’ll do the same.

Mike.

What I know

I know that just because something is scary does not mean you should not give it a go.  Failure is not something to be afraid of, but to learn from and grow.  Obviously you want to try and stack the odds in your favor though.  Making a living from products that you have created, sell and own sounds great to me.  Though it does sound… dangerous.

I have gathered requirements for business products, specified, programmed, deployed and supported them in the field.  In the games industry I’ve worked on development tasks centered around tools and deployed them across the studio.  I helped out with the odd game bug here and there.  Although credited on excellent AAA titles, I have not shipped and sold a game independently.

I had a great conversation with Tak Fung (@mrfungfung) at Winter World of Love 2 about his transition from being a coder working on AAA titles at Lionhead Studios to living solely from his own creations MiniSquadron, EpicWin and Fox vs. Duck.  He swapped full time work for contracting which helped him make contacts and wean himself off a monthly wage – a self-bootstrapping slow transition.  Tak works from home and contracts out things to make his games as necessary.  I hope a video of his talk appears online at some point, I think many people would be interested in it.

I met up for pizza with Byron Atkinson-Jones (@xiotex), Jeffrey Sheen (@stargazystudios), Matthew Hanlon (@thebag1981) and Cliff Harris (@cliffski) after Winter World of Love.  Some design and money talk was had over pizza and beer.  To get an idea of some of the conversation (guidelines about how much money you need to make etc.), watch Cliff’s talk from 2010 at a Winter World of Love 2010.

Matthew Wiggins (@wiggo) co-founded Wonderland Software who have released GodFinger – I do not have many details there but I believe they managed to get some outside investment.  They (twitter list) have a decent game on the market, a nice office and have been making a living from their creation.

Sean Murray of Hello Games spoke at Winter World of Love 2010 (video) about Joe Danger and doing it yourself.  Sean started off talking about how he got started programming young, ended up at EA then founded Hello Games.  He goes on to talking about the passion behind Joe Danger and how risk adverse publishers are.  The money a publisher would have put in came from themselves.

Keith Judge (@KeefJudge) is leaving Lionhead this week to be an independent developer.  He has a wife and child to support, but has enough confidence to try the lifestyle out.  I hear people all the time saying they want to try, but have too much responsibility to try and work for themselves.  Take a look at his first blog post on #AltDevBlogADay.

What I don’t know

Business plans.  I can recall bits and pieces of some business modules during my Computer Studies degree, and a GCSE in Business Studies more years ago then I would like to think about right now.  I am able to handle my personal finances pretty well with a steady income – though I can only believe it gets much harder when your personal finances are linked with the successes and failures of your products and services.

Real numbers. What can someone expect, how do they budget?  How do you manage the risks, set the price point?  How on earth do people make money from the free Flash games you see on websites?  Or from free games at all?  Is “free” really just “shareware” under a new name?  How do you combat piracy – is DRM even worth it anymore?

Art. If I were to program my own independent game I really do not know what a fair price for art and music is. A revenue share? A fixed price upfront? I feel there is a tension there between getting eye catching art that generates sales against art that is good enough to sell a game and still profit. How do you decide how much to spend on a games assets and not end up losing money?

Publicity.  I find blogging and tweeting quite natural, though I have never had to professionally market anything apart from myself.  I am very proud of the projects I have been involved with at Lionhead and tweet links etc about that… but press packs, getting interviews and press coverage?  People *want* to talk to Peter Molyneux; game journalists contact the studio all the time to talk to the man.  I am pretty sure restricting press access for games is not how it usually works – especially for an independents!

What do you know?

Here are some more links to related articles I have found interesting in no particular order.

• Analysis: World of Goo’s iPad Launch
• SteamBirds: Survival – By The Numbers
• http://www.lostgarden.com/
• 12 business tips for indie game developers
• Can you make money on XBLIG?
• Making money in Xbox 360 indie game development: Is it possible?
• Getting your game on Big Fish Games
• Everything I ever learned about marketing I learned from Dungeons and Dragons
• More Tender By The (Redacted) Numbers
• http://www.gamesbrief.com/
• Bootstrappers’ Kickstarter Kit – No Investment Required
• 31 Days to Start Freelancing
• http://unicornfree.com/
• Free is good
• Kill yr ads… the don’ts of iPhone app marketing
• Cliff Harris Business Blogs
• http://www.indiecity.com/blog/

In the comments please share insights and links about the business of creating independent games. I am sure there is no one right answer, but many.  I am certain that many reading this blog may have written some things themselves… please link to them here.

Update: Links from feedback

• Celsius Game Studios (@celsiusgs) Indie Gamedevs: You’re (Probably) Doing it Wrong 
• Four Dour Lemon (@barog)- Indie Studio Considerations Part 1 Part 2 Part 3
• Ed Bartley ( @FishFPG ) – What’s your Indie Strategy?
• Noel Llopis (@noel_llopis) – http://gamesfromwithin.com/
• Paul Firth (@paul_m_firth) – The reality of being a new developer on Facebook
• Christopher Waite (@chrismwaite) - 10 don’ts of iphone game development, World of Love 2 – an indie games conference
• Bob Koon (@Bob_at_BH) – Your New Life As An Indie/Contractor

There are times when people just want to get their head down and get their stuff done.   As a coder myself, I know the importance of having a stretch of uninterrupted time to finish a thought when coding.  Switching tasks abruptly can ruin the rhythm and flow of the creative process – it can take time to regain that momentum once you have been disturbed.

Constant interruption slowing down completing your tasks might cause you to seek solitude.  Solitude is useful at times and a good producer / manager will shield you, as a creator, from interruptions or interference when what you have to finish is more critical than anything that you could be interrupted for.  The danger is that prolonged isolation causes segregation – information becomes filtered from what you need to know to what someone else thinks you need to know.  Communication happens on the side of the listener, but a listener has no chance of communicating if they are being shielded from what is being said.

The funny part of all this is that a person can be in both situations at once.  They can be told too much and expected to be reactionary to one type of thing and not find out about something else that would help them be more effective.  This kind of dysfunction can occur internally in a team, but is perhaps more likely to occur between different teams where information exchange is naturally more guarded.

To counteract too many interruptions, try learning the power of saying no – do not take on more than what you can do.  Make sure if you are being constantly interrupted that this is accounted for in your estimates.  Let the person know that if you do x, that will mean y will have to wait.

If you are feeling left out of the loop make sure you take time to talk to people.  Build some time in to your day to keep in touch – instead of waiting at your desk for a long build to complete, go interact with someone.  Studios and companies are defined by their people and their interactions; without people you just have some office furniture in an empty building.  If you are work for a big company, during lunch try introducing yourself to different people now and again.  If you are a programmer that always hangs out with programmers, why not try and make a connection with an artist.  Try and dispel any “them and us” if you start to feel it.

Connecting with your colleagues can be a very rewarding endeavor – you begin to be able to introduce people to each other that can solve each other’s problems.  It enables you to help more people, because even if you cannot help someone, you know someone who might.  Connecting people might mean effort is not wasted or duplicated, and help work to be co-ordinated.  You can get a better understanding of how a company works as a whole and through these small social actions make things better.

I have heard it said that many important conversations happen during smoking breaks.  Relationships are sometimes forged during drunken nights out.  Personally I don’t smoke and tend not to drink very much… but you do not have to smoke or drink to excess to join in these things  now and again.  Making new connections deserves some effort – people who seem to have many strong connections worked hard at it.

For small studios and companies it makes sense to make room in your calendar for local and industry events.  The gaming conferences I have been to have had some amazing lectures.  A person who just went to those and did not try and socialize missed out on an opportunity though.  For smaller companies in particular it is vital to have trusted peers you can share ideas with and swap tips; so many important things happen as a side effect of the main event.

At the end of Mike and Matt’s recent #AltDevBlogADay podcast (March 17th) they stated an aim for #AltDevBlogADay is to be like a perpetual game conference.  Although the web can never be a substitute for physically meeting people, it is a worthy goal and participating in it does feels a bit like a conference.  If you are interested in game development and want to try and engage with more professionals, try a guest post on this site.  Get your voice out there and start some discussions about something that is important to you – it could make a positive difference to your career!

High level summary of what we discussed:

• What is your favorite DLC & why?
• Is DLC on the disk ethical?
• Discussion around DLC pricing.
• How can DLC effect game balance?
• DLC and player status.

The voices you hear in order of appearance:

• Paul Evans @PaulECoyote (Programmer).
• David Addis (Programmer).
• Kalev Tait @KalevTait  (Designer).
• Keith Judge @KeefJudge (Programmer).
• Bryn Davies @LH_ClarkyCat (Designer).

Thanks to everyone who took part.  Special thanks goes to my wife who spent some of her time over the weekend post-producing this.  Should I try this again with any luck I will do a better job with the advice she has given me.

Update: The original audio files linked have been updated.  Michael Taylor @stomp224 (Audio Designer) kindly offered to clean up the audio some more.  Find him at http://www.stomp224.co.uk

As with Mike Acton’s audio posts, this comes with no warranty, transcription or satisfaction guarantee!

Round Table: DLC (Part 1 of 2)

Round Table: DLC (Part 2 of 2)

I extend this thought to other defensive practices like checking for nulls indiscriminately – even where there never should be one. Sanitization of external data is prudent and necessary, but once things are safely inside your own codebase you have control of the expected range of values and should be able to trust that.

What an assert does

An assert stops execution and flashes up a message when a condition fails. If there is a debugger attached then if it can it will direct the programmer to the source where the assert fired. Great for the programmer trying to track something down, rubbish for someone else who has to skip the message (perhaps many times) to do what they are trying to do.

Asserts disrupting workflow for other programmers and disciplines have been mitigated in a few ways. The following are some more common methods:

• Builds with asserts turned off
• Asserts with a concept of levels or categories that can be toggled
• Assert instance toggle – it will appear once but as well as skip there’s an option to ignore

Crying wolf

Asserts that continually fire create too much noise; unless the game completely falls over then people start to not take any of them seriously. Just like compiler warnings there is a point where many eyes just glaze over the number and a number above zero becomes an excepted part of life… perhaps even becoming a joke.

Do or do not, there is no try

Asserts show a lack of confidence of an operation being successful – so much so that a human being should be warned. It is a developer communicating with themselves and others that at some point something is in a state so dire that normal execution must be interrupted so someone can take a look. I do not believe having that kind of warning permanently buried and hidden is healthy. It is preferable to either formally test and handle the situation if it really is expected, or get to the real root of the problem and prevent that invalid state from ever occurring.

Sanitize the data once properly rather than repeatedly sanitizing the same data in the same way throughout the program just in case. Every time a conditional statement is encountered there is a computational cost associated with that. A code block could have its own setup and destruction costs – perhaps more so if exception handling is being used. This may seem like premature optimization but clear concise code is easier to digest for man, compiler and machine. After all the best kind of processing is the processing you can eliminate – look to improve your algorithm.

Asserts in the middle of a method after a long conditional block could indicate that the method could be broken in to smaller more focused testable methods. If possible architect so that a method will always succeed in some measure to allow callers to expect the same predictable outcome. If a function should always return a populated something, use a default something rather than null. For example use a valid bright pink texture for missing data and log the error rather than just returning null and forcing everything from that point on to check for nulls.

Silent but deadly

A badly written assert may cause a side effect as part of testing the condition perhaps without the programmer even realizing it. When an assert like that is disabled it causes different behavior between types of builds.

Worse is when an assert expects to be heeded in the same way as exception. Ignored or absent through compilation options, execution blunders on and states become corrupted, going on to cause unpredictable problems later. Perhaps that problem will even mask itself as an issue with a completely unrelated system. In the worst case corrupt data could be persisted, ruining a saved game.

Asserts encourage a codebase that constantly tries to correct itself rather than addressing the real problem. Methods no longer trust each other to fulfill their remit. Expectations of callers change from “I should only give it foo” to “I can give it foo, bar or nothing at all”. Those expectations can virally spread throughout the codebase causing more methods to second-guess each other and bloat.

The truth is out there

Earlier I stated that asserts in the main body of code shows a lack of confidence and are used to try to mitigate bad states. Used in the context of test functions they serve to communicate an expectation of success. The tests can be run independent of running the game or application itself and provided with sample of runtime data to consume. Instead of the same assertions being made in multiple places against the same method scattered across the codebase, an expectation for a specific scenario can be stated exactly once.

Asserted expectations can be gathered in a test suite to form a living document in code that provides examples of use that are easily found. Compile time can be quicker for coders because tests can be separated out in to different projects – run only during the testing phase of a change and on the build machine.

Conclusion

Asserts in the main body of your code clutter the logic and could be expressed more concisely elsewhere. Programming too defensively could blur the responsibility of what is being written. Do not always code “just in case” otherwise callers will start to rely on the defensive parts. Either set the expectation of a method to always sanitize (and perhaps hint at that extra processing in the name) or fail as gracefully and quickly as possible. Many applications and games are closed systems that have predictable points of failure, only the input from the boundaries should be considered for sanitization.  Failed asserts should be a point of immediate failure – though I would argue there are better ways of indicating failure.

Asserts are very useful for debugging, but be wary of the costs of permanently committing them to the main body of your source code. Logging error messages and substituting inert values can be far less obtrusive then relying on asserts breaking execution and popping up message boxes. It is outrageous for a tool that is supposed to run unattended to stop everything waiting for input, just fail and exit.

Asserts do belong in source control when used to formally test methods and when they clearly express specifications.  This kind of living documentation created by asserts is a form of cover fire.  If you cannot separate asserts in to formal test methods to create clear behavior specifications, try and gather them together close to where the bad state will first occur.  Group them close as possible to where an errant call could first appear on the stack, rather than scattering the expectations around deep in the code.  Let the developer see everything that is expected at a glance.  Asserts should help avoid detective work after all!

There are many advantages to taking asserts scattered through your code and creating test suites from them – see my previous article Cover Fire for Coders.

Further Reading

Some other related #AltDevBlogADay articles about debugging and asserts you might be interested in:

• Tips and Tricks for Debugging Optimized Code by Max Burke (@maximilianburke)
• Debugging Tools by Justin Liew (@justin_liew)
• Looks like I’m up by Jaymin Kessler (@okonomiyonda)
• Elegance in Failure: How and when to crash horribly by Ben Carter (@CarterBen)
• Think low level, write high level by Chris Kosanovich
• Handy Developer Tools: The Sandbox by Max Burke (@maximilianburke)
• #AltDevBlogADay programming category
• Cover Fire for Coders by Paul Evans (@paulecoyote)

Some books you might be interested in:

McConnel, Steve (2004). Code Complete – 2nd Edition. Microsoft Press. ISBN: 0-7356-1967-0

Chapter 8 covers the split between debugging tools and effectively handling failure in production code. It supports quite some things that I advocate in this article in a much more detailed discussion. One of my favorite quotes from the chapter: “Sometimes the best defence is a good offense. Fail hard during development so that you can fail softer during production”.

Keith, Clinton (2010). Agile Game Development With Scrum. Addison Wesley. ISBN-13: 978-0-321-61852-8

This book covers how spending time eliminating technical debt can help create a more predictable schedule and end up with a more focused, polished game.

[Paul Evans is a central technology programmer at Lionhead Studios. He has worked on the Fable II, Fable III and other unreleased titles. You can find him on Linkedin, see other things he has written on his personal blog, and follow him on twitter. Everything in this article is Paul's opinion alone and does not necessarily reflect his employers views. Copyright ©2011, Paul Evans.]

You are coding away and suddenly realize that there is a vital piece of new data you need to propagate through the battlefield of your game (or application) for your change.  Your heart sinks… you are going to have to take drastic action.  It will be tricky to safely create and navigate that vital piece of data through the lines.

A complex web of method signatures fill the field like barbed wire between your data and its goal – painful for both friend and foe.  Tracing back from your goal, you come across comments from generals that have trodden a similar path in the past and shudder at their remarks.  Some of them had to do some rather unsavory things, some warn against the consequences of using exactly the method you were thinking of.

You wipe sweat from your brow; is it really worth it to try and guide this plucky new data across such a hideous mine field?  A message from the tower tells you that you have no choice.  Reluctantly you make a plan for the fresh data recruit to cut through the battlefield at a certain point.

Your data makes it through and helps fortify the frontline – it all looks good.  Only three months later does a subtle change you made show up as having a hideous side-effect on the entire outcome of the war.  A halfling managed to make it behind the lines and is causing all kinds of problems.   But your plan was reviewed by one or more generals!  No one saw anything wrong with it!  Until that day when it *all* went wrong and now the Eye of Sauron is focused squarely on you…

If only there was an alarm hooked up… a simple safe guard to indicate there was something amiss. Find a way to test, this story need not be about you!

Allow time for tests

Managers and leads, please allow time for tests in schedules.  Programmers, include extra slack in estimates for writing them.   There are many reasons why – but it all comes back to your definition of done.  Is “it works for me” good enough?  Is it enough to set things up and assume everything will go to plan?  When is something really signed off?

Scott Evil: Wait aren’t you even going to watch them?  They could get away!

Dr. Evil: No, no, no; I’m going to leave them alone and not actually witness them dying.  I’m just going to assume it all went to plan, what?

… and Austin Powers escapes.

Benefits of automated testing

For the coder it is like cover fire.  Every test is another sniper covering some small part of the code for you.  If something flashes up in their scope they can immediately warn of some nasty bug lurking.  That regressive bug never gets a chance to get a foothold.  Each extra test watches out over your software at a different angle and cumulatively they become a very useful force.

A well written test reviews your code – not on how you wrote something like a human reviewer might – just against an expected result.  A rational coder can not argue their code is decent if it fails a good test.

Tests form a kind of living functional documentation that any written form can never hope to compete with.  If a test becomes obsolete it is changed to fit a new requirement or even removed entirely.  Anyone that can write code can understand and write the tests.

A good test suite can even aide the gung-ho programmer that is desperate to rewrite a big chunk of code (ahem Alex Evans :-) ).  As long as the new code satisfies the integration tests and functionally achieves the same thing – have at it.  But before rewriting create some tests to measure performance, then after the rewrite the new work can have proven value.  If another change in the future reduces performance an alarm bell will go off.

Code passing a good set of tests in a branch can give any coder the confidence that a clean get from source control will result in a successful build of useful software.  That could be a pivotal moment for getting together something presentable for that last minute demo.

If you cannot test something, then it is unlikely that the code in question is fully understood.

But I can’t test

I can’t test because I don’t know where to start… there is just so much already there!

• Some tests are better than none.

• Try “Tracer Bullets”[2] to shoot down bugs and introduce tests to your game / application:
  • Create a test that tests the bug and fails.
  • Fix the bug, make sure the test now passes.
  • Commit and resolve.
  • Now if anyone regresses the behavior, your test will catch that right away.
  • Test coverage is cumulative – more bugs fixed in this way increase coverage at valuable pain points.

I can’t test because I don’t know what I expect yet.  I’m still figuring that out.

• Prototype to investigate the problem domain.

• It would be helpful to set a time box around the research period (a “spike” [4]).
  • Setting a time limit will allow you to :
    • Step back before going too deep down a rabbit hole.
    • Concentrate on estimating the size of the problem domain.

• Concentrate on figuring out what to test – the tests are likely to be usable even if the prototype code is not.

I can’t test it because there is no one expected state.

• Just think creatively while writing the test.  For example :
  • If a test is for randomness, then obviously there is no one predictable state.  But there can be a fitness function that defines how random something should be.
  • If looking for problems in a scene screenshot, perhaps a test could ensure a reserved color used for missing textures is not present.

I can’t test it because I cannot isolate the behavior to test

• This could indicate:
  • Possibly blurring of responsibility with highly dependent and coupled code (perhaps too general).
  • Code could be reaching through objects, violating the principle of least knowledge.
  • Architecturally a lot of cruft is required to access useful behavior.
  • Code has been added to workaround a prior issue rather than refactored for a new requirement, adding to the cruft.

• Rework to be testable if you can, try to isolate and retire if you cannot.Rework to be testable if you can, try to isolate and retire if you cannot.

I can’t do all these tests, it would increase build time

• Keep tests in separate project or solution, you can run them only before committing to source control.

• Ensure each test does not take long to run, mock where necessary.

• Partition tests that must run for a long time.  Perhaps only run them on the build server.

• Partition tests per module so that only particular module and integration tests are executed.   This gives the coder the choice to only run the tests they need.

I can’t write tests, I just do not have the time

• This one is the hardest thing to overcome if there is no management buy-in to testing.  As a programmer at any level try your best to campaign for more scheduled time.

• Writing tests gets quicker as a programmer gains experience (just arrange, act and assert one thing in each test).

• Once tests start proving there are fewer regressions being reported in the bug database, it is an easier sell.  Gather any time saving metrics you can.

Summary

To many game developers I am sure tests don’t seem very rock & roll… not something they may have considered to be part of their role in the industry.  So I expect many do not test their work.  Writing elegant tests can present interesting engineering challenges and can be a good way to understand something that is new to you.  There is satisfaction to be had when all your tests pass after a big change, or when you realise a test saved you from an obscure bug or bad design choice.

Testing is no silver bullet, but try to think of it as an investment against that same bug being reopened many times later on.  Wouldn’t you rather spend time on polishing something else then finding and squashing the same bug again?

Further Reading

Other articles on AltDevBlogADay by Paul.  Text about testing and asserts is “Do or do not”.  Paul’s personal blog.

Clinton Keith’s book is written for game developers that want to think about different ways of prioritizing and scheduling tasks during game development.  It includes many reasons for testing and many interesting stories from the front line.  (For the purposes of disclosure he was also kind enough to acknowledge me for helping him out a little bit).

The other books listed are not specifically about game development but software excellence in general.

[1] Keith, Clinton (2010).  Agile Game Development With Scrum. Addison Wesley.  ISBN-13: 978-0-321-61852-8

[2] Richardson, Jared & Gwaltney, William (2005).  Ship It! A Practical Guide to Successful Software Projects. ISBN: 0-9745140-4-7

[3] Martin, Robert C. (2003). Agile Software Development: Principles, Patterns and Practices. ISBN: 0-13-597444-5

[4] Pryce, Nat (2010). Growing Object-Oriented Software, Guided by Tests. Beck Signature. ISBN-13: 978-0321503626

[5] McConnel, Steve (2004).  Code Complete – 2nd Edition.  Microsoft Press.  ISBN: 0-7356-1967-0

[6] Subramaniam, Venkat & Hunt, Andy (2006).  Practices of an Agile Developer: Working in the Real World. ISBN: 0-9745140-8-X

Paul Evans is a central technology programmer at Lionhead Studios.  He has worked on the Fable II, Fable III and other unreleased titles.  You can find him on Linkedin, see other things he has written on his personal blog, and follow him on twitter.  Everything in this article is Paul’s opinion alone and does not necessarily reflect his employers views. Copyright ©2011, Paul Evans.

But the cat came back the very next day…

Arcades with video games and pinball machines are quite rare now in the UK (now they are full of fruit machines) but are still a good starting point for looking in to players’ lives in games. Lives in Pinball are represented by identical silver balls – a limited resource per game. A player may start with three balls and might even win extra balls but eventually the game will end with a score. Score is used as a measure of success across all of your lives, with each finite reincarnation another chance at increasing the net accomplishment.

Space Invaders sees the player’s ship explode and be replaced with an identical clone a limited number of times. PacMan actually shrivels up in to nothing and makes a pitiful whining noise as his little spherical body implodes at the touch of Inky, Blinky, Pinky or Clyde… but another identical PacMan takes his place. These games are over thirty years old but the themes of credits, lives and scores still permeate throughout modern games in all sorts of disguises.

This kind of death and credit system is useful to monetize failure. Want to see more of the game? Well okay then… you have ten seconds to cough up the money and we will let you see some more. If you do not come up with the money then back to the start for you! Progression therefore will cost you, mastery of skills and patterns only earned after costly failure. Is it worth antagonizing a player with this kind of death in games that are not pay-per-play?

Mario and Sonic teach via death. I cannot believe that these games were designed so that a brand new player could get through the entire game without learning through a fatal kind of trail and error. Punishment for death can increase from the arcades where you can always bribe your way through a section, because in some games you pay in time instead. After dying a few times in a row the punishment goes from a pained animation to having to restart an entire area – taking away hard fought progress from the player. While some players thrive on this type of this type of challenge I would argue this action can be demotivating. Only a certain kind of player continues on to conquer this, others will just walk away in frustration.

‘Splosion Man has death but you just bounce right back in a glorious splodey sentient cloud of insanity. The game has levels and stages to clear and it is not possible to save your progress in the middle of a stage. The game does offer the player an option to skip to the next stage if you die in a section too many times in a row. So a frustrated player can skip forward to see new content and get some sense of progress. I never took up the option… too much gamer pride. But I did hear something about a pink tutu you have to wear in the next stage if you do!

Games with lives and credits often also keep score, either in terms of points or fastest times. They promote competition through leaderboards, with players trying to out do each other for bragging rights.

If it bleeds we can kill it (apart from if it is the player)

There is a snowy mountain path continuing to the NORTH. To the SOUTH a noisy group of villagers carrying flaming pitchforks are closing in on your location. They all seem kind of angry. Well apart from the springer spaniel that is wagging his tail furiously. He seems to think this is the best walk ever.

> NORTH

You tripped over something and fell off the cliff, a whooshing sound fills your ears followed by a very nasty crunching noise. Breathing heavily and looking up you see the villagers standing where you were laughing. One shouts down to your broken body “enjoy your trip?” Another takes your INFRARED SUNGLASSES that fell from your pocket before your tumble and puts them on. “OOOh INFRARED SUNGLASSES, I’ve always wanted a pair of these! I’m seeing red… oh look at that INVISIBLE TRIP WIRE across the path!” Rolling your eyes, you promptly expire.

THE END.

If only the player would have typed USE GLASSES. Ah well. It was all great playing that text adventure until you died, then you had to consider if you really wanted to play through all *that* again. It is like not being able to cheat in a “Choose Your Own Adventure” book. Part of the reason I like Monkey Island II so much was that you could not get in to that situation. Sure you could get stuck, but Guybrush could not die (but could certainly embellish the stories he told about it). The lack of death (but the presence of peril) made the game a very accessible adventure game.

In Fable III, you get knocked down, but you get up again. There is a price though; you get scarred up and you could lose some experience towards your next guild seal. This cosmetic toll is unbearable to some – I have known people to quit to the dashboard to avoid the auto save kicking in and saving their character in a knocked out state. Of course others play well but get knocked out on purpose… because scars are cool and perhaps they like the villagers making negative comments about their looks (just another reason to take the safety off).

The player in these games has one life that is constantly threatened but never ends. It gives a player license to experiment without fear of a sticky end. Games where the player cannot die often focus on telling a story rather than keeping score. They might also have to fight against the perception of being “easy”.

Ouch that really stings

There are a breed of games where death is both an inconvenience and a common occurrence. Gone are the limits on lives and credits. A player can retry many different things in different ways without fear of being sent back to an arbitrary check point a designer decided would be a good place to start again.

In Braid, everything fades and pauses… whoops better rewind time to before that death happened. No penalty really, unless the backwards noise really grates against you.

Crackdown and Bioshock have the concept of clones… so just like Pacman and the hero’s ship in Space Invaders there is always a new vessel for a player to jump in too. Though in Crackdown & Bioshock the effects of the previous clone are still present in the world. You literally are a player clone army and in Crackdown II there is actually an achievement rewarded for finding all the ways an agent can die. Death then can be its own reward.

Demon’s Souls adds a community aspect to death. Death can come completely out of the blue but blood stains can be used to communicate to other wary players what is in store for them – death is a form of shared learning experience.

Limbo sees the little boy avatar you control dying over and over again with very little game penalty. I take it back, the deaths are really quite disturbing and stomach churning though I’m sure there are those reading that just think it is funny! Heck it is probably a good way of acclimatizing to that kind of horror. Each death is over so quickly and so little ground is lost that it hardly costs any player time at all to die.

These games attempt to limit the frustration of death by placing the player close to the point of failure. They dust off the player and say “have another go, try something different”. Many of these games want you to complete them and know that some of the challenges they offer are tough.

No you really are dead

Something that computers and home consoles can do that I have not known in the arcades is the game save. A precious area of memory where a player can save their progress through the game and return to it at will. This allows the paradox of a player dying and a game ending, yet able to return to a certain point of time before that happened. Kind of like Ground Hog Day, where the entire world in unaware that all this has happened before (and all this will happen again). The player though has hopefully gleaned some knowledge to progress past that sticky point, so perhaps after x amount of times it will actually happen differently!

The downside of this is that the game does not know you played through a section either, so if there are any sections of non-interactive play then a player is doomed to sit through them again and again. As a player I really, really do hate times where I am forced to sit through sections of the game deemed so essential that I must watch them before interacting again. Perhaps there is a happy compromise, a separate save file held that indicates if a player has experienced that oh-so-important content once even if they revert to a previous save?

Grand Theft Auto IV and Red Dead Redemption do sometimes have fresh dialogue for retrying a totally failed mission from a checkpoint. GTA does exact a penalty for death (or at least lack of heath) – the player does not automatically revert to a save but instead ends up in a hospital with the contents of their previously bottomless pockets empty.

Red Dead Redemption did rely on teaching me that I cannot disarm people in story mission duels via killing me off and reverting me to a save / checkpoint. I really would have preferred disarmed opponents that had to die to have killed themselves rather than gimping the disarm mechanic and killing me in duels. Being quite a persistent gamer I believed them to just be formidable opponents, so I did try one particular duel over and over again for an hour before I caught on (sigh).

If a player veers away from where the story teller wants them to go, they are killed off and put back somewhere they can make a different choice. It does become frustrating if that choice is not clear, or if a player sees what they are supposed to do but lacks the skill to do it. Perhaps worse still, when the player remembers something from several hours ago that would change things now. Arguably save slots offer redemption for mistakes… at the cost of perhaps many hours of player time. Multiple save slots also potentially endanger the weight of player decisions.

Should a player be able to decide to “cheat” and turn the pages back, or should that temptation be removed? Do you trust a player to not replay one part of the story again and again to see all the different outcomes? Does it even matter if they do? I don’t think so if the player is having fun, but Mr. Resetti would disagree!

You wear yellow, they wear red

When a hero dies there is a save point or usually a special something that allows them to fight another day. The same cannot be said of other characters and things the player interacts with in a game world. You are Captain Kirk, the other characters are red shirts.

Games in the Civilization, Age of Empires and Command & Conquer series reward units that survive many battles with experience. They reward the player for leadership that keeps the minions alive. Cannon Fodder also had this but had an extra twist. Giving my squad names and knowing the penalty of seeing a new grave on the hill at the end of the level made me work just that little bit harder to keep my squad alive (see comments from other gamers on this vid).

Some game’s deaths actually are a vital part of the storyline and they expect the player to accept that. Characters in The Sims eventually die if you play with them. Sure you could just switch characters, keep reverting to a save or allow them to continually imbibe from the water cooler of youth but you are always able to let time take its course and eventually death will come to collect them. Then they are gone. Ok, well you might get a ghost hanging around but they are not remotely the same.

Mass Effect makes the player choose life or death for their own team members at points during the game. Mass Effect II rewards good leadership and truly knowing the players own team with extra story and different outcomes. There comes a point where deep knowledge of a the supporting cast strengths and weaknesses can save their lives.

Having a player care about their supporting cast is terrible when it feels unfair (why won’t this healing potion work on them this time… it worked the other thousand times?!) When done right though it gives a player extra emotional investment in not only the avatar they control but more of the world they are experiencing.

That’s all folks!

I would be very interested in hearing about how you think player death may evolve in the future, more examples of the above and your own personal experiences in the comments. Many argue games are getting easier – some would say they are becoming more accessible. A few designers have designed away player death completely in their games.

Death serves a few purposes, but chiefly to either completely end a score attempt or to impede progress through a larger game world. Geometry Wars understands that smashing down a button lots of times should just let the player try again (a touch many gamers I am sure appreciate). Other games use checkpoints and saves to snatch failed player actions out of the air as if they never happened; or return a carbon copy of that character back to the world sometimes none the wiser of the predecessors fate.

While writing this blog I asked an open question on Twitter about player and character death. The many replies even then just go to show what a wide subject this is in both narrative and gameplay. Grim Fandango, Planescape: Torment and Die2Nite have been suggested to me as games that explore death itself, though that is a topic for a different article. As a programmer and gamer I believe the way death is handled in a game very much defines how the game feels and plays overall. I do hope this article sparks off a few interesting conversations. You may leave comments here or try joining a conversation on Twitter – I suggest the hash tag #PlayerDeath @paulecoyote.

Thanks

Tweeters that helped me out in no particular order: @DaveFeltham @zackfreedman @lingmops @glamgeekgirl @oOSTVOo @twonjosh @paulnew @acroyear3 @BusterMcFearson @Stomp224 @JurieOnGames @ChrisA9 @ColleenDelzer @Renmauzuo @NaviFairyGG @FatalWebMunki @bjoernknafla @daredevildave

Also many thanks to my lovely wife proof reading this for me several times before I published it.

Paul Evans is a central technology programmer at Lionhead Studios. He has worked on the Fable II, Fable III and other unreleased titles. You can find him on Linkedin, see other things he has written on his personal blog, and follow him on twitter. Everything in this article is Paul’s opinion alone and does not necessarily reflect his employer’s views, nor constitute a legal relationship. Copyright ©2011, Paul Evans.