Posts Tagged ‘ code ’

InterSceptre, a game 20 years in the making

InterSceptre is one of Leda Entertainment‘s pet projects, and has passed through several names and guises since the early 1990s. With a PC release on IndieCity imminent, and a possible XBox 360 release before Christmas, I wanted to look back over the development of the game from the earliest 16-bit incarnations through to the Windows Phone 7 release of the game earlier this year.

This slideshow requires JavaScript.

The original concept was for a futuristic bat-and-ball tennis style game, similar to Pong  but played on the vertical rather than horizontal axis (I’d never seen Pong; I assumed that it was played up-down rather than left-right partly because that’s how tennis is televised in the UK, and partly because I thought it would be too easy to defend a narrow gap with a wide space between the bats). The aim of the game is to get a shot past your opponent’s bat and off the screen. To make this more interesting, behind each player there is a row of blocks that first have to be destroyed (by hitting the bricks with shots) and then the winning shot fired through the gap presented. In that sense, InterSceptre borrows from two other classic games – Arkanoid and Breakout.

The concept proceeded through several generations, as I returned to it from time to time as my coding abilities improved and I learned more about the capabilities of STOS Basic:

1991: The first generation of the game was called Reflekt. The graphics were crude, the sprites moved in a jerky fashion and the collision detection was highly dodgy (shots often leapt through blocks undetected). Shots travelled in straight lines and were simply blocked, not even reflected – I probably didn’t get that far into writing the game before I was distracted by the next idea!

1992: You can’t keep a good idea down. I returned to the game the following year, and Reflekt II was born. It was one of the few games I actually completed writing on the ST, although there were a few bugs and crashes (Ben eventually ironed all of these out, and released the game as Reflexor, since no-one other than the two of us had ever heard of the original Reflekt). Reflekt II had bouncing shots and bonuses but not the centre bat or the white holes.

1995: InterSceptre (ST) was a game born from the STOS Missing Link extension, specifically the new Zones concept. Previous versions of the game had few large blocks behind the players which were too easy to get a shot through. With InterSceptre, it was possible to have many more and smaller blocks thus making the gameplay harder, and also freeing up space in the programming for more features: aliens and bonuses. The game was at least partially written in 68000 Assembler (I still have the collision detection code!)

InterSceptre on the ST was highly configurable; the user could turn on or off many of the game features (inertial control, centre bats, shot bounce, directional shots, black holes…) – features that survive into the XNA version of the game. InterSceptre was almost finished, but never released, on the ST (I think work was done to release a demo version of the game as Freeware…) InterSceptre (ST) had enemies that roamed the screen, getting in the way and destorying blocks, and it had black holes that swallowed shots – but no curving them round the screen.

It’s visibly the same game as the version released 16 years later. I was using alternate transparent and opaque pixels on the logo and the in-game drop shadows to try and create the illusion of translucency that is now so easy via alpha blending. Most remarkably of all perhaps is the visual difference between this version and the original Reflekt – how far I came in such a short time… and how little I’ve changed since!

2005: After writing ‘Get In The Ring‘ in C using DirectX for a university project, and some time fiddling with a platform concept game in C, I had a go at writing InterSceptre in C++ since I saw the possibilities OO would bring to games writing. Basic gameplay (bats and balls bouncing off each other and the environment, bricks being destroyed and the game won or lost) was working well and so I started porting the graphics over from the ST version. But I didn’t really get anywhere with it, and by late 2005 the project was effectively dead. Unfortunately no screenshots of this era exist; I don’t have a .exe of this version and so it lives in limbo. However, the game graphics from this version – the player bats, the game logo – were carried over unchanged into the PC and Windows Phone version, and the core code and class structure live on.

2010: When Ben reignited the desire for games writing by introducing me to XNA, I thought where better to start than with a game where I already had the code and the graphics? The core game classes were easily translated from C++ to C# over a few hours, and the game has evolved out from there, being significantly re-factored along the way as I got to learn XNA better. It’s been a fun proving ground for 2D games development, getting away from the old STOS limitations (how many sprites, how much processing).

Alpha channel work has been a revelation. About half the programming notes I have from the early PC days are about how I would go about doing lighting and transparency effects in a 256-colour restricted palette (since moving to 16 or 24-bit graphics would at the time have been too slow). Much of that is irrelevant now since I can use alpha-blending effects to effortlessly achieve something that was previously the result of a lot of mathematical heavy lifting (converting between the RGB and HSI colour spaces in order to reset pixel intensities), some of which even made it to code (that C-based platformer I referred to earlier).

Not the ‘droid I’m looking for

In my previous blog post, I talked about porting InterSceptre over to Android. I spent about 6 weeks on that project, but in the end I abandoned it and have started writing a new XNA game. I thought I’d write a quick blog explaining my reasons.

Reason 1: It’s just too hard!

Okay, honesty first. I thought porting to Android would be relatively easy. I’d need to write a simple lightweight implementation of the Microsoft XNA framework on top of the Android APIs – not too daunting since all I needed was sound, touch input, and 2D graphics. After that I could essentially copy and paste my source code, because Java and C# are syntactically quite similar.


Actually to code porting wasn’t too bad. There are some differences in the syntax, yes, but more problematic was the way Java and C# differ in pass-by-reference/pass-by-value. Java is consistent: it’s always pass-by-reference. C# isn’t, and that way lies a world of pain if buried in the logic of your code you’ve assigned a variable expecting it to clone & copy the values rather than just give you another pointer to the same structure.

Other issues that fall into the “separated by a common syntax” bracket include:

  • Need an instance of an enumeration to get all values
  • Construction: base/super, call order of member variables vs constructor
  • Java doesn’t initialise “primitive” classes (e.g. Boolean, Integer, Float)
  • for/foreach syntax
  • unqualified case values in switch statements
  • lack of Properties
  • Differences in getting the size of collection classes – size/length/count
  • No operator overloading
  • Different GC strategies (Dispose())

These are all fixable, but are a right PITA. Slightly harder to deal with are the fundamental differences between Android and XNA:

Emulation. The Android emulators are unusably slow. Basically the emulator is a Java application that is emulating a hardware device (virtual machine), which is running the Android OS, and on top of that is running a Java application (your code). That’s several layers of emulation deep. I was getting 1 frame every 5 seconds. The only way to develop is with a hardware device, which even if you have one available can be awkward.

Screen sizes! Even relatively recent high-end Android devices have screen sizes smaller than the Windows Phone standard 800×480. This can be devastating if your games graphics are pre-rendered to fit that size. The biggest problem I’d have with InterSceptre would be fitting all of the options on the options screen, with the specially crafted text font I was using (note to self: use SpriteFont from now on). The in-game could adapt to smaller screen sizes, but I didn’t bother – in the end I settled for dynamically scaling the graphics so that the screen throught it was 800×480 but the rendering shrunk what was actually drawn.

But this really is symptomatic of a wider problem with Android – no standardisation. You can’t rely on anything. Sample Android game code that you’ll read on the ‘net is riddled with per-device exceptions and work-arounds. That’s insane, for a developer it’s a support nightmare having to keep releasing emergency per-device peculiarity patches for your games as they arise. Life’s too short to have to worry about that kind of nonsense.

Threading. Not hard, but you have to keep threading in mind in Android, lest your draw and update code clash over access to anything and you find yourself crashing out because of a ConcurrentModificationException. Very easy to do if, say, you’re adding to a list at the same time another thread is iterating through it.

Android alpha blending is XNA 3.1 style not XNA 4 style. In the move from 3.1 to 4, XNA changed from unmultiplied to premultipled colour values… or maybe the other way around, I could never get my head around it. Anyway, Android graphics still expect the old XNA 3 style colour values. So if like InterSceptre your game relies heavily on colourised special effects, you’re going to have to adapt an awful lot of code.

Vector maths. Android doesn’t have any. No, I couldn’t believe it either.

But the biggest issue for me by far was Canvas vs OpenGL 2D Graphics. The first 3 weeks I spent on the InterSceptre port, I was using simple Canvas.drawBitmap() calls to copy pieces of screen around. Once I’d fought my way through understanding the Paint and PorterDuff classes this worked fairly well; unfortunately InterSceptre performs a lot of screen copy operations per screen refresh, and as a result I was hitting the performance limits at about 10 frames per second – simply not fast enough for an action game like InterSceptre.

So, I ripped all the graphics code out (from my mock SpriteBatch class) and re-implemented it in OpenGL. This brought its very own challenges. There are no beginner’s guide to 2D OpenGL graphics tutorials anywhere, again you’re relying of scraping knowledge from someone else’s project. Noddy game samples all use Canvas of course, so if you need OpenGL you’re looking at a complex game such as Replica Island, and good luck understanding that if you have no idea how either Android or OpenGL actually work. OpenGL itself is a much lower level of coding than you use in XNA; it’s a set of arcane instructions to the graphics processor, and heaven help you if you can’t understand the gibberish you have to type in, or issue the commands in the wrong order. If something doesn’t work, you haven’t got a prayer of working out why.

OpenGL textures have to be exact powers of two wide and tall. No, I have no idea why this can’t be abstracted away from you. And there’s no easy way to change the size of a texture in memory before passing it over to OpenGL either, I had to resize all the graphics on disk, adding hugely and uselessly to my application size. Why?

But I persevered, asking lots of stupid questions on StackOverflow, and eventually got InterSceptre running in OpenGL. I had just 2 problems:

  1. I couldn’t use the same trick I did with Canvas, drawing everything fullsize to an offscreen 800×480 buffer then scaling that to the actual screen. OpenGL insists that offscreen buffers are no larger than the actual screen. This meant I had to draw each graphic scaled individually, and lost the nice antialisaing effect of just doing one big resize at the end. As a result, the game looked terrible – particularly the font, which suffered badly from artefacts
  2. It still wasn’t fast enough, I was only reaching 20 frames per second. On WP7 InterSceptre sits at 30fps with no problem at all.

Even then I probably would have continued, but when I couldn’t get sound effects and music to work either, despite following 2 separate examples that used 2 different sound APIs, I basically lost interest in Android completely. But while I’d been working on it, other issues had come to my attention that probably would have stopped me even if I was being successful:

Reason 2: Cheapskates.

Anecdotal evidence would seem to suggest that sales figures for independent games are just as bad on Android as they are on Windows Phone. There’s so much free stuff on Android that that’s what people expect, and so no-one wants to pay for anything, unless it’s from a big-name studio or franchise. So what exactly am I putting all this effort in for?

Reason 3: Long-term future of the platform

Android may be becoming the dominant mobile phone platform, but it is under threat from patent wars and the possibility of the Linux license being withdrawn. Google seems to have panic-bought Motorola to head off some of these issues. But things are so unstable at the moment, I’d rather steer clear!

Reason 4: Lack of Governance

The Android app market is riddled with malware as Google doesn’t seem to perform even basic checks about what an application is doing, unlike Microsoft (and Apple) who take a very close look. Will users continue to trust the platform, or will they defect to iPhone… or Windows Phone?

– – –

So… those are my reasons. I’m an XNA-only developer again, writing games for release on Windows Phone, XBox and Steam. It’s an exciting tiome to be a wp7dev and I’m looking forward to the ride!

The aftermath

Download InterSceptre from the Marketplace now!

Download InterSceptre from the Marketplace now!

So, InterSceptre has been published for over a month now – what’s been going on?

A lot has happened since I last wrote. Ben and I put some work into creating a press pack for our games, and Ben produced a brilliant promotional video to put on YouTube. We approached and were publicised in some of the major Windows Phone 7 blogs such as WPCentral, BestWP7Games, WP7Lab, and the XNAUK User Group. We also got some bad publicity, but maybe no publicity is truly bad as it caused a spike in interest, and more importantly gave birth to Ben’s new project: TrollWhacker.

Ben and I also had a good session at the London-based Windows Phone User Group, where we presented our efforts, and feedback from those guys helped refine the latest update to InterSceptre with improved feedback options, particularly an in-app suggestion to rate the game.

The publishing process itself has proved somewhat frustrating… it takes several days for each update to be tested and made available for review, and you have to be very careful how you actually release the game; publishing from the main menu (rather than the individual project page) can cause delays.

A few weeks in, and the results are disappointing. At the time of writing InterSceptre has had just 10 paid downloads, which is not a lot to show for a year’s work. However, the latest update also opened it up for trial mode, and so the game itself has been downloaded 43 times. More rewarding than the paid downloads is seeing the reviews come in. After that first initial bad review, InterSceptre was updated with better alternative controls and a nicer looking front page, which seems to have gone down well in the marketplace (the user who posted the scathing initial 1* review updating it to 3*, and several more positive reviews have followed from a worldwide audience).

Are these the ‘droids I’m looking for?

This left me in a bit of a quandry. Was it InterSceptre itself that wasn’t liked? Or is this all that can be expected of the Windows Phone platform? It is after all a much smaller target audience than the other platforms. Releasing a different game for WP7 would not be a controlled experiment, and therefore I decided to try porting InterSceptre to Android. Since then, I’ve been in contact with other developers who have similar poor sales figures, so I feel vindicated in this approach. Maybe if I ever make $99, I’ll consider porting to iOS…

Fortunately I could already code in Java, and it’s not radically different from C# in any case. It’s basically a case of finding out what the equivalent “hooks” are (how to draw on the screen, read the input devices, and play sounds) and watch out for the gotchas. I’ve been building a mock XNA framework to help me move XNA projects over to Android without too much reworking… most of my class hierarchy already abstracts away from XNA anyway, but the base levels of that needed some replumbing. You also need to take care as Android is multi-threaded, which can raise some unexpected issues for the unwary.

Android development is frustrating. The emulator is slow. As in a frame every 5 seconds slow. That’s because it’s written in Java, and is emulating an entire hardware device from the BIOS up through the Android OS stack, and then running Java on top. It’s several layers of emulation deep. This makes developing a game almost impossible without access to a physical device. Fortunately there is no “unlocking” required, unlike for Windows Phones, so you can test before handing your cash ($25) over to Google to get a developer account. But even on the device itself, InterSceptre is getting a disappointing 10fps or so, compared to 30+ on the Windows Phone. This significantly affects the gameplay.

The other issue you have to be aware of is that Android phones all have different screen sizes, unlike Windows Phones which are all 800×480. Android phones mostly have smaller screens too – typically 400×240, or smaller. This is a problem if your game, like mine, is full of pre-rendered graphics, and particularly pre-rendered text, that wants to be a certain size. You have to do all your own resizing and rescaling at run time, or rewrite everything. InterSceptre’s main game can adjust to the screen size available, but the title screen and options pages needed to be dynamically rescaled at draw-time… which also raises interesting issues around touch mapping because nothing is actually where your original code drew it 😉

So it’s been an adventure. I hope to have the Android port done before the holidays – I’ve got another 4 weeks or so – so that when I next go to the XNA UK User Group at the start of September, I’ll be there not just as a published WP7 games developer, but as a published Android developer too.

Maybe if I keep saying that, I’ll start believing it. I’m a published games developer. Nah, still not sunk in yet.

Standby for launch!

The coding is complete. All the game artwork is finished. Game music (courtesy of Ken MacLeod) has been added, the final screenshots taken, and everything has been uploaded to the App Hub ready for publishing. We just need to sort out all the boring tax details with the IRS before we can actually get paid, but the actual development is all done. Just need to wait for AstroSwag’s web upload to be finalised, and then we can go for the joint launch.

While you’re waiting to buy your copy from the Marketplace, check out these final screenshots!

This slideshow requires JavaScript.

All over, bar the shouting

I’ve used the word “finished” to describe InterSceptre quite a lot this year, but this time I almost mean it. I need to add some music for the title screen and in-game, and then it’s done. Release is now scheduled for the start of June, in time for the next XNA UK User Group meeting.

Several rounds of testing through the XNA UK XAP Test Service have ironed out the bugs and issues; I’ve taken much of their feedback on board – but not everything. Some stuff I don’t think is in keeping with the game’s feel. I’m sure they’ll be proven right.

I’ve done a lot of work on the game’s AI recently; it was too easy to beat. Now the different levels of AI player have different capabilities and strategies, rather than just faster reaction times. There’s loads more I could do here, but I think it’s good enough to release. Maybe if I ever revisit the game later, I’ll do more. There’s loads of scope for machine learning here, a personal hobby of mine, but let’s move on.

I’ve also added some different backgrounds. The main niggle left from the beta test team is around the backgrounds. What do you think?

InterSceptre, One Year On

It’s been practically a year since I started developing InterSceptre in XNA, albeit based on a version I wrote in 2005 in C++ for DirectX 9. Snatching a bit of time on the train here, the odd evening there, I can finally see the finish line. From here it’s just housekeeping – sound, tombstoning, maybe some bonuses – and it’s done. Thanks to Ben and the guys at the XNA UK User Group for giving me the incentive to finish this one rather than just move onto the next (if you’ve heard the one about the engineer, the physicist and the mathematician – well, I’m the mathematician – when I can see the end is in sight, I’m tempted to move on to the next problem).

Work were able to offer me a Windows Phone 7 to test development on, which has been unimaginably helpful and improved the playability of the game no end. There’s nothing quite like seeing the game running on a piece of hardware to spur you on. So the last month has been quite productive. Since the last development update:

  • dual deployment – for Windows & XBox in one project and for WinPhone7 in the other – same code base, same content
  • the menu system has been upgraded to draw button-boxes around the options. This was needed in order for the menus to be usable on the phone. Lots of engineering under the hood to create hot-zones as click-targets, make the text appropriately centred, and so on
  • Added a “brick burst” explosion at the end of each round
  • Various improvements due to more experience with C# (such as Dictionary rather than Hashtable, Properties rather than getters/setters)
  • All movement and positioning code reworked to use Vectors rather than integer co-ordinates
  • Ripped out all frame counting for animation and movement, and replaced with proper GameTime controlled calculations
  • Addition of game effects – shadows, glow-balls – using Textures drawn in the code rather than pre-created as PNGs
  • Reworked title screen sequence

A lot going on. My aim is to demonstrate where I’m up to at next weeks’ XNA UK User Group meeting, garner one last round of feedback, with the aim of having InterSceptre ready to publish at the end of April – or, at least, the first public version of it. No doubt I’ll continue to tinker with it as time goes on, but the call of future projects is becoming too strong…


Dreaming… visions of you…

A few things have happened games-wise recently and I feel a bit on a high at the moment – InterSceptre looks like it might actually get finished; I had a great Code Jam with Ben; met a random stranger on the train home one drunken night who turned out to work for Packt Publishing and we had a good chat about the state of the mobile games market, and I got an evaluation copy of their XNA Beginner’s Guide book! (I will review that separately when I finish it).

Last, but most importantly, I had a great night at the XNA-UK meet last night! It inspired me in several ways.

Firstly I’d like to thank all of the members, but particularly Ed, Charles and Simon, for making me feel so welcome. The stuff demonstrated yesterday was brilliant, particularly the post-processing pixel shading special effects stuff.

Also, Ben has been nagging me about using particle systems to add a bit of razzamatazz to my games development work.

I can see the potential, and it excites me.

But not for InterSceptre.

Far be it for me, an engineer, to go off on a rant about how that would ruin my project’s artistic integrity and vision… but I think there’s an element of that in it. InterSceptre is deliberately retro, partly because those are the kinds of games I love, partly because that’s currently the limit of my ability. I think adding pixel shaders and particle effects to InterSceptre now would cause me to want to revamp the entire graphics stack of the game (I’m already imagining a “frosted glass” effect, rather than just dimming the screen, when a dialog box pops up). But, apart from anything else, that would kill InterSceptre for the Windows Phone 7, which doesn’t support pixel shaders.

Besides, I want to move on to the next project! if I keep adding new stuff to this game, I’ll never write the next one. Maybe one day I’ll come back to InterSceptre and put a bit of sparkle on it. But for now, InterSceptre has become the game I wanted it to be back in the mid 1990s, but lacked the talent, staying power, and CPU horsepower to make reality. So I’m happy that it is now everything it should be. Anything excessively funky I add into it just won’t fit. New techniques need a new game to live in.

So after I finish i-dotting and t-crossing, I’m going to take a short time to write something quick-and-dirty for the phone. I have a Bejewelled-style puzzler in mind, and I’m letting those ideas bubble away while I finish InterSceptre.

All the real funky stuff, I’m keeping back for my puzzle-platform game. I might allow myself to do some simple prep work for that in the coming weeks, but only if I think it won’t distract me.