So I got this Blog thing...

Target: Dream Build Play 2012

2012-01-10T22:24:00.004Z

First post of 2012!

The news that there will be a Windows Phone category in the Dream Build Play competition this year has given me a solid target for Dreamland's completion. While no actual submission dates have been announced yet, I'm fairly confident in my assumption that we'll be looking at a June date for final entries.

Six months is plenty enough time to finish Dreamland and give it all the polish it deserves. Leon, Team Mango's resident graphics artist has been hard at work producing the last of the assets and storyline required to complete work and I'm following up with getting the last of the game mechanics coded.

To give me some extra motivation - and taking a cue from some of the Ludum Dare participants - I've started live streaming of my development sessions. Using a rather neat app called XSplit, I can screencast and show the game running on my Lumia 800 via webcam all on the same stream. I can stream to the Team Mango UStream channel and record to disk at the same time. The recordings allow me to make neat timelapse videos like this one:

My plan is to record and stream most of my Dreamland development sessions between now and DBP and make a huge timelapse video at the end of it all.

I'll be livestreaming at weekends and on weekday evenings (GMT), though not to any fixed schedule. I'll always announce on Twitter before I begin. It's development, so I can't promise too much excitement but I will sometimes have the microphone on and commentate my work.

Here's to a productive new year!

Omnia 7 vs Lumia 800

2011-11-19T15:15:00.001Z

It's just over one year on from my day-one adoption of Windows Phone on the Samsung Omnia 7. After much deliberation, I decided to grab a Nokia Lumia 800 to see what all the fuss is about, and get a taste of what so many newcomers to the OS are going to experience.

Nokia has done a fantastic job of advertising the Lumia, and the campaign is a great shot in the arm to Windows Phone after a year of little to no pushing of the platform by Microsoft itself. In the UK, at least, everywhere I look I'm being bombarded with adverts for the flagship device. I don't need to be sold on the platform - I'm developing games for it. I'm sold, I'm locked in. But it's great to see how interest has grown over the last month or so. Having Windows in your phone is becoming cool again, and rightfully so.

But this post isn't for me to extol the virtues of Windows Phone, it's to compare the wonderful phone I've been using for the last year to the new star of the show. Hopefully it'll be of use to other Omnia 7 owners that are wondering if they should make the switch or not. So let's dig in.

Hardware

To me, the Omnia with its 4" screen never felt like a huge phone. But the first thing that struck me about the Lumia is how small it seems next to it. And yet the Lumia feels weightier, and definitely looks a lot better. That's fairly subjective, but the Lumia has the lovely curved gorilla-glass screen and the equally curvy rear. The Omnia looks fairly plain and businesslike in comparison.

A few reviews had mentioned a slight rattle in the buttons, and although it's present it's not as much of a problem as I had imagined. You have to shake the phone fairly hard to hear it, and the buttons are not loose in any way when you run your finger over them. All in all, the chassis feels solid.

I have a slight concern with the USB socket cover. It's really flimsy, and kind of a pain to operate. You push down on one end of it to open it, and the hinge and cover feel pathetically weak and plasticy. Any amount of force while the cover is open and it will definitely break off. However, once it's closed there's no looseness to speak of. Something to consider if you're constantly recharging, syncing or deploying over USB.

The Lumia has all-capacitive operating system buttons. I do miss the hardware Windows key of the Omnia. I had got used to using the Windows key to wake up the Omnia, and now that's not an option with the Lumia.

Many Lumia reviews have mentioned how close the capacitive buttons are to the screen. This was an issue for me with the Omnia when I was gaming on the phone. I find it less so now, probably because I'm used to avoiding accidental swipes, but that search button still catches me out sometimes. I haven't used the Lumia enough yet to tell if the closer proximity of buttons to screen is going to be an issue, but I will be sure to update if I find it is.

On the audio side I find the Lumia's loudspeaker a little quieter than the Omnia's, but it doesn't distort as much at high volume. It also seems that the lowest volume setting is quieter than the Omnia's, which is great. There's also more control over the volume at low settings. However, the included headphones are dreadful. The Omnia's have a volume rocker, answer button and mic in the remote control unit. The Lumia's is without a volume rocker. The audio quality of the Omnia's pack-in headphones wasn't great, but the Lumia's are somehow worse.

I'm no expert in photography, so all I'll say about the cameras is that I found the Lumia generally produces better quality pictures, with a higher colour saturation. The Lumia's lens has a much wider angle on it, which is very nice.

Omnia 7 Camera Image

Lumia 800 Camera Image

The Screen

The 3.7" Lumia screen is smaller than the 4" Omnia. And I was surprised how much smaller. When you line the phones up side-by-side and look at the home screen, you can really appreciate how nice the Omnia's screen is. Surprisingly, I haven't yet found the smaller screen is hindering my typing in either portrait or landscape orientations. And I have sausage-fingers.

Quality-wise, the screens look about the same. I noticed that the Lumia has a slightly higher colour saturation, and that it had a slightly redder hue to the Omnia's when the phones were both displaying at medium brightness. At high brightness, the colour levels look about the same.

I mention the brightness because the Omnia's light sensor seems to switch to a higher brightness at much lower ambient light levels than the Lumia. I had to shine my desk lamp directly at the Lumia's screen to get it to automatically switch to high brightness. You can always turn off the auto brightness (at the expense of battery life) if you prefer a brighter screen. To be honest, I hadn't noticed that the Omnia's probably been running at high brightness most of the time, and the Lumia screen on medium is very dim in comparison.

Speed

A video is all that's required to illustrate how much faster the Lumia is. Here, I run a side-by side comparison of the opening sequence of Survivalcraft, the first Windows Phone Minecraft clone. I've set the resolution to Full on both phones. This blew me away, watch for yourself:

This slickness filters down to the rest of the system. App load times, browsing and task switching are all smoother and faster on the Lumia. This for me is probably the biggest selling point.

I also noticed that my signal strength has gone from showing the "3G" icon on the Omnia to showing "H" (HSDPA) on the Lumia. This is on Three UK. I'm not entirely sure why this is, as I'm not a phone junkie. The browsing speed OTA is marginally faster, so I'm guessing the Lumia is capable of faster HSDPA than the Omnia. I swapped the SIM back to the Omnia to make sure (I had to use an adaptor as the Lumia is micro-SIM), and couldn't get the Omnia to show the "H" icon. So that was an unexpected bonus.

Included Apps

After a year of using the Omnia, I'm now a Zune user as far as music is concerned. I have a Zune Pass, all my purchased albums come from the Zune marketplace. Therefore, the Nokia Music app is redundant. I had a quick flick through it and it seems that all your sideloaded tracks are present and correct should you decide to use it, but it wasn't for me so I uninstalled it.

Nokia Maps didn't fare much better. Once updated, I had a quick play. It mimics the Local Scout behaviour and pinpoints local points of interest, but it doesn't seem to offer anything above and beyond the standard WP7 maps app. The interface is also a little clunky. Bye-bye!

Nokia Drive is the real winner here. When I moved away from Symbian to come to Windows Phone, losing Ovi Maps was a big deal. While functions seem a little limited at the moment (no favourite addresses for instance, just an address history), Drive does what it says on the tin. It's real voice-guided turn-by-turn 3D satnav with downloadable offline maps. And it's really slick. Considering the next best option on Windows Phone - Navigon - costs $99, this is a really great addition.

One other thing to note is that the Lumia did not ship with the internet sharing capability enabled. The Omnia was recently updated to make this new Mango feature available, but Nokia had to ship without it. I believe it'll be coming in a future Lumia update.

A Handy Table to Help You Decide

Omnia 7	Lumia 800
Larger Screen	Nicer Chassis
Better OS Buttons	More Storage
Louder Loudspeaker	Better Quality Loudspeaker
Internet Sharing (with latest update)	Faster Processor/Graphics
	Slightly Better Camera
	Faster Data Speed (HSDPA)(?)
	Nokia Drive

I hope that helped out at least one person with an Omnia 7 wondering about upgrading.

Update: 4 Weeks Later
After four weeks with the Lumia, I can happily say that I made the right choice in upgrading. I have not missed the larger screen of the Omnia. I'm not experiencing the reported battery life issues (the Lumia lasts as long as the Omnia for me given the same daily usage and overnight recharge). I don't seem to accidentally brush the search button as much, which is a surprise. Maybe I'm just used to avoiding it now.

I still wish the loudspeaker was louder, I can't hear it too well in the shower or whilst cooking like I could with the Omnia. The update that will include the Wifi access point option has been pushed back to next year, but I've already had one update from Nokia so I'm confident that any further issue will be ironed out.

As a footnote, I'd like to plug my two current Windows Phone games - Asteroid Armageddon and Bunny Massacres Episode 1. Both games run wonderfully on both the Omnia and the Lumia! Also, keep an eye-out for my forthcoming Windows Phone action/RPG Dreamland.

New Team Mango Website

2011-07-29T21:51:00.005+01:00

It's been a long time coming, but I finally updated the Team Mango site to bring it up-to-date with information on all of our releases. The home page contains relevant content from my personal blog, so I don't have to update in two places.

I've been a little lax in blog updates, but suffice to say that Dreamland was indeed submitted to this year's Dream Build Play just in time! With that done and the website update out of the way, there's three currently ongoing projects in the Team Mango camp:

Dreamland
Dysnomia for Windows (hoping to have that out this year)
A silly little Windows Phone game. Or collection of minigames, really.

I'll leave you with the latest Dreamland trailer (Dream Build Play edition):

Crunching for Dream Build Play: 3 days to go

2011-06-12T11:25:00.001+01:00

More great progress as I begin what will hopefully be the last day of work on the Dreamland codebase for Dream Build Play. So what's been added to the game since Friday's update?

Merlin intro - he greets the player at the start of the game and gives a few hints and tips

New Figement (spell) screen. Gives info on new figments, powers and major quest items.

More NPC conversations. Added placeholder text for some characters that don't have quests in the DBP preview build

5 completable quests for DBP.

Today is all about sounds and music. I'll be adding as many placeholder sound effects as I can in the time remaining, and choosing a couple of music tracks that will appear in the final game. That leaves tomorrow evening for final polish and recording a DBP trailer video. Then Tuesday evening for final submission.

Crunching for Dream Build Play: 4 days to go

2011-06-10T19:40:00.000+01:00

Progress! Had a few very productive evenings of work on the Dream Build Play build of Dreamland. First of all, three things that were crossed off of my to-do list:

Directional spell casting. A half-second delay with a direction indicator makes hitting the desired target much easier.

Town portal. Teleports between dungeons and the town square.

Quest progress text. Displays when a quest phase is completed, with a hint for the next phase.

Levelling text. Merlin has a new "Figment" (spell) every few levels. Also, new quests may be unlocked.

And something that wasn't on my to-do, but needed doing anyway:

Game Over! Will have more options in the finished game, but this will do for now.
Text is made up of animated particles (a similar effect is used on the title screen).

Very pleased with how things are going, but things take a less fun turn tonight as I start work on a short tutorial, which involves having the Merlin character walk onto the screen and strike up a conversation.

Will update again tomorrow!

Crunching for Dream Build Play: 7 days to go

2011-06-07T19:57:00.000+01:00

I wasn't going to enter Dream Build Play this year. When the registration period began in March, I was maybe 15% done on my current work-in-progress, Dreamland. And most of that progress had been made on the Windows Phone version of the game. Team Mango artist Leon didn't have to do a great deal to persuade me that we should get the game ready to enter regardless.

I've entered DBP for the last two years. Gravsheep in 2009 and Dysnomia last year. Dysnomia finished in the final 20. While I'm not expecting Dreamland to be a finalist, it would be a shame to sit it out this time around. So here I am, with seven days to go. As the game stands, it's fully up and running on the 360 with the majority of the game mechanics in place. Content-wise, I'm looking to have the first 20% of the game in there, including the first dungeon and first boss and a number of completable quests. I'm aiming to be code-complete by Sunday night so that I can spend Monday recording a video and have Tuesday evening ironing out any last issues.

Dreamland has been in development since October last year, and while there's not been an official release announcement about the game, I can tell you a few things about it. It's an RPG. A pretty light RPG with real-time combat. It's cartoony, but the visuals betray the adult nature of the game. There's plenty of dry humour in the dialogue, a fair amount of blood (though nothing that sticks) and some adult themes. I'm aiming to get the game out in September on Windows Phone and Xbox Live Indie Games, and complete a Windows version by the holidays.

As of tonight, and after a month of real crunching on the codebase, my to-do list for the Dream Build Play release stands as follows:

Spell Direction indicator

Spellcasting in Dreamland is directional. On the phone, a flick gesture is used to cast spells in the direction of the flick, and is pretty accurate. On the 360, the right stick is used to cast spells. Because It's kind of hard to precisely gauge the direction with a flick of the thumbstick, I'm adding an on-screen direction indicator, with a slight delay so that you can line up the spell before casting it.

Quest updates/levelling text

I need some nice text for when the player gains a level or moves a quest along. Just to provide a bit of extra feedback.

Intro/mini-tutorial

There's nothing there at the moment. You're dumped right into the game after the title screen. Plan is to have an introduction by one of the games characters, along with a short tutorial explaining melee and magical combat.

Portal

In the full game, the character will have a Diablo-style portal item allowing them to easily move between their current location and the town square. For the DBP demo, I'll just be placing a fixed portal at the end of the first dungeon.

More Quests

Currently there's two completable quests, I'm hoping to get that up to five. That includes all the NPC conversations that go with the quests.

Sounds and Music

Currently none. Nada. Nil. Argh. Why do I do this to myself. I have my eye on some stock music already, but sound effects are another story entirely. Maybe I'll just use BFXR for some extremely placeholder sounds.

And that's it. Seven items on the list. Seven days to go. Realistically (and given no other distractions), I have around 30 hours free time between now and Sunday.

I shall update again on Friday evening.

Asteroid Armageddon Updated

2011-04-23T22:18:00.000+01:00

Asteroid Armageddon for Windows Phone 7 has been updated to version 1.4. The update should be available through the usual Marketplace update service right now. We've added a few new features:

Weekly High Scores (reset every Sunday at 2100 GMT)
End-of-wave score bonuses
One new level of laser
Two new backgrounds (randomly chosen each new game)
...and a number of small bugfixes.

Gaming for Japan

2011-03-18T08:38:00.023Z

Now that Asteroid Armageddon has been released for free in all Windows Phone 7 marketplace regions, we're going to use our first mobile game to do some good.

From April 2nd to April 22nd, Team Mango will donate all advertising revenue from Asteroid Armageddon to the American Red Cross, who are helping the people of Japan recover from the earthquake and tsunami. We chose Red Cross as they are one of a few charities who have a direct fund for Japan.

The more you play, the more we can donate. So go grab Asteroid Armageddon either via Zune or by searching the marketplace for "Asteroid Armageddon Free".

Total Raised: $109.08

Thanks to everyone that played Asteroid Armageddon over the last few weeks!

Asteroid Armageddon released

2011-02-28T08:39:00.007Z

Just a quick one to say that Asteroid Armageddon is now available on a Windows Phone 7 near you! It's available worldwide as a trial/paid version for $1 (79p), and in the US as an ad-supported free version.

The free version will come to other markets as soon as Microsoft expand the pubCenter program into other territories. Here's a couple of one-line reviews by Marketplace users:

"Awesome game, graphics, and difficulty." - Josh51191

"Very cool and beautifully polished game. I'm going to buy it!" - Megatron63

"WP7 Games are being developed with much more skill, this being a great example." - victorj589

"Actually very good! With leaderboards and challenging gameplay." - GrungiestGorgon

Right now, the ads aren't showing up on the Free version, so if you're in the US you're getting a completely free game with no nagging! We're working on fixing that in the first update, which will also add a main menu option to view the local and top ten online scores.

And some Zune deep links for each version of the game:

Worldwide paid version: http://social.zune.net/redirect?type=phoneApp&id=399c5bc9-673c-e011-854c-00237de2db9e
Free version (US only): http://social.zune.net/redirect?type=phoneApp&id=f4eb750d-6d3c-e011-854c-00237de2db9e

Run! released, and Asteroid Armageddon on its way

2011-02-07T12:42:00.009Z

I never thought I'd say this, but Run! has finally been released to Xbox Live Indie Games. Now it's out, I can tell the story of this Team Mango release, and how it almost never happened. It's not that interesting, but here it is all the same...

Development of Run! began in February 2010, whilst I was getting Dysnomia ready for release on XBLIG. I used it as a creative output whilst I wrapped up all the necessary but boring bits that make up the last 10% of getting a game to market, especially one with the scope of Dysnomia.

The original idea for Run! was to create a simple Skyroads clone. I'd already written a clone using OpenGL way back in 2001, called Rollminator. I had a basic engine for Run! working in just a couple of days, but the idea of using Avatars wasn't there right from the start. I guess that came out of the frustration that a lot of XBLIG creators were feeling back then, that fully-fledged games were being ignored in favour of "shovelware" that used Avatars as a gimmick. I was also glad that I had the idea when I saw Dr. Mistry's rather excellent Blazin' Balls, which is pretty much precisely the direction that Run! was headed in that first week or so.

So, I was using Run! as my one-dollar-avatar-game experiment. Being part of the problem, I guess. Except I completely missed the boat, as usual. Though the game was 90% complete around the time that Dysnomia became a finalist in Dream Build Play, I was simply too busy to wrap it up. Last summer, there was the whole house-buying thing which dragged on, then there was distraction in the form of Windows Phone 7 and the work I was doing there. Run! became the "difficult third" game that was swept firmly under the rug.

Then just before the holidays, Microsoft announced they were turning off XNA 3.1 publishing as of, well today actually. This means that Run! was on a deadline. Now, I'm a bit of a completionist, and it was starting to really bug me that Run! was still unfinished and sitting there taunting me in my projects folder. I decided to push to get it out before the deadline, saving me the pain of upgrading to XNA 4.0.

I used the Christmas break to finish the majority of the work, and got the game into Peer Review mid-January. I completely skipped Playtest, which I hated doing but there was just no time, and I thought that upgrading to 4.0 would be far too painful.

Run! made it through peer review on the second try (after a rare but game-breaking bug was found and fixed) and was released to the world. I was ready to put this one behind me and work on other things. Fate, it seems, had other ideas.

A couple of days after release, Leon (resident Team mango artist) pointed out that I had used the wrong boxart for the game. When we were putting together concepts for the boxart, we were using an avatar taken from MatthewM's Avatar Dash boxart, as it was exactly the kind of pose we needed for ours. I later wrote a quick app to animate random avatars so that Leon could pick his own for the final Run! boxart (above). But somewhere in those six months of downtime, I completely forgot to update the boxart and title screen images in the game project. Uh oh.

It was a genuine mistake. I didn't set out to plagiarise Matthew's boxart, I would never dream of doing so. I had to get it fixed. And so I updated the entire project to XNA 4.0 so that I could resubmit a new version with the correct boxart. As of writing, I'm still waiting for the 7-day submission "purgatory" to end. MatthewM - if you read this - I apologise profusely for the screw up, and a fix is on its way. Drop a comment so I can get in touch.

And so ends the sorry saga of the third Team mango game. Lessons have been learnt.

What's all this about then? Why, it's Team Mango's first Windows Phone 7 game, of course! Here's a trailer!

Asteroid Armageddon was suggested, designed, and bought to life by Leon after looking about on the WP7 marketplace for action/shooting games. It's a simple but addictive game that uses the tilt sensor to rotate the player's viewpoint, the the touchscreen to fire lasers at oncoming asteroids. Between each wave of asteroids, the player can upgrade his turret with more shields, more weapon coolant and so on. I wrote an online high scores service especially for this game, but that can also be used for future Team Mango WP7 and Windows games.

I'm really happy with this bitesized game, perfect for those 5-minute breaks in your day when you might break open a game on the phone. It took just under two weeks to put together all the code and assets for it. It's something I'd like to do more of, maybe a game of this size and simplicity for the phone every couple of months. We're still working on the next "big" Team Mango game, our as-yet-unnamed RPG, and it was nice to have a quick break from that to work on something else. Looking forward to getting back on the RPG this week though, I have to say.

I think that's enough rambling for this week. Next week, I'll go into detail about that high score service I created for Asteroid Armageddon.

Team Mango Dev Diary

2011-01-10T19:52:00.007Z

It's been ten months since the release of Dysnomia, and I had hoped to have at least one more game out on the Xbox Live Indie Games service by now. 2010 proved to be a busy year outside of games development (which is only a hobby for me, after all) and time has been short. Now I'm back to a regular schedule, I have a list of projects that I intend to finish this year:

Run! to be released on XBLIG shortly
Game 4 (still untitled!) on Phone 7, and XBLIG shortly after
Game 4 on Windows
Dysnomia on Windows
and lastly, Dysnomia on Phone 7 (still tentative)

So that's six releases of three games on three platforms. The only real tall order is getting Dysnomia working well on the phone. There's currently some framerate hitches that I'm assuming are garbage collections, so more optimization to do on that front.

I'm wrapping up Run! this week, there's less than a month to go before XNA 3.1 games are no longer valid for submission on XBLIG, and I'd rather not spend the time to port to XNA 4. The game's been the best part of ready for several months, with just a couple of levels to finish and some pre-submission tests to run through. I'll be glad to get this one out the door!

Things are progressing well on Game 4, the first RPG game I've attempted. Basic melee combat is in and generally feels nice to play. As Game 4 is being developed simultaneously for all three XNA hardware platforms, I'm taking the time to ensure a solid user experience no matter what the control method. For instance - while nothing is set in stone as yet - the movement and basic attack controls are mapped as follows:

Movement - Xbox: Left stick Phone 7: Single-tap Windows: Left click

Attack - Xbox: A button Phone 7: Double-tap Windows: Right click or double click

For what will be the equivalent of "magic" attacks, the Xbox version will make use of the other three main buttons, which will be player-assignable in a method similar to Deathspank. On the phone and Windows, the UI will make use of tapable/clickable icons for quick access to three user-definable "spells". The Xbox version will use auto-targeting for ranged attacks, whilst on the phone and windows the player will be able to click an enemy to fling a "spell".

We're still developing the storyline and game mechanics, so I can't yet explain the reason for the quotes when talking baout "magic". Suffice to say, the game doesn't make use of regular fantasy-RPG magic. Whilst some attacks will be familiar, others will be completely ridiculous. Hopefully in a funny way!

I've started work on a WPF application to help with editing the conversations that occur between the main character and the NPCs in-game. I love the rapid development environment offered by VS 2010/C#/.NET. Just being able to slap a new application into your game solution, quickly knock out an interface, write some codebehind and bam! a functional tool that will save so much time compared to writing out the XML content by hand.

At the moment, it simply serializes a list of conversation steps to an XNA content XML file that is read in and deserialized in the game. It will become more complex as the quest system gets added, with specially marked steps to control the flow of conversation according to the completion status of associated quests.

And, just to wrap up, a quick video of the first iteration of the conversation screen:

WP7 Games and the Dreaded Search Button

2011-01-03T16:47:00.012Z

Happy twenty-elephants! I hate to start the new year with a rant, but I figure why not get it out of the way now, so I can concentrate on some more constructive posts for the rest of the year. Besides, I've only really found how awfully annoying the subject of this rant is over the holidays, as I spent quite a bit of time gaming on my Samsung Omnia 7.

You see, the Omnia 7 has a capacitive search button. The WP7 search button is one of the three hardware face buttons required by Microsoft's hardware specifications for the Phone 7 OS. The Omnia 7 isn't the only phone with capacitive back and search buttons. It's the capacitive nature that means they can be accidentally swiped fairly easily, especially during more frantic gaming moments.

Unfortunately, the default behaviour of the search button is to open up Bing search, even if you're right in the middle of a game. In itself, this wouldn't be so bad if you could simply hit the back button to get back to where you were in game. But due to the application lifecycle on Phone 7, the game you were playing is quickly closed down in the background. The Phone 7 SDK provides ample tools for developers to deal with such situations, but unfortunately - as I wrote about in a previous post - not all developers take the time to make their games behave. As a user as well as a developer, this is extremely frustrating.

So I thought I'd take the time to name and shame some of the games that don't do enough to get the user back in the game as quickly as possible after accidentally hitting search, answering a call, or dropping out to the home screen. And, because I like to be positive as often as possible, I'll also highlight the games that do tombstone correctly.

All of the games I've tested here are full purchased versions of Xbox Live enabled games. This means they are published either by Microsoft or a third-party partner. I test by getting into the game, hitting search, waiting a few seconds, then hitting back.

Puzzle Quest 2
Quite frankly, this is the most disappointing game on the list. I love Puzzle Quest, I've got the game on XBLA as well. The game runs like a dog on Phone 7, with a framerate that looks to be barely in double-digits. The complete lack of tombstoning is the straw the breaks the camel's back. You could be almost at the end of a 5 minute battle and have to put the phone away - and you're completely screwed. Attempt to resume the game, and not only do you have to sit through the splash screens again, you've also got to navigate the menus. The game does save your position in the overworld, but you lose all progress on the battle you were fighting and that, my friends, is highly annoying.

Rocket Riot
A great game that almost gets the tombstoning right. The game resumes with a single loading screen, and gets you right back into the level you were playing. Unfortunately, you have to start the level again and that can be a little frustrating especially in the latter levels where you are required to kill 40+ enemies in a match that could last a few minutes. Close, but no cigar. Just save out the current score, Codeglue guys, and you'll have a winner.

The Harvest
One of the original line-up of games that got some tech sites noticing the tombstoning problems early. I really like The Harvest, but as I went to test it again for this post I'm having serious problems with it. It no longer wants to load or continue games, either from resuming after tombstoning, or from a fresh boot. I even turned the phone off and back on again to clear it out and still no dice. This means I can no longer load or continue my saved game. It never used to be like this, but even when it did all work there were major issues with coming back from tombstoning including multiple splash screens and excruciating load times. Seriously in need of a patch.

Fruit Ninja
Well done to Halfbrick for nailing it. I guess all the time spent developing XBLIGs and adhering to the Evil Checklist rubbed off, as they actually seem to care about the end user experience. Either that or they got fed up of accidentally swiping the search button in playtest! Fruit Ninja resumes perfectly, getting the user quickly back into the game with all the fruit on-screen where they were left. The game's even paused for good measure. If I had to nitpick, I'd say the MGS splash screen is unnecessary - but I have a feeling it's required by Microsoft. If that's the case then they should have an "except in the case of resuming from tombstoning" clause.

Flight Control
Another one that gets it right, save for a couple of unnecessary splash screens. Seriously, if you're coming back from tombstoning, you don't need to let the user know who you are again. Chances are I've already seen your company logo once today. That aside, Flight Control gets you right back into the game with all the planes onscreen where they were left, and your score intact. As with Fruit Ninja, the game comes back to the pause screen, which is perfect.

So there you have it. Two out of five of the games I've purchased behave satisfactorily after I accidentally mash the search button. In time, I expect all the Xbox Live enabled games will pay attention to this vital part of the user experience. Until then, please patch PQ2!

I promise that's the last I will post about tombstoning for oooooh, at least a month. Next monday will be a Team Mango games status update, with a couple of videos of Game 4. Maybe we'll even have a title for it by then!

Normality, Of Sorts

2010-12-06T21:33:00.002Z

It's been one month since Jenna and I moved into our new home. We're still in the process of sorting everything out, and we're still having to move boxes of junk in from our parents' houses and find room for everything. Luckily we have a huge loft for most of the boxes of knick-knacks. We've somehow found the time to put up the christmas tree and a few lights already! It's all feeling much more homely now, and having done the major work, I've been able to sort out a schedule for Team Mango game development work.

It's a rough schedule that allocates days to certain tasks, but doesn't constrain me to allotted hours, because I never know how many hours I'll get to spend in any given day. Still, my schedule goes something like this:

Monday - Blog post day
Tuesday to Friday - Work on Game 4 for Phone 7
Saturday - Bring Windows and Xbox versions of Game 4 up to date
Sunday - Work on Dysnomia for Phone 7

Bear in mind that I usually have only one or two hours each day to spend on the assigned task. I kind of like it like that, as it allows me to really focus on bitesized chunks of work.

I tend to treat Saturday as my "anything goes" day, as it's the one day I have plenty of time to spend on development. The only task I set myself as must complete for Saturday is to get the Windows and Xbox versions of Game 4 up to the same level as Phone 7.

Throughout the week I develop on the phone as it's the lead platform for Game 4, but I'm giving the Windows and Xbox versions the same amount of respect by making sure I carefully tune the UI and controls for each platform. Sometimes this may only take 20 minutes on a Saturday morning, adding in any new content files and tweaking the controls. Sometimes it takes longer, especially if there's new UI items to do - especially on the 360, where I need to display button prompts rather than having clickable/tappable buttons on-screen. There's a lot more to developing on all three platforms than simply creating copies of a project in a solution and hitting compile!

So that's my work schedule - but how do I remain focused? Like many creatively-minded people the world over, I tend to have moments of procrastination. It's easy for the mind to wander to other things. Here's my top five tips for staying on a project, especially if it's just a hobby:

Work with someone else. There's absolutely no substitute for teamwork. If you're working with a partner on a project, you're always pushing forward because you don't want to let the other party down. I have Leon constantly churning out art assets for our games, and that pushes me to get things done.
Work in bite-sized chunks. If you know you've only got an hour to spend on something, plan ahead and assign yourself a task you know you can get done in that hour. Conversely, if you have a full day - don't spend all of it working. Work on a large task that might take five or six hours, but have plenty of breaks. And when you're done on a task, it's okay to call it a day. If you feel you've accomplished something, then it's probably a good time to stop.
Music. This is a personal thing, but I find that music helps me concentrate a lot more, especially if I'm listening to familiar tunes. I often find I have the same few albums in rotation for several weeks before I try something new. For the record, I listen to a lot of melodic death - but whatever floats your boat!
Get a whiteboard! I love my whiteboard. I use it to keep track of tasks, doodle UI sketches and work out geometry math. If you don't have room for a whiteboard, you may find a pen and a pad of paper a suitable alternative.
Do the hard and/or boring stuff first. Specifically in games development, there's the cool stuff like gameplay, animation and visual effects. Then there's the monotonous stuff like menu screens, file handling, Xbox profile support, tutorials and so on. Reward yourself for completing something boring by working on something cool. Otherwise, you'll finish your main game after several months, and still have a month's worth of essential polishing to go, when all you want to do is get the game out the door.

Tombstoning in Phone 7 XNA games

2010-11-29T19:04:00.015Z

One of my pet peeves about the new Windows phone 7 platform is incorrect or insubstantial use of "tombstoning" of applications, especially when it comes to games. Tombstoning is the terminology Microsoft use to describe the hibernation of apps when they lose focus (ie. for an incoming call, or the start button being pressed).

In a way, some of the worst culprits are the official Xbox Live games on the Phone 7 marketplace. Very few of them will resume the game at the exact place they lost focus. Take one of my favourite titles, Rocket Riot, for example. It's one that almost gets it right, but falls at the last hurdle.

Each of Rocket Riot's levels requires that the player kill X number of enemies, 50+ in the late game. If the game loses and then regains focus (ie. it is tombstoned), it remembers which level was being played, but not the number of enemies that had already been killed, or the progress of a boss fight on boss levels. The player is effectively forced to restart from the beginning of the level, and is in a way punished for taking a phone call or accidentally brushing against the start or search hardware buttons.

Some of the Xbox Live games don't even behave that well. Having to sit through splash screens and 30 second long loading screens just to get back to a game that simply lost focus is just not good enough. And as responsible XNA developers, we can make sure our games behave, and it needn't be a complete hassle to achieve seamless tombstoning.

The XNA team give us a great starting point in the Phone 7 Gamestate Management sample. There's even more help available in the article on Tombstoning in WP7 Games.

I use a modified version of the Gamestate Management sample as a starting point for all my XNA projects, whichever platform I'm working on at the time. I found the Phone 7 version of the sample to be very useful, although in its current incarnation, it doesn't quite push the tombstoning quite far enough.

I changed the sample to recognise the right startup event for restoring state upon re-activation. There's a handy table in the Tombstoning in WP7 Games article. The Gamestate sample does not check the PhoneApplicationService.Current.StartupMode property, and instead attempts to restore from a tombstoned state every time the game is run. To avoid this, we simply need to add a check in Game.cs as follows:

Replace:

// attempt to deserialize the screen manager from disk. if that

// fails, we add our default screens.

if (!screenManager.DeserializeState())

{

// Activate the first screens.

screenManager.AddScreen(new BackgroundScreen(), null);

screenManager.AddScreen(new MainMenuScreen(), null);

}

With:

// attempt to deserialize the screen manager from disk. if that

// fails, we add our default screens.

bool deserialized = true;

if (PhoneApplicationService.Current.StartupMode == StartupMode.Activate)

{

if (!screenManager.DeserializeState())

{

deserialized = false;

}

else

{

deserialized = false;

}

if (!deserialized)

{

screenManager.AddScreen(new BackgroundScreen(), null);

screenManager.AddScreen(new MainMenuScreen(), null);

}

You'll need to add a reference to Microsoft.Phone, and also System.Windows (the latter is required for the IApplicationService interface). You'll then need to add the corresponding using statement in Game.cs:

using Microsoft.Phone.Shell;

Great! now the Gamestate sample will only attempt to restore from a tombstoned state upon re-activation, not starting afresh. Now onto the tricky stuff.

The Gamestate sample rather cleverly serializes the state of all the opened GameScreens when the game is Deactivated. This means we don't have to do anything extra to get back to the screen (most likely GameplayScreen) that was in use at the time of deactivation. If the Xbox Live games mentioned earlier are anything to go by, you've done enough at this point! Go straight to marketplace, do not collect £200.

But in order to cater for the more discerning phone user, we need to do more work. We need all of our game objects to be saved as they are. We want our main character to come back exactly where we left him. We want to be on the right level, and with the same enemies in the same places. Now all of this is going to depend on your game and how you intend to handle game saves, but I will give an example of just one way to do it, using XmlSerializer.

The GameScreen base class has two overridable methods, Serialize() and Deserialize(), which are called when the screen is removed or added during application Deactivation and Activation respectively. So, in our GameplayScreen, we need to add both these methods:

public override void Serialize()

{

base.Serialize();

}

public override void Deserialize()

{

base.Deserialize();

}

Now, let's assume that you have a game hero class, Hero. Your GameplayScreen might instantiate the Hero class:

Hero gameHero;

public GameplayScreen()

{

gameHero = new Hero();

}

And during the game, the hero's fields might be updated, such as gameHero.Position, gameHero.Level and so on. We need to save the state of the Hero class when the game is deactivated, and we're going to use XML serialization to do it, because it requires very little work to get up and running.

Let's extend our earlier GameplayScreen.Serialize method to store down our Hero when GameplayScreen is serialized (the game is being tombstoned):

public override void Serialize()

{

using (IsolatedStorageFile storage = IsolatedStorageFile.GetUserStoreForApplication())

{

if (!storage.DirectoryExists("TombstoneData"))

{

storage.CreateDirectory("TombstoneData");

}

using (IsolatedStorageFileStream stream = storage.CreateFile("TombstoneData\\hero.dat"))

{

XmlSerializer xmls = new XmlSerializer(typeof(Hero));

xmls.Serialize(stream, gameHero);

}

base.Serialize();

}

It's as simple as that! We open up the application's IsolatedStorageFile, create a directory in it, and serialize the gameHero instance of the Hero class to XML, which we then write out to the hero.dat file stream. And because all .NET 4 classes are automatically marked as Serializable, we don't need to do any extra work to save out most of the fields on the class.

We can now do the opposite to load our hero back in when the game is activated, and the screens are Deserialized:

public override void Deserialize()

{

using (IsolatedStorageFile storage = IsolatedStorageFile.GetUserStoreForApplication())

{

try

{

using (IsolatedStorageFileStream stream = storage.OpenFile("TombstoneData\\hero.dat", FileMode.Open, FileAccess.Read))

{

XmlSerializer xmls = new XmlSerializer(typeof(Hero));

gameHero = (Hero)xmls.Deserialize(stream);

}

catch (Exception ex)

{

if (storage.DirectoryExists("TombstoneData"))

{

string[] files = storage.GetFileNames("TombstoneData\\*");

foreach (string file in files)

{

storage.DeleteFile(Path.Combine(loadFolder, file));

}

base.Deserialize();

}

We add the extra try/catch to handle any errors that may occur whilst loading our data back in. If it fails, we simply delete any remaining files to clean up the TombstoneData folder for next time.

Now, it's important to know in which order the GameplayScreens initialization methods get called when returning from tombstone. The ones we're concerned about (in order of execution) are:

The constructor GameplayScreen()
Deserialize()
LoadContent()

So we should instantiate our game classes in the screen's constructor, load their saved state in Deseralize(), then load any graphical content in LoadContent(). You'll probably have a Hero.LoadContent() method, which you'd call from GameplayScreen.LoadContent().

Of course, there's a lot more to tombstoning than simply serializing your main classes, but hopefully it'll give you a starting point to help improve your game's behaviour. There are issues with the performance of the XmlSerializer and you may choose to look to Binary serialization for instance.

I'm only just scratching the surface whilst developing the as-yet-unannounced Team Mango RPG for the phone, so I'll likely blog more about my final tombstoning solution as it's quite a black art that unfortunately even the big studios are failing to get right.

Shrinking Dysnomia

2010-11-22T19:12:00.010Z

In my last post, I teased Dysnomia running on Windows Phone 7. It's an interesting challenge, shrinking the game down to run on the phone. I did a lot of optimization on the 360 version, mostly around garbage collection and memory management while the gameplay was running.

What I did not optimize at all was RAM usage. I chose to load all game assets up-front, even before the title screen appeared. For the 360, the amount of overall RAM used was trivial, and the load times were fast. I loaded all animation spritesheets, all sounds, all music and all popup screen content before the first level was started.

The only items I chose to load per-level were the tilesheets, as they were by far the largest textures used in the game, and I needed to be able to free up the RAM they used between levels.

On the phone however, the RAM usage story is completely different. Microsoft recommends that an application shall not exceed 90mb of total RAM usage, that is to say peak usage. It's a simple matter to check how much memory your app is using:

var curuse = (long)DeviceExtendedProperties.GetValue("ApplicationCurrentMemoryUsage");

var memuse = (long)DeviceExtendedProperties.GetValue("ApplicationPeakMemoryUsage");

var maxmem = (long)DeviceExtendedProperties.GetValue("DeviceTotalMemory");

curuse /= 1024 * 1024;

memuse /= 1024 * 1024;

maxmem /= 1024 * 1024;

Will return current memory usage, peak memory usage, and total RAM available (in MB) respectively.

So when I hooked up a debug method to output the RAM usage to the screen, I discovered that Dysnomia was using 190MB at peak (with the map screen open), and 170MB during normal gameplay. That's twice the usage limit for passing app certification!

I began by simply cutting down on front-loaded assets. Later on, I'll implement per-level loading of required spritesheets, but for now I've simply eliminated loading of everything not needed for the first level. That alone got me down to around 110MB peak usage.

Next up, I began resizing all of the sprite and tilesheet textures. An across-the-board resize of 75% got me down to around 80MB peak. Several larger spritesheets could be downsized even further. Next up, I stopped loading variations of HUD and player sprites for different player colour options and for player two, as there will be only one player on the phone.

After all that, I'm currently down to 75MB in-game, and 80MB or so on the map screen. I'm still investigating further reductions, including using DXT compression for spritesheets. My target is 65MB in-game usage before reinstating sound effects and boss fights, which will require a good 10-15MB of RAM per level on top of what's used already.

I'm not going to officially confirm Dysnomia for WP7 until I'm sure I can make it work, but so far I'm impressed with the virtual sticks (emulating left/right thumbsticks via the touchscreen) I've implemented, so I'm sure it will control quite nicely if I can just get everything squeezed into RAM.

Game 4

Can't wrap up this post without a quick update on Game 4. I've resumed work on the next Team Mango game, working on it alongside Dysnomia for WP7 and Run! for XBLIG. It's an RPG, and the next job I needed to complete was getting an enemy manager up and running. The manager controls all of the enemies loaded on a map, including their spawn points.

As the game is based upon my XNA Tile Engine solution, I'm using the Tiled editor to lay out the area maps. To depict enemy spawns, I'm using an Object layer. The screenshot below shows a typical map layout with spawns. Each rectangle represents one enemy's patrol area, with the spawn point in the center. When the enemy is loaded, a point within its rectangle is chosen at random, and the enemy begins to move toward that point. When it reaches its destination (or collides with a wall), it chooses a new destination point from within its rectangle.

And the result, Squirrels!

Moving House and Team Mango projects for the next year

2010-11-15T15:19:00.014Z

I'm almost done with the house move. That is to say - we're in, but still living out of boxes while we wait for a few bits and pieces to come together. It's not been the smoothest of moves, especially having our garage broken into no more than two days after spending our first night in the new place. Nothing too essential gone, but all of my guitar amps and effects were taken. I was planning to sell them next year to fund a new PC, so it looks like that may be on hold for the time being.

Anyway, troubles aside the new house is looking great and I now have a spare room studio setup for working on all the Team Mango projects that I've been planning for the better part of half a year while all the househunting and moving was taking place. Here's a dark picture of my workstation:

I need to do a bit of housekeeping in this post, starting with an update on 7Cache, my Phone 7 Geocaching app. I've decided to suspend the project for now, because Groundspeak released their official Geocaching app for the phone, and it seems to have everything most 'cachers would need including offline caching. It's quite well presented and seems to work well, though I have yet to get out and test it properly on a full day's caching. It certainly has more features than I planned for 7Cache, apart from the Cache Radar function. I rarely used that in Geocache Navigator anyway.

I may revisit this decision further down the line if there's a niche for features that Groundspeak won't add to their app, or if they make the Geocaching.com API publicly available. For the time being, I have game projects to work on and that's where I'd rather spend my very limited personal time. Speaking of which...

That's Run!, the third game from Team Mango. It's been in the works since February, just before Dysnomia hit Xbox Live Indie Games. I've been working on it sporadically, but it's close to being ready now.

I'd describe it as "Skyroads with Avatars", and it offers 1-4 players local competetive play as well as online best times, using the same highscore sharing method employed by many XBLIGs. I'm looking forward to finally getting it out the door after a busy few months away from all things Indie Games.

The fourth Team Mango game remains under wraps, but I can say it's an action-RPG, and will be released for Phone 7, XBLIG and Windows sometime in 2011. It should also be pretty damn funny, but I guess that's subjective!

Also,

Windows Phone 7 Device Get

2010-10-22T16:41:00.005+01:00

Just a quick post with some images of my Samsung Omnia 7, running my two current projects: 7cache, and the next Team Mango game. I'll post more on the phone and the projects once I've finished moving house ;)

XNA Tile Engine Base Solution Updates

2010-10-02T19:40:00.006+01:00

I've done a little more work on my XNA Tile Engine for WIndows Phone 7, and I've also branched it off into a solution for Windows and Xbox, which I've dubbed "HiDefTileBase".

The HiDef solution contains an additional example mode showcasing a platform game running on the engine. It's important to note that both the RPG and Platform examples are using the exact same classes for drawing the tilemap and controlling the camera - only the GameplayScreen and Player classes differ to reflect the actual game mechanics.

I've added an example of a day/night cycle into the RPG game in both the Phone 7 and HiDef solutions, and made some optimizations to the map drawing routine as it was getting rather slow when several layers were being drawn. All looks good now, although performance on Phone 7 hardware is still a mystery :)

The two new downloads are after some screenshots:

Please note that the solution is built on XNA 4.0 and will not compile using older versions of the XNA SDK.

Hi-Def (Xbox & Windows) solution: http://team-mango.com/stuff/hideftilebase.zip

Phone 7 solution: http://team-mango.com/stuff/phone7tilebase.zip

Phone 7 XNA Tile Engine Base Solution

2010-09-28T10:47:00.007+01:00

A lot of the game ideas I have require a tile engine as a base. I've had a few ideas for Phone 7 games but thus far I've given up at the first hurdle - a tile engine.

I've now resolved that issue by creating a base solution with a ready-to-go tile engine that is suitable for side scrollers, top down and RPG-style maps. I've decided to release it so that anyone else in my position should be able to pick up this base solution and get cracking on tile-based games.

The solution imports maps created with Tiled.

Here's a video of the engine in motion:

And a handy list of all the features of the solution:

Suitable for side-on and top-down games
Good for platformers, RPGs, shooters, racers, adventures - anything that needs tiles!
Works in landscape or portrait with one line change.
Built on the Windows Phone 7 XNA Gamestate Management engine sample.
Uses Nick Gravelyn's content pipeline extension for the "Tiled" editor.
Simple but flexible camera class that clamps to the map boundaries.
Draw the whole map at once, or one layer at a time for flexibility.
Parallax scrolling simply by adding a couple of properties to a layer in Tiled.
An overload to draw a layer as "shadows" by drawing offset+black+semi-transparent.
Per-pixel colour-based collision detection on specified layers/tilesets.

I've added a whole bunch of comments to hopefully help some beginners along the way. Please note that this is just a base engine for a game, and won't help you magically write your actual game mechanics!

This is the first time I've released some code with the intention of helping other developers, so please leave comments below. I'll address any questions in future posts. If anyone with a real device reads this, please consider giving it a run on a real phone - I'd love to know how it performs (if it runs at all!). Take some video as well!

A few screenshots next, download link is at the bottom of the post!

Tiles used in the solution are released freely at Lost Garden.

Please note that the solution is built on XNA 4.0 and will not compile using older versions of the XNA SDK.

Download the solution: http://www.team-mango.com/stuff/phone7tilebase.zip

7Cache - New screenshots

2010-09-06T14:19:00.011+01:00

Lots of work done this weekend. .GPX importing from Windows is working (in theory!). Also implemented direction and bearing to both the active cache and any cache you select from the map. Distances can be displayed in metric (km/m) or imperial (mi/ft).

Edit (Tues 7th): Added Cache Radar screenshot!

7Cache - Planned Features

2010-09-03T14:36:00.005+01:00

Work continues on 7Cache - my Windows Phone 7 Geocaching application. I've compiled a list of features that will make it into the first release:

Import of .GPX pocket queries via a companion desktop application.
Offline storage of around 2-3000 caches, including descriptions, hints and recent logs. You won't need a data signal to find caches you've pre-imported!
Bing Maps integration. View caches on a pan/zoomable world map, find caches near your location quickly.
Full details of each cache: descriptions, recent logs, hints, cache size/terrain/difficulty, distance and direction to cache.
Cache Radar - similar to the radar function in GCzII and Geocache Navigator, shows distance and direction to cache, along with your direction of travel. Will have an optional audio "click" as you get closer.

Some of the must-have features that will make it into the app in the future, as soon as it's possible to do so:

Download caches directly from Geocaching.com with a "find caches near me" feature, fully integrated with the Cache Map.
Log your finds directly to Geocaching.com.
Integrate phone compass with cache radar so there's no doubt about which way to head.
Import .GPX files from Skydrive, Windows Live's online storage facility that will be used to share content with all your Windows devices.

I'll be posting some more screenshots this weekend. I'd like to hear suggestions from any prospective Windows Phone 7 Geocachers about features that you'd like from a mobile 'caching app. Leave a comment!

7cache - Geocaching App for Windows Phone 7

2010-08-29T19:32:00.009+01:00

Microsoft is ramping up to the release of Windows Phone 7, and they've really been pushing the developer tools recently. The tools for WP7 development are now packaged alongside the XNA Game Studio 4.0 previews. I can see the reasoning behind it - WP7 development is either Silverlight or XNA and you'll use the same tools to develop XNA games for Windows, Xbox and Phone.

What makes less sense is that the Silverlight applications development side of the WP7 tools are also bundled in with the beta, creating an odd mishmash of tools for WP7 apps, WP7 games, as well as Xbox and Windows games development.

If Microsoft were hoping to tempt some of the XNA community over to Silverlight, they've succeeded! I briefly touched on Silverlight back in the 2 beta but I thought I'd have a dip into creating an application for Phone 7. I also intend to explore cross-platform games development for the phone and Xbox at a later date.

I've decided to create an application for Geocaching on the phone. In a nutshell, Geocaching makes use of GPS technology to create a worldwide outdoor treasure hunt. Geocaching.com holds a database of "caches" placed by Geocachers around the globe, and provide the data for users to hook up their handheld GPS unit or GPS-enabled mobile phone and go hunting for caches.

The best mobile Geocaching application I've used is Trimble's Geocache Navigator on my Nokia N95. I'd like to get all the features of that particular application into my app, while providing a modern easy-to-use interface that makes the Geocaching-on-the-go experience a pleasant one.

And so I've begun prototyping my first Windows Phone 7 application, 7cache.

It's a good project as it not only exposes me to more Silverlight, but it also makes use of many features of the the phone, including GPS, mapping and (when made available in the API) the compass.

Unfortunately, while I can develop out the application to be as feature-rich as most Geocaching applications out there, I may never be able to release it as a real product. To be of any use, the application must be able to bring in XML data about the caches themselves. In other applications, this happens in one of two ways:

1. The user uploads .GPX waypoint files to the phone, and the application reads them in. Or:

2. The application connects to Geocaching.com's API and retrieves cache data directly.

The first method is not possible on Phone 7, because Microsoft is not allowing direct access to the filesystem either by users or third party apps. I was hoping to make use of the rumoured Skydrive integration, but the API is currently limited to retrieving pictures from a user's Skydrive. I could leverage Azure services, but that would require users to go through a Windows application or hosted website to get their GPX files to their phone, which is an unwanted layer of abstraction.

The second method would be ideal, if Geocaching.com made their APIs public. At the moment, only selected partners are able to query the Geocache database directly in their applications. They have said they are looking at opening up the APIs to a wider audience in the future. If they do, I'll be waiting with a near-complete solution for Phone 7 users.

Of course, there's other obstacles to overcome - I'll need a physical device to implement real geolocation properly. It's possible to fake it in the current API, but in order to build out the "cache radar" function, I'll need to test on real hardware. Having said that - so far the emulator is doing a great job!

On another note, I should really stop starting new projects!

Dysnomia: The Post-Mortem

2010-08-20T08:24:00.019+01:00

Before I begin with this post, I should say that I am more than happy with the successes I have achieved with Dysnomia. I set out in May 2009 to create a game that I could be proud of, and that I would enjoy playing. I had no thoughts back then of making money from selling the game on the Xbox Live Indie Games (XBLIG) service, where my first release Gravsheep had failed miserably.

Dysnomia was born out of a love for '90s Amiga games, and those in the know immediately liken it to Team 17's Alien Breed. I did indeed set out to make an Alien Breed-alike, but there was another much less-known game that I borrowed ideas from. That game, Xenomorph, was a Dungeon Master-like crawler RPG set on a mining outpost. In fact, reading the game's Wiki article it's scary exactly how much I borrowed from it!

So the top-down, alien-shooting arcade action was borrowed from Alien Breed, whilst the parts-collecting and puzzle-like elements were borrowed from Xenomorph. The game's speed and sheer number of enemies on-screen was kind of a throwback to Gauntlet, but that came about naturally as I added in dual-stick shooter controls. Early in development, the right stick was unused and the player could only shoot in the direction of travel. That's one early change I'm glad I made.

I began in May with a design document that gave an initial outline for the game, and gave me something to show to potential artists that applied to my request for help on the Creator's Club forums. I believe that having that document showed artists that I was semi-serious about the game even though I was only offering a 50/50 profit split. I was pleasantly surprised at the number of replies, but at the end of the day one guy stood out from the crowd simply by getting the game idea and throwing out a few initial tilesets, some concept art and a character animation. That guy was Leon, and without him Dysnomia would be nothing more than a long-forgotten Visual Studio project folder.

And so the two of us ventured forth with development. One of the very early jobs for me was to enhance the level editor I had hacked together for Gravsheep so that it could be used to design the levels for Dysnomia. The editor was a simple Windows Forms affair, with drawing handled in GDI as opposed to using WPF or an XNA window. So, not the fastest of editors, but it worked well enough for both myself and Leon to get the levels done.

There are nine levels/floors/areas in Dysnomia, and each one was saved out of the editor as a simple plain text file using 2D arrays of three-digit integers to represent the tiles. Each map has a set number of layers overlaid in a set order. Some of the layers were full-colour tilesheets, others were effects layers. Later on I added in animation layers which were used sparingly, the biggest example being the animated water on the Maintenance level.

If I had to go back and do the editor again, I'd do it in Silverlight to start with. I'd allow for an unlimited number of layers each with a specific effect applied (shadow, reflection etc). I'd allow for multiple tiles to be selected in the tile palette and pasted into the map (large objects made up of several tiles had to be drawn tile-by-tile!). I'd make it a lot more generic too. Like I said though, it did the job and allowed me to focus on the game.

Developing the game itself was a veritable minefield for this amateur developer. Although I've been messing about with games development since the Acorn days, this is really the first serious game that I've attempted. Instead of playing it safe and skirting around issues I knew would be a challenge for me, I ploughed through. I implemented some features in Dysnomia that I never thought I'd be able to write. The one that immediately springs to mind is the pathfinding AI.

I hadn't even considered that the aliens might actually need to be able to find their way to the player. I guess I'd hoped that the Gauntlet-style logic of "move toward player location until you hit a wall" would suffice. Not really, no. It became apparent that some basic intelligence would be required. I knew nothing of the various pathfinding techniques that developers had used over the years, and I only just managed to understand A* after a few days of reading.

Luckily, Roy Triesscheijn has done a lot of work implementing A* in C# and XNA. I was able to leverage his examples as a good starting point. There was an awful lot of work to do to even with that initial code as it was quite allocation-hungry, and of course I had to make it work with my tilemaps. It all came together in the end though, and I could probably write a whole post on how.

There were a number of other challenges that I won't go into detail on here. Performance was a big one, and I learnt how to use the XNA remote perfmon tool and the .NET CLR profiler together to banish allocations and garbage collections. For those interested, I went down the path of allocating everything during load and nothing during the game and it worked wonders.

And so onto the game itself. The game received a number of awesome reviews, which I was so happy with. To see something that you poured so much love into be received so highly was reward enough. It went down fantastically with the Creator's Club members that playtested and reviewed the game. Receiving praise from peers is even better than getting good reviews!

Then the unthinkable happened - Dysnomia placed in the top 20 of Dream Build Play 2010! Leon and I decided to enter the game on a whim, and it just happened that we were mere weeks away from a complete and polished game when the deadline rolled around. That definitely worked in our favour. Although we didn't get a cash prize, Dysnomia became eligible for a place on the "Contest Finalists" section on the dashboard. More on that later.

One of the more common comments about the game is the respawning of enemies. In Dysnomia, the only enemies that are gone completely once killed are the bosses. All of the other enemies are spawned constantly, so there's always something to shoot. Many players didn't like that, and suggested that once the player clears a floor, the respawns shouldn't happen - or at least occur less frequently.

Looking back on it, I agree. If I was doing it all over again now, I could create a more tense and atmospheric game by using spawns more intelligently. Combine that with better use of the lighting system and it could have been an entirely different experience. The fact remains that Dysnomia definitely became more of a standard frantic dual-stick shooter than a story-driven adventure shooter. Maybe next time?

On a more personal level, I would have like to have used the motherboard/device mechanic a lot more. Motherboards in the game were inserted into and removed from devices such as doors, terminals, turrets and switches to power them up and down. The initial idea was to have more of those devices so the mechanic would become almost puzzle-like. If combined with less frequent enemy spawns, more motherboard/device puzzles would have been great. However, I think due to the overall speed of the game the frequency of the puzzles was just right. Any more and the player wouldn't have had time to solve them in between bouts of shooting!

And now to the boring business side of things. Dysnomia cost me around 800 hours of my time, and probably the same of Leon's. We couldn't possibly hope to make enough money to pay us a full wage for that much work. Good job this is just a hobby, right?

I spent around $100 total on assets for Dysnomia. Most of that went toward the sound effects I purchased from Soundrangers. That's right - I created a nine-level, three hour or so long indie game for $100. That's £70, give or take. So if you're looking purely at the bottom line financially, Dysnomia has made about ten times what was spent on it so far.

The music was mostly free-to-use public domain stuff composed by Matt MacFarland. The title track was made by one of the original members of Team Mango (as it existed back in high school), Adam Bartlett. The in-game ambient track was purchased from Shockwave Sound and composed by Bjorn Lynne (who wrote a lot of music for Team 17 and the theme music for Alien Breed 3D).

As I said, Leon agreed to do the artwork based on a 50/50 profit share, and I was lucky to find an artist that has the same passion for making games that I do. Any money we make is great, but it's not our focus at all.

And so, to some numbers. Here's a pretty chart:

Fairly self-explanatory. Firstly, not a great conversion ratio of around 6%. Secondly, you'll notice that huge trough between the end of March and the middle of June. End of march is when we dropped off the Indie Games new arrivals dashboard list after the first ten days or so. We then had very few sales and trials, most of them were driven by the reviews we were getting.

On the 15th June, the game was promoted to the Contest Finalists section of the dashboard, and that's where things pick up again. Sales aren't quite what they were in the first week, but the conversion ratio is similar. We currently average around 4.5 sales/day. I expect the sales to continue this way until we're pushed off the Contest Finalists section sometime next year.

Here's the totals for 19th March - 18th August:

Trials: 8002
Purchases: 487
Purchase/Trial Ratio: 6.09 %

So, we're nearing 500 sales fast. My personal target for Dysnomia was 1000 sales, and it looks like we'll reach it if things stay as they are now. What's more impressive is that 8000 people out there have played (or at least downloaded) my little game!

What makes me a little glum is thinking about where we'd be without the DBP placement. Sales and trials were dire in April and May when we weren't on the dashboard top lists. Even with some great word-of-mouth, we were nowhere. It goes without saying that if we were looking for financial success, XBLIG was not the place to find it with a game like Dysnomia.

I priced Dysnomia at 240msp. It's the price point of a quality XBLIG game that actually wants to sell some copies, which would not happen at 400msp. I think it's a fair price. When we drop off the Contest Finalists section, I'll drop it to 80msp. That's fairly selfish (and probably quite mad!), but it'll be a reasonable experiment to see if a quality game like Dysnomia can make some sales when not on the top lists. Should be interesting!

So there you have it. Dysnomia in a (rather lengthy) nutshell. The best game I've ever made and some of the most enjoyable coding I've ever done. I improved as a developer by an order of magnitude whilst writing it, and will always look back on the process fondly. Financial success maybe not, but a personal triumph indeed.

Quarterly Report

2010-08-19T08:15:00.006+01:00

Oh dear, looks like I reneged on my self-promise to blog at least once a month this year. No great surprise there. Usual excuses apply. So I've decided to make up for it with a series of three posts that will serve as a catch-up on the hectic four months since I released Dysnomia. Whether anyone still reads me, I have no idea. Drop me a comment or something!

Immediately after Dysnomia's release, I launched straight into my next XNA project that is now entitled "Run!". The next in this series of posts will be all about that particular game. In hindsight, I think it was way too soon to leap from finishing a 9-month development cycle into a new project. I had initially decided to take a couple of months and brush up on some XNA bits that I'm not strong at, such as shaders. But instead, I got right on with a new game - simply because the creative urge was still there.

In fact, one new game wasn't enough and I also started working on the engine for what will be the fourth Team Mango game. I'm not ready to talk about that one yet - but there are some cool ideas floating about. The idea was that I would have Run! finished by the end of June, and game four would be a six-month project to launch at the end of the year. That's not going to happen now.

You see, I've decided to grow up and get on the property ladder. Jenna and I started the hunt for a home at the beginning of the year, and in June we found a nice maisonette that's inside our rather humble price-range and put in an offer. That was the end of our six-month property search and we were sure we'd be all moved in by now.

However, after a six-week long wait full of stress, we were rejected by the first mortgage company that we applied to. The rejection was due to a change in circumstance that was bought up in the third week of our application, but for some reason we were strung out for a further three weeks before the rejection came through. Cue mad panic to secure a new mortgage before the vendor gave up on us.

As I write, we're two weeks into our second application, and things are looking way more positive. Keeping everything crossed for a swift resolution and hoping for a completion date sometime in September.

Having our own place will afford me the luxury of a spare bedroom office/studio which I struggled without during development of Dysnomia. Looking forward to having my own space to really crack on with the next two games. One we're fully settled, I'll have much more time not only for development, but also to be a more active XNA community member and maybe even fit in another couple of potential projects I have lined up, including something musical!

So, that's where I've been for the last four months - buying houses and nearly finishing a third XBLIG title. I'm tired, stressed, and in dire need of a holiday - but also extremely positive and excited about the coming months.

Dysnomia Released!

2010-03-18T14:31:00.003Z

Dysnomia is now available for download from the Xbox Live Indie Games channel. If you've got a Live account, you can click this link to hop straight over to Xbox.com and download it directly.

I'm going to write a longer "wow, it's done" post soon, but for now here's some of the buzz that Dysnomia's been getting:

"Nothing short of awesome! ...This is what I've been waiting for!"

"This game is pretty great, really professional and high quality."

"This game really sets the bar higher on what to expect from future indie game titles. I will be keeping a close eye on its success for sure."

"I can spot a game that XBLIG has been crying out for. Congratulations!"

"I think this is the best xbox indie game out there in terms of sheer game content, and arguably the best overall from what I've seen."

"I wasn't expecting it to be this good."

"Wow, gotta say Dysnomia knows how to impress. Who knew that a Metroidvania game could work as a twin-stick shooter."

Here's all the obligatory links you'll need to find out more about the game:

http://www.dysnomiagame.com - Official game site

http://www.team-mango.com - Team Mango site

http://www.facebook.com/teammango - Team Mango facebook page. Become a fan, already!

http://www.twitter.com/teammango - Team Mango Twitter feed

http://www.twitter.com/garethiw - My Twitter feed

Dysnomia Development Diary - Getting ready for Dream Build Play

2010-02-20T19:53:00.006Z

Dysnomia is going to be ready for Dream Build Play. Feels great to be able to say that because it did look touch and go as little as a month ago. There's been so much to do just to get the game to a feature-complete state. That said, the game is now playable from start to finish and all of the gameplay is locked down, as is the level design, enemy design and all the other bits that make up the actual playable portion of the game.

When people ask what exactly is taking so long, It's always hard to explain. It's pretty easy to get a game designed and working - and even fully completable. It's the unnoticed details in every game that takes up development time, especially in the late polishing phase. Things like nice menu screens, tutorials, on-screen prompts. All the transitions that make the user experience smooth, fading and animation of UI elements, making sure that interactive objects provide the right amount of user feedback. All things that I've been working diligently on over the last three months, whilst also finishing level layouts.

Sound as well - finding the right sounds for a game as complex as Dysnomia is hard. There's a lot of events that require sounds in the game and I have to scour several stock sound effects sites to find effects to fit the on-screen happenings. Then I have to edit them down, set mix levels and in-game audio cues for each one before I can tie them to actual objects on-screen. There's currently 49 individual sound effects in the game, and I anticipate adding at least another ten before we wrap up.

So, after nine months, an estimated 800 hours work (from me alone, not including Leon's time for the art) and more than 30,000 lines of code, Dysnomia is ready to be submitted to Dream Build Play next weekend. I'm not expecting the game to win a top four prize, but my hope is to finish somewhere in the top 20 semi-finalist positions.

There's not a great deal to do after DBP - some more sounds, an intro and outro and a final bit of polish. The game will be submitted to XNA Creator's Club peer review in March. With enough testing beforehand, the game should appear on the marketplace near the end of the month, or early April.

I then plan to do a lot of marketing for the game over Easter and for the rest of April, before taking a well-earned couple of months of relaxation before starting the next game in July.

Can't wait to get the game out there and for you to play it!

New Year, First Post

2010-01-13T11:55:00.002Z

I've been neglecting the blog for a while now in order to really get working on Dysnomia. We're entering in for the March Dream Build Play competition, so it's full steam ahead for that.

I've launched the official Dysnomia mini-site, which has a brand-spanking-new trailer on it. And apart from that it's been work -> dysnomia -> bed for a couple of months. Which is all good! I'm hoping that once we're done with the game I'll get back to a regular posting schedule and write up a few XNA tutorials I've been thinking about - as well as getting life back to normal and getting outside more. Until the next project at least!

Happy belated 2010!

Dysnomia: First Playtest

2009-11-16T08:57:00.006Z

It's been six months in the making, almost to the day. Tonight, we release the first playtest of Dysnomia to the XNA Creator's Club community. Although only containing the first three levels of the full nine levels the final game will have, the playtest is extremely polished. I've wrapped up most of the engine code, all there is to do now is to get down to designing the final levels. I'm going to go ahead and call it for a February release now. That's not too bad - only three months overdue!

I just spent a week's holiday polishing off some of the important Xbox integration features of the game. Handling things like gamer profile sign ins/outs, save locations and a trial mode are all essential things to have in an Indie Games release - yet so many games fail to implement all of them correctly.

I then moved on to creating a fantastic boss fight that I hope will be the first of four or five battles against epicly-sized denizens. Here's a screenshot:

He's an ugly mofo, that's for sure!

I'm planning on at least another two playtests depending on the responses I get from fellow Creator's Club members. If all goes to plan, the second playtest will include one more level and the third one will have most of the content in place. I'm guessing playtest two will be out over Christmas.

So close to completion, yet still more hard graft to get there.

A Quick Reminder

2009-09-16T12:26:00.003+01:00

If you're interested in Dysnomia, the best place to keep up with announcements (and to discuss the game) is over on the Team Mango Facebook page. Become a fan!

Dysnomia Update

2009-08-21T21:44:00.003+01:00

I can't believe it's been over a month since my last diary post. Time is flying this summer. There has been a lot of work going into a lot of behind-the-scenes stuff on Dysnomia. The sort of stuff that needs to get done but isn't really worth blogging about.

So yes, work is still progressing well. Tutorials are in. The starting area is more or less complete. Work has begun on local co-op. Tiles for the later areas are starting to roll in and they are looking fantastic. The very last area especially is looking very tasty.

I've been trying to work on some of the more boring stuff like Xbox controllers and profiles, loading and splash screens, XNA best practices and other things. I learnt during development of Gravsheep to get that stuff out of the way as soon as possible, as putting it in at the end when all you want to do is release the damn game already proves to be a drag.

I've been trying to figure out whether we're still on track for a November release, and I'm still as yet undecided. It all really depends on how much time I get to work on the game - but I have a feeling that while the game will definitely be out before Christmas, it may not be as early as November. Having said that, if we used November 15th as an arbitrary release date, we're still only just over halfway through development time. And if I'm honest, the game feels about half-done at this point.

So there you have it, folks. Dysnomia is officially halfway through development. Time to update the Wacky Idea-o-Meter!

Dysnomia - Development Diary Part Six

2009-07-20T19:58:00.009+01:00

This week, I'd like to talk a little about Dysnomia's audio "engine". It's no so much an engine as it is a simple class to control the XACT project behind the game. XACT (Cross-platform Audio Creation Tool) is Microsoft's high-level audio library and engine, releaed as part of DirectX.

The XNA community seems to besplit between those that love XACT and those that prefer to use XNA's built-in audio calls. Because I started using XACT in XNA 1 when it was the only option, I'm reasonably comfortable with both the tool and the API calls in XNA so it was my first choice when thinking about the audio in Dysnomia.

There were two tasks I needed the Dysnomia audio engine to perform, alongside the usual simple sound playing. The first was to have some sounds play positionally, according to the location of certain events on screen. Enemy footsteps, weapon hits, doors opening and so on can all occur at any position on the screen, as opposed to simply coming from the player. For this, I needed to set up the Attenuation RPC preset in XACT and use it in my audio class when playing the appropriate sounds.

First of all, I modified the "Distance" Cue variable, giving it a range of 0 to 1000. The range can represent anything you want it to, but in my case I've set it up to be the distance in pixels between the player and the sound emitter.

Next, we set up an "Attenuation" RPC preset. As you can see in the screenshot, we are setting up the parameter to control the volume of the playing sound, using our Distance variable as input. The curve is set up to roll off the volume of the sound as the Distance variable increases, with a sharp rolloff at the end to completely mute the sound when Distance reaches the point where the player should no longer hear the sound.

Next up, we need to attach the Attenuation RPC to all sounds that need to be played positionally. Simply right-click the Attenuation preset and select "Attach/Detach Sounds". Select all neccessary sounds and click "Attach" to move them to the attcahed column.

That's it for XACT. Now for some code. First of all, we need to set up an AudioEmitter and an AudioListener. Note that all code here comes from my Audio class, which is static simply because I'm using the same XACT project and calls for the entire game.

public static AudioEmitter aE = new AudioEmitter();
public static AudioListener aL = new AudioListener();


private static Vector3 aEVect = Vector3.Zero;
private static Vector3 aLVect = Vector3.Zero;

As you can see, I've set up a Vector3 for the Emitter and the Listener as well. We'll use these in the play method. First though, I'm initialising a Velocity for the Emitter. I do this in the LoadContent method of my Audio class:

public static void LoadContent(ContentManager content)
{
...
aE.Velocity = new Vector3(30.0f, 30.0f, 30.0f);
...
}

You might have to play around with this to get the velocity just right. 30 seems to work for me. Next up, we define a method to play any sound positionally:

public static void Play3D(string EffectName)
{      
aL.Position = aLVect;
aE.Position = aEVect;    
EffectsSoundBank.PlayCue(EffectName, aL, aE);
}

So, we're passing in only the name of the sound we wish to play. The method sets the position of the AudioListener and the AudioEmitter to the values of aLVect and aEVect, which we set up earlier. Lastly, it calls PlayCue on our SoundBank, using the positional override.

Now for an example of the methods we call from the actual game classes:

public static void DoorOpen(ref Vector2 DoorPos)  
{       
aEVect.X = DoorPos.X;     
aEVect.Y = DoorPos.Y;                 
Play3D("door1"); 
}

So, this method is for playing the sound of a door opening. We pass in the location of the door in the game world, and copy the values to the X and Y positions of our Emitter Vector3.

Time out for a quick explanation of what's going on. In my game, I know the position of the player in the world. The AudioListener must be set to the player's position in the world, which I do on each update:

(in Player.Update:)

Audio.Audio.UpdateListenerPosition(ref Position);

(in Audio:)

public static void UpdateListenerPosition(ref Vector2 PlayerPos)   
{       
aLVect.X = PlayerPos.X;        
aLVect.Y = PlayerPos.Y;   
}

Every time we play a sound in the world, we know where the sound is coming from. A door, an enemy - they all have a position in the world so we set the AudioEmitter position to the same. When PlayCue is called, XNA takes care of positioning the sound for us based on the Player's position (AudioListener) and the sound position (AudioEmitter). Our Attenuation RPC further affects the resulting sound by rolling off the volume according to the distance between Emitter and Listener. Simple? Don't worry - follow the steps and you'll get it eventually!

In my next diary post, I'll write about the second task I needed the engine to perform - crossfading audio tracks. For now, I leave you with another gameplay video.

Dysnomia - Development Diary Part Five

2009-07-13T08:38:00.014+01:00

Another week rolls by!

Loads of exciting progress this week, a great deal of which involved adding new features at long last. I'm now extremely confident that we'll meet the proposed November release date and maybe even with a month to spare to do some really in-depth playtesting and polish. We're also considering a possible Windows release, maybe around the holidays or early next year.

I'm going to break up the text this week with some of the great graphics that Leon's been working on. I'm sure you'll all agree that everything is looking rather awesome. Usual screenshot selection at the end.

This week saw the implementation of Medikits and Ammo packs (Batteries). I also added some on-screen control prompts to give the player a better idea of which buttons perform which actions when near something they can interact with. There's also been some changes to the game mechanics again - although really they're constantly evolving throughout development. These changes will be the meat of this week's entry.

As discussed in earlier diary entries, Dysnomia isn't all about running and gunning. Although a lot of time will be spent dispatching the alien hordes, it will be exploration and survival that will provide the path to completing the game.

I didn't want to go too over the top with the whole survival thing and end up giving the player an inventory to manage. I also didn't want the player to carry as many medikits and ammo packs as they liked. I think it takes away some of the sense of danger when all you have to do is hit a button or hide behind a wall to regenerate health.

It's with that in mind that I have made medikits and ammo in Dysnomia single-use pick up and consume objects. I had a bit of criticism about the way fuel was managed in Gravsheep, whereby the player could accidentally pick up fuel they didn't need. In Dysnomia, I've addressed this issue by requiring the player to press X to pick up and use both health packs and ammo.

On the subject of ammo, it may seem a little harsh not allowing the player to carry more "magazines" and reloading as required. I think my idea behind this is solid, but I'll be listening carefully to thoughts on this during playtest. Essentially, the player's gun in Dysnomia is an energy weapon. It is recharged by using batteries (the ammo packs). The gun has five modes of fire, each represented by a different colour. The colour of the battery will determine which firing mode it recharges.

For the first couple of areas, the only ammo available will be the blue ammo for the first firing mode. A full charge of blue energy will more than likely last a very long time. Subsequent colour batteries will start to appear on further levels, giving the player more firing modes that will get progressively more powerful. The player will be able to switch between modes at will. I plan to implement a reasonably powerful melee attack for when the player completely runs out of charge on all modes. They'll at least be able to defend themselves whist they head towards the nearest ammo cache.

Another small but nonetheless significant change I've made is to put a progress bar on a device when it's powering up. I've already written a little bit on devices such as doors, turrets, switches and terminals. Each device requires a number of boards to be installed in it before it powers up. What I've done is to add a little delay between the last board being inserted, and the device being usable. I think that makes sense in a world perspective, but it also adds a little extra challenge. It might make players think twice about taking boards out of a door they use frequently. If a turret is guarding a particularly busy corridor, maybe the player won't want to borrow a board from it if it will take a little while to power up again.

They're all small changes, but ones that I think add to the depth of the puzzle/exploration/non-combat side of the game. I'll be waiting for the results of playtests to see if potential players agree with me though!

Dysnomia - Development Diary Part Four

2009-07-06T12:43:00.010+01:00

I've been doing a great deal of work under the hood this week. I was lucky enough to get an entire weekend with my 360 and my development PC in the same place. I spent that time wisely, doing some 360-specific bug hunting and feature additions.

Firstly, I was hunting down an annoying little hitch that was rearing its ugly head on the 360. Although the game was running at a solid 60fps and the Remote Performace Monitor was showing few if any allocations and collections, there was still a definite little hiccup occurring every few seconds.

After reading through the XNA forums a little, I decided to give IsFixedTimestep = false a go. Shawn Hargreaves explains the difference much better than I'll ever be able to, but essentially it was a last-ditch attempt at solving the problem after going back over all the code several times. This was the XNA thread that gave me the idea to try it.

And after updating all the movement code in the game to take ElapsedTime into account, the problem went away. We're talking one hundred percent smooth-as-silk on the 360 now. I celebrated by jumping straight into getting some rudimentary game saving done.

I'm still not quite sure how to handle saves in Dysnomia - I plan to make the game saveable anywhere, as I believe all casual games should. Right now, the game is saved by pulling up the pause menu and hitting "save". Can't get any simple than that.

Of course, I need to consider things like autosaving and the like. On the 360, I will be attempting to find a storage device as soon as the player hits start before the menu screen. This will allow for a main menu "continue game" option if the current player has a save file already. I now need to work out the little details such as when to autosave, what I'm going to do in a co-op game (although I haven't started on co-op play yet, everything is being coded to allow for two local players) and whether to offer multiple save slots. It's all easily do-able, but one needs to consider the end-user and the most intuitive way to handle their save games.

Talking of co-op play, I still haven't decided how to handle death with two players. In a single player game, if the player dies, it's game over and he's given the option to load the last saved game or exit to the main menu. With two players, that's not a great option - a surviving player should probably be able to play on without the dead player. I'm currently considering a one-minute respawn where if the surviving player can hold his own for a minute, the dead player will respawn right next to him with perhaps a half-bar of health.

Implementing co-op is a way off yet, but I'm keeping it in mind as I go. It's on the "nice-to-have" list along with boss fights. I get to that list when all the other game mechanics are in.

I'm often asked when the game will be finished. In my original design document, I stated October as a release-to-playtest month, and projected November for release. It's safe to say we're on track for that if things keep going at their current pace. My hope to have a playable two-level demo with all neccessary game mechanics by the end of July is, however, looking less likely. I can't release a demo without a tutorial and the tutorial is still way down my to-do list, underneath things like: Health packs, ammo packs, weapon powerups, fuel rods, ship status, terminal screens and so on...

Dysnomia - Development Diary Part Three

2009-06-29T08:48:00.007+01:00

A bit of a shorter diary this week as I'm busy working on a number of things in Dysnomia that I'm not quite ready to show yet! Also, this week is more about coding than anything else, so non-techies may want to wait until the next entry when I should be showing off a little more of the game!

Optimisation is a very important part of game development. However, for simpler games you may not ever need to worry about performance - let's face it, if your game is running smoothly on your target platform from start to finish then going back over the code and optimising for the sake of it is ultimately pointless. Put the energy into starting your next game!

Likewise, spending hours and hours pondering over every line of code to ensure it's as efficient as possible will likely result in a convoluted and hard-to-follow program.

If you know your game is likely to use a lot of memory, either graphically or object-wise then you'll need to keep performance and optimisation in mind right from the start. Because I've never had to optimise a game before, I completely ignored all the issues. That is until I started to get frame hitches when running on the 360. Then I started to realise and put right many of the mistakes I had made.

Shawn Hargreaves, one of the XNA framework developers, has written a number of blog entries regarding .NET garbage collection and the 360. These three posts are the ones I found the most useful when starting to track down where I had gone wrong.

I noticed a definite "jerk" in Dysnomia that was occurring once every few seconds or so. After going through the code and commenting out the heavier update and draw methods, I couldn't narrow it down to one particular place in code. That's when I started to pay attention to the posts regarding garbage collection and how to either avoid or manage collections. I ran the CLR profiler against the game and found that (on Windows at least), I was seeing a level 2 (heavy collection) occurring every few seconds which would definitely correspoind to the glitches on the 360.

I started to look at my code and figure out where it all went wrong. To start with, I was using generic List() lists to hold my game classes. Enemies, spawn locations, lights, bullets - pretty much anything that changes in game is allocated on the fly and added/removed from its list. Each time an enemy died, it was removed from the list. When an enemy spawned, a new Enemy() was allocated and added to the list. Same with bullets. Those are quite complicated classes to begin with, and to top it off I was giving each enemy and bullet object its own Texture2D sprite. What the hell was I thinking?!

To fix the issues, I decided to follow Shawn's advice and went with his first "path" for avoiding garbage collection worries: Allocate as little as possible during the game loop.

I went back and re-worked how I managed my in-game objects. Rather than letting the List allocate for me, I created a Manager class for each of the lists. They work in much the same way as the ParticleEngine XNA sample in that the Manager classes pre-allocate all of the objects I will ever use in game, and use a queue to select the next object for use. When the object in question is no longer needed (if an enemy dies or a bullet hits something), it is set as inactive and placed back on the queue to be used again.

All of the pre-allocation is done when the level and content is loaded. After I've performed all my loading a allocating, I do a GC.Collect() before fading the level up and starting the game. This gives me a clean slate for the smaller allocations (Vector2s and value types mostly) that occur in-game.

Net result is that garbage collections no longer occur whilst the game is in progress. Okay, so now I'm starting to get into this optimisation stuff. I looked at the way I was using Texture2D for loading game content. I realised that having a spritesheet for each instance of a game class (enemy, door, light, bullet) was not the way to go. Too much unneccessary memory wasted.

Instead, in each of my game object Managers, I loaded the spritesheets for each type of object. For instance, I have a Spider enemy and a Slug enemy. Each enemy in my List in my enemy manager class can be a Spider or a Slug type. My manager loads one instance of a Texture2D for a Spider enemy, and one for a Slug enemy. In the EnemyManager.Draw() routine, I loop through all the active enemies in the List and choose the correct Texture2D to draw from, rather than having each Enemy class draw itself from its own Texture2D.

So that's just a couple of the ways I'm handling memory usage and garbage collection in Dysnomia. Allocate lots during load, allocate close to nothing during game. There are still some glitches to iron out in the AI routines that can get a little heavy, but I'm getting closer to that constant smooth 60fps gameplay I'm after.

Here's a bonus off-screen recording showing the action on the 360:

Dysnomia - Development Diary Part Two

2009-06-22T09:19:00.014+01:00

Developing Dysnomia in my spare time makes the weeks fly by. This week, I'm going to write a little about the level editor behind Dysnomia and how I'm linking together map files, save game files and in-game "devices" which need to keep their status throughout a full playthrough.

The map editor is a functional but clunky Winforms application that doesn't use any XNA, but opts for GDI instead.

It allows the level creator to paint using tiles selected from several tilesheets, one for each map layer. The layers are drawn from the bottom up, starting with the floor tiles, then the walls, then anything overhead. There are a number of in-between layers as well, including separate layers for shadows and decals, which break up the tiled graphics without needing to duplicate tiles. For instance, rather than having "floor tile 1" then "floor tile 1 with top shadow", we simply place down "floor tile 1" in the floor tiles layer, then in the shadows layer we place down "top shadow".

The decals layer allows us to place down little "junk" items like littler, blood spatters, corpses, computer terminals and so on. We have a decal layer for the floor and one for the walls, allowing us to place rubbish on the floor and a computer on a table (tables being wall tiles).

The "specials" layer is used to place items that are replaced in-game with objects. Things like lights, enemy spawns, doors, healthpacks and other pickups all have a tile on the "specials" sheet which is used to represent them in the editor.

The editor also allows us to place down Devices used in the game. Door controls, turrets, terminals and all other interactive objects are placed in this way, and then a few controls allow us to change parameters for each device.

The editor saves each level to a separate text file, which contains grids of three-digit numbers representing a tile number. There is a grid for each layer. After the grids are saved out, additional information about the level is appended - the lighting level, map size and all the information about Devices.

The game will be split up into a number of levels, somewhere around ten in total. This number includes the area outside the mining outpost, on the planet surface. The player needs to scavenge items from the base to repair his ship and thus will need to return to the outside area (and the ship) every now and again.

All of the lower levels of the outpost are reachable via a central liftshaft. At the start of the game, the liftshaft does not work, and requires a number of motherboards to be replaced for each additional floor the player wants to reach. The map layout could be drawn as follows:


Outside -> Entry Halls
                |
                v
             Floor 2
                |
                v
             Floor 3
                |
                v
               ...

When the player crosses between levels, there will be a short pause for loading as the next map is read in and prepared for use. However, because the player can explore the entire base at will and return to any previous area at any time, we need to hold a state file on all the objects that the player can interact with. This state file will stay active from the start of a game until the player dies or finishes the game. The same state file will also be used for loading and saving games, so it must hold information on the player's status too - current map, position, health, weapon powerups, ammo etc.

I decided to wrap up all this information in a single class that is instantiated at the beginning of play. The class has its own Load() and Save() methods. The Load() method takes a string as the only argument, the string being the contents of a saved game text file. The Dysnomia editor has a generator to create a save file that represents the intial state of everything in the game. If a player starts a new game, it will be that file that is supplied to the GameData class, essentially creating a "new save" in memory.

Throughout the course of the game, the GameData class will be updated to reflect the current state of the game. For instance, if a player takes a motherboard out of a device, that device will be updated in the GameData class to show that it holds one less motherboard. The GameData class also holds the number of motherboards currently held by the player, which would be incremented at that point.

Some data in the GameData class will only be updated when the game is physically saved. The player's health, level and location would be some examples, as would the location of any enemies currently on screen. I feel that on the whole, it's a solid way of dealing with saving game progress, especially given the open-ended exploration nature of the game.

Dysnomia - Development Diary Part One

2009-06-16T09:00:00.023+01:00

I now feel confident enough to write a little about Game 2, which now has the working title "Dysnomia". Dysnomia is the name of a real moon of the planet Eris, and also means "lawlessness" in Ancient Greek. Dysnomia is the setting for the game - in fact, a mining outpost on the moon.

The backstory (though not fully fleshed out) goes something like: the main character, a space marine, was engaged in a firefight aboard a two-man fighter craft launched from a large battleship. Badly damaged in the fray, and with the mothership destroyed, the ship is forced to lock in a course for the nearest friendly base - a mining outpost on Dysnomia.

After drifting for three days and with systems failing, the marine lands the ship manually just outside the base. All attempts to make contact with the outpost have failed. The marine now has two missions:

1. To scavenge supplies to fix the ship. The ship requires:

- A number of replacement motherboards

- Several fuel rods, which are dangerous to handle and replace

- Navigational data which has been corrupted

2. To complete a report on the base and find out what happened to the inhabitants.

The game is a top-down shooter and borrows ideas from classics like Alien Breed and Gauntlet, whilst adding a few of my own ideas and mixing in a bit of light puzzle solving.

During the course of the game, the player will find many electrical devices in the outpost which require a certain number of motherboards to become operational. Some devices will be up and running, others will be missing some or all of their motherboards. It's up to the player to decide which devices to leave powered up, and which to borrow from for other parts of the outpost. Such devices include:

- Doors

- Computer terminals

- Automated Turrets

- Medibeds

- Electrical fences

- The main liftshaft which links the ten or so floors of the outpost

And of course, once the player has finished his report, he'll need to scavenge a large number of the same motherboards to fix his ship and leave the base.

The game's story will be revealed through visual clues and computer journal entries. As the character discovers more, the Report progress will go from 0-100%. Certain events will be worth a large amount of report progress, so the player won't need to access every single journal entry or discover every part of the base.

And now onto the technical side of things.

Dysnomia is my second XNA project. I began it directly after releasing Gravsheep on Xbox Live Community Games. Gravsheep didn't sell very many copies, but then again it was a fine example of a "polished turd" in that the gameplay and graphics were lacking in several departments, but it was very well finished with a good UI, smooth transitions and intuitive controls. I spent a long time making sure it played nicely with the features of the dashboard and the 360 which are often overlooked by other XNA developers. I of course intend to do the same with Dysnomia, only this time I hope the gameplay will be present too.

Dysnomia represents a huge leap in my abilities as a hobbyist game developer. I've been developing games for years, but this is the first time I've really put maximum effort into every aspect of the game. In other words, I'm not taking the easy way out. Every obstacle I've come up against, I have defeated with research and code, rather than simplifying my vision, or coming up with a half-assed solution.

It's also the first time I've worked with an artist. Leon Arellano replied to an ad I posted on the XNA forums, and his art style immediately fit the bill. He also has the exact vision I have for the game, and readily understands tiling and formatting graphics to work in a game. A perfect partnership so far.

I began the Dysnomia project with the GameStateManagement sample. In Gravsheep, all the gamestate and transitions were done by hand I was very proud of it. My implementation was nowhere near as elegant as the one offered by the GameStateManagement sample, however. All developers that want to eventually release on Community Games should be using this sample as a base, or developing their own solution to handle menus, transitions, multiple controllers, live profiles and so on.

I then began looking at Nick Gravelyn's TileEngine tutorial. A brilliant set of videos indeed. After part 3 I was happy that my way of doing tiling and scrolling was the right way (though I had never thought of layering before), and Nick's sample very closely matched the way I would implement such an engine. I took his code as of Part 3 and began implementing and expanding it to suit my needs. I already had a tile editor from Gravsheep, so it was a case of simply extending that to handle multiple layers. Layering in a tile engine was all new to me - I have no idea why I hadn't ever thought of it before.

Next, things all got a bit mathematical. For collision detection and for doing some fake dynamic shadows on the "lights" I had placed down, I needed some trigonometry. I'm sure most of this stuff would be simple for A-level or further Math students, but for me it was quite a stretch and took me a while to work out!

Firstly, a function to work out the point on a circle. I've actually done this previously, so I wrote this one myself.

private static Vector2 PointOnCircle(ref Vector2 C, int R, int A)

{
A = A - 90;
float radA = MathHelper.ToRadians(A);
int endX = (int)(C.X + (R*(Math.Cos(radA))));
int endY = (int)(C.Y + (R*(Math.Sin(radA))));
return new Vector2(endX,endY);
}

I use this in collision detection to cast a point out in front of the player according to the player's angle of rotation. The tilemap is then checked for walls at that pixel location and if a wall tile is found, a per-pixel test finds out if a collision has actually occured. This per-pixel test uses the colour information of the sprite of the tile in question to allow for oddly-shaped walls.

private static bool PointInTriangle(Vector2 P, Vector2 A, Vector2 B, Vector2 C)
{
Vector2 v0 = C - A;
Vector2 v1 = B - A;
Vector2 v2 = P - A;

float dot00 = Vector2.Dot(v0,v0);
float dot01 = Vector2.Dot(v0, v1);
float dot02 = Vector2.Dot(v0, v2);
float dot11 = Vector2.Dot(v1, v1);
float dot12 = Vector2.Dot(v1, v2);

float invDenom = 1 / ((dot00 * dot11) - (dot01 * dot01));
float u = ((dot11 * dot02) - (dot01 * dot12)) * invDenom;
float v = ((dot00 * dot12) - (dot01 * dot02)) * invDenom;

return (u > 0) && (v > 0) && (u + v < 1);
}

I'm not even going to pretend to know what's going on here. I took these calculations from a maths site and converted them to C#. All I know is that it's using Normals to calculate whether a given point (P) is inside a triangle made up of three points (A,B,C clockwise). I use this to calculate the position of the player's shadow when he walks past a directional wall light. All that math for an effect that half the players won't even notice. That's what I mean by not taking shortcuts this time. If I understood how all this math worked, I'd be developing 3D games for a living.

private static float fAngleBetween(ref Vector2 vPointA, ref Vector2 vPointB)
{
float fAngle = (float)Math.Atan2((double)(vPointA.Y - vPointB.Y), (double)(vPointA.X - vPointB.X)) - MathHelper.ToRadians(90);
return fAngle;
}

This function calculates the angle between two vectors. I use this during enemy AI routines to cast out a ray between the enemy and the player to see if there's anything blocking the enemy's path. First of all I use this function to find the angle between the enemy and player, then use a series of collision checks using cocentric PointOnCircles, increasing the radius each time.

That brings me onto the last bit I want to talk about for now - the AI. A simple enemy chase/wander routine just wouldn't cut it for Dysnomia as the level layouts pretty much require aliens to be able to find their way to the player. After sitting and thinking about how to implement pathfinding behaviour, I decided to find out how the professionals do it. A* is one method, and is touted as being the most efficent method of pathfinding in games. I had heard of A* before, but didn't know it was an AI algorithm.

After reading and actually understanding the concept, I wanted to see if anyone had written a C# implementation of A* pathfinding. Sure enough, Roy Triesscheijn had everything I needed on his blog.

However, after implementing Roy's source and modifying it to work in Dysnomia, I found that trying to calculate paths for multiple enemies each update (or even every 50-100 updates) was too slow, especially as the paths became more complicated. I got around this by implementing a number of behaviours.

- Enemies have three AI states - Idle, Following and Pathfinding

- Enemies start out with an Idle state

- Every update:

- If the AI state is Idle, we check to see if there's a direct line of sight between the enemy and the player. If so, we set AI State to Following. If not, we calculate a path and set AI State to Pathfinding.

- If AI State is Following, move enemy toward player.

- If AI State is Pathfinding, move enemy to next node in the A* discovered path.

- AI Counter is incremented

- If AI Counter reaches 50, reset AI State to Idle

Using this method, the enemies will follow a set AI pattern for 50 updates before calculating a new path. We don't calculate a path if the enemy can head directly towards the player. There are also path length limits in place, so if the A* algorithm doesn't find a path fast enough the enemy AI state is set to follow the player. Whilst this means that enemies that are too far away will not be able to get to the player, it also allows the AI to run as smoothly as possible.

There's a lot more to talk about, but that'll do for a first update. Enjoy this video! :)

Lights Come On in Game 2

2009-05-23T17:38:00.002+01:00

That is all.

GravSheep Released!

2009-05-19T10:53:00.008+01:00

Team Mango's first release for Xbox Live Community Games, GravSheep, is now live and available to download and purchase in Community Games regions!

I'm exceedingly happy that the game is finally done and out there. Not only that, but things are definitely progressing at a hectic pace on Game 2 with some very promising concepts coming in from possible artists. The future is bright, the future is Mango!

You can find more information about GravSheep at the Team Mango website, and you can recommend the game at XBLCG.info by signing in with your Windows Live profile.

Team Mango Game 2

2009-05-18T12:06:00.005+01:00

Without giving too much away, I thought I'd post regular updates on progress of Team Mango's second game, which is currently untitled. This weekend I was chatting with a couple of artists interested in the project, and I began working on the very basic parts of the game engine (state management and tilemap drawing) and began extending the GravSheep editor to support the extra features Game 2 will have.

All of the tile graphics are extremely temporary (assuming I *do* find an artist) and just for use in getting the editor and engine up and running. I love this early part of development - the bit between a blank screen and the final 20%.

Retrobution Finished!

2009-05-15T13:05:00.005+01:00

...for now at least!

Finally put the finishing touches to Retrobution last weekend. Overall, I'm very happy that I now have a working arcade cabinet to play all those old classics on. I'm not 100% happy with the finished product. The wood paintwork could be better. The bezel didn't exactly paint too well on the perspex. There's still some bugs to iron out on the software side. And so on.

At some point in the future, I'll make a custom control panel with a built-in trackball and some admin buttons. Until then, I'm going to very much enjoy playing many classics this summer.

Team Mango - Games for Xbox Live Community Games

2009-05-07T15:51:00.012+01:00

Team Mango was the name of my teenage bedroom games programming team. We created a number of small Amiga games back in the late nineties. Nowadays, I am the sole remaining member of Team Mango (thus not really a Team anymore, I guess!). I have decided to release GravSheep, my first Xbox Live Community Games game, under the Team Mango monicker. I will most likely release any future games under the same name.

I've just launched the new Team Mango website in preparation for the launch of GravSheep, and I'm already designing Team Mango's second game and brushing up on my XNA skills to make development of Game 2 as smooth as possible.

If you're a budding 2D artist and fancy working with me in your spare time on future Xbox Live Community Games releases, please drop me a line at the same address.

A Very Musical Post

2009-05-01T13:43:00.005+01:00

At last, I can close off one of the projects on my Wacky Idea-o-meter! Origin: Unknown?, the first album from my band Puritan Slain has been released for FREE download. Overall, we're very happy with the final results. It's a culmination of the last three years of songwriting all wrapped up in one huge album that clocks in at 65 minutes.

If you had to push me for a favourite track from the album, I'd have to say it's the title track: Origin Unknown. There are many awesome songs on there though. Feel free to snap it up!

As well as the Origin: Unknown? release, I've just got back from a great weekend of music making arranged by one of my mainland-based friends, Dan. Five musicians each with their own taste in music got together on a farm in Dorset and spent three days writing, rehearsing and room-recording four songs. You can hear cleaned-up versions on SoundCloud and Last.fm, and can also see YouTube videos here.