Featured Post


It’s been a while since I posted anything to the blog as I tend to use Twitter these days for gamesy stuff but I thought I’d recap exactly what I’ve been doing these past few months in Pumpkin Land. I’ve been keeping busy converting various bits n bobs of Java, frameworks and...

Read More

Doppelganger for Windows!

Posted by Paul | Posted in Doppelganger | Posted on 21-08-2013


I’ve just released the latest version of Doppelganger for Windows. When I say ‘latest’, I mean the donkey’s years old version that was up on XBLIG about 5 years ago!

The solution was just sitting on my hard drive, rotting away, so I thought why not. Bring the code up to XNA v4 and bung it up on the site.

It was the first thing I ever wrote in XNA GameStudio – it took about 10 weeks to make, while learning the framework, coding business apps all day and juggling two kids at night. The code is bad- very bad. The graphics, really, really, programmery. Sound is meh (apart from the music I bought in which is pretty cool) but I LOVES it. It owes a MASSIVE debt to Defender and there’s obviously the whole dual worlds of Iridis Alpha going on too. I’m resisting the temptation to add more particles and baddies and weapons as I’ll probably end up breaking it and I don’t think I could stomach the code for too long anyways :-)  (but then I look at the awesome Ultratron update that Cas did and I get all twitchy for a while).

The plan is hopefully to use MonoGame to bring it to Linux, Windows 8 and Mac in between doing other stuff.

It supports Xbox 360 gamepads and may need some perf tweaking if you have an older machine (as the code, is really, really bad).

Titan Attacks is DONE!

Posted by Paul | Posted in Code, Puppy Games, XBLIG, XNA | Posted on 15-06-2013


Yup, that’s right – finally in a fit enough state to submit to playtesting over at the XBLIG forum.

If I remember correctly I think I started this chunk of work around Nov 2012 but that entailed converting LWJGLApplets first before I could begin on the Titan code.

Am I happy with it after all the grief and agro of the past 6 months or so? Pretty much as a project goes I guess. The game itself is near identical to the Java / Desktop original – you’d have to run them side by side to have any chance of spotting the slight differences and even then I reckon you wouldn’t really tell. So game wise, yeah, all is good.

The CRT shader is rewritten from scratch – the converted code worked perfectly on Windows but wouldn’t distort correctly on the console – I spent some time trying to fix it, checking texture and render target formats were correct and everything seemed ok, but no, broken. That annoyed me a little :-)

Object pools – boo! I broke the game a few times implementing poolable entities but it was a case of do it or be a slave to the GC every 5 seconds or so – *yikes*.

I had to trim some of the particle effects on later levels as the Xbox really struggled with > 1000 sprites. Again, you can’t really notice any difference. And a new collision detection system was required.

The code-base is hacked more than I would have liked in an ideal world. Public fields sprouted up EVERYWHERE along with the pool changes mentioned above, it just makes things a little nasty. A player is never going to know or care but it’s just a little grating for me the developer :-)

Storage had a rewrite at the eleventh hour – I utilised the excellent SharpFileSystem to get me out of a widening hole. And I used a nice thread pool (by KiloWatt who I think is jwatte over in XBLIG land) to alleviate IO stalls.

There’s the very occasional stutter caused by the JIT code generator which I can just about live with in my old age. Garbage is tamed mostly – I still generate some but not enough to cause problems during gameplay and then I can collect in the Shop so no glitches in game unless you played a level for about 10 minutes or so (most levels are over within a couple of minutes)

So I’m done – unless playtesting throws up anything nasty, I can submit to release in the next couple of weeks.

And my reward for finally getting it done? Feet up, chilling with friends? A beer or two? Watch a movie? Nope, I downloaded the latest  Ultratron source changes…..

Titan Attacks 4 Titan Attacks 3 Titan Attacks 1


Converting Java is Fun!

Posted by Paul | Posted in Uncategorized | Posted on 30-11-2012


The same way I find running fun! It hurts a lot while I’m doing it and I’m glad when it’s over but there’s a certain satisfaction followed by a warm glow after.

I first dabbled with the whole Java/C#/Puppy/Pumpkin conversion thing about 5 years ago now I think, just after the release of XNA Game Studio 1.0. Being a jobbing C# developer it sounded great to be able to use the same language to write cool games. I’d spent a short time with the fledgling game library and already converted my existing C++ engine to it and developed my first XNA game, Doppelganger.

Around this time I’d been playing a fair bit of Droid Assault and thought how cool it would be to get it on the Xbox and after a bit of back ‘n’ forth with Cas, it was decided I’d convert the games as is – no new art and minimal design changes – cheap as chips basically. Even at this early stage we didn’t think XBLIG would be a massive success financially so we went for quick and dirty.

So, there I was, eagerly hitting refresh on the Send/Receive email button in Outlook when the email from Cas arrived. Yay, I though, then “Ultratron source code” hit me. Now I liked Ultratron, but it was no Droid Assault, bah, I though! But Cas was right. It was a MUCH simpler game and would be MUCH easier to convert. It would be the perfect test case and hopefully we’d hit the launch of XBLIG too.

Reading through the code it was obvious there were a few support libraries that the game used – namely, LWJGL, SPGL, LWJGLApplets. Hmm, that’s a fair bit of code there, I thought. And as I began trying to get a handle on the way it all fit together I got a bit despondent. And, converting the cool little game suddenly became a much larger project.

But then I had an epiphany! I’d already got a game engine, written in C#, using XNA Game Studio, targeting the XBox. Let’s face it, Ultratron is a simple game – it’s Robotron with knobs on – what would we need? Entity system? Got one. Menus? Those too. Particles and effects? Yup, all in the Doppelganger engine. XML parsing – close enough. So I had a plan – I would extract all the data from the XML scripts, the entity behaviour from the Ultratron code, bolt my menu on, tweak the particles and add the XNA specific bits like Controllers and Profiles the the Xbox audience would expect.

Conversion was rapid. My engine was pretty basic but it had all the guts required and the only thing I had to change was the collision detection as the Xbox CPU choked a bit on the exiting approach. Around this time I was preparing to emigrate to New Zealand so things were mad but I completed the conversion a few days after XBLIG went live. The game received some fairly good reviews (2nd I think in Retro Remakes early round up of the service) as well as some (valid) criticism – folks missed the Puppy menu system and some would have liked a super duper HD widescreen version. It sold shockingly however – I think we split a cheque for a couple hundred dollars early on and that was about it for it.

But I’d got the bug and after tidying up a few things in a couple of updates (including new Menu) I was eager to get my hands on the Droid Assault code. Eventually, the email came through! “Titan Attacks source code”, bah * 2. BUT, it was mostly more of the same and again much simpler than Droid. I followed the same process as for Ultratron but this time things didn’t go as smooth. I struggled a bit with some of the code features of Java, I couldn’t get the sprites to draw in the correct locations (stupid hotspots), Titan was my least favourite of the Puppy games so enthusiasm dipped a bit and then my world turned upside down MASSIVELY and development stalled. Titan was pretty much dead in the water. It was maybe 85% done but I’d got zero time to dedicate to it and even less desire.

But the life changing event didn’t last forever and eventually (maybe a year?) I had some time to kick things off again. And what do you know Microsoft go and announce a Dream Build Play competition and Cas is up for Droid Assault as our entry. The stars align and I’ve got the code mojo back so I begin the conversion…

…it’s a disaster. The code just doesn’t fit my engine. I introduce too many bugs during the conversion and I’m gutted. I’d been waiting to convert this game for ages and then I go and bugger it up?  I wasn’t totally beaten yet though – I loved the game too much to give up and I wanted to give it a real go. So I went at SPGL and LWJGL with an XNA sized lump hammer. The code was rough and hacky and I had to change a lot of the syntax (but not as before, the behaviour) and blimey Charlie I’d got them into some sort of compilable assembly. This was probably about 2 years ago so details are a bit fuzzy and I’ve no idea how long it took but, there it was, a little droid, doing his little animation dance on the screen – he was upside down and in the wrong place but I didn’t care.  A sprite, on screen, using SPGL, LWJGLApplets and Droid Assault code. I finally fixed the sprite positioning bug and even wrote some Java utils that wrote the map data into a format I could use. And by some miracle, I got maybe 95% of it converted. There was some work to do with the controls but it ran and you could play it and transfer and shoot stuff and…..it sucked on the Xbox. Like 1 or 2 FPS sucked.

“Garbage, that is”, I confidently predicted but it wasn’t. Method call overhead in the sprite engine maybe? – I made public fields EVERYWHERE. Better, but still not good enough. The first ten levels were playable but not much more – I posted some images on Twitter and even upload a YouTube vid but something was rotten in the core of it. Eventually I tracked it down to the enemy droid AI and the map renderer!! I came up with various changes to both systems but nothing worked well enough to get it performing acceptably. I submitted the 10 level demo to the comp but didn’t hear anything back from Microsoft – I showed it at GameCityNights in Nottingham and folks liked it but I wasn’t happy with. It needed MAJOR work, most probably a rewrite of the offending systems and I was totally burnt out. I spoke to Cas about a few ideas but Revenge of the Titans was nearing release and things were about to go mental there so Droid kind of got put on the back burner.

At this point, the scoreline read success 1 – 2 failure. Boooo!

After a period of recuperation of about 3 – 4 months I’d got the bug again – I found the  Titan Attacks source code snapshot, ran the new Java Conversion Monkey tool at it and had the lot converted in 3 days! 3 days, part time, the entire game. And it worked. The work that went into the Droid converison had finally paid off – I posted a tweet – and then BAM! Cas replies, “We’ve just given Titan a massive widescreen overhaul – with HD graphics” – none of it compatible with the engine stuff I’d done. “Never mind”, he says, “check out this Android version. What about doing that?”.

So, I started again. With AndroidSPGL – And I did it all. Properly this time – no XNA hacks in there. I did bits of Java, LWJGL and all the resource loading tools. It was hard work, late nights, head scratching but I reckon about 2 months or so and I’d got it done. I did the test harness too and got it running in the iPad emulator – I did a Windows Phone 7 version for kicks – it all just worked now.

Score most definitely 2-2 I thnk :-)

I just needed an AndroidLWJGLApplets now but it never came. Revenge of the Titans took off on Steam, rather well, in fact and Cas was swamped with that. And then life gets in the way for me again and I have to cope with that for about 4 months again.

Things are a bit messy so I reassess:

- Ultratron - done
- Titan Attacks (pre-widescreen) – done – uses hacked XNA version of SPGL / LWGL
- Titan Attacks (post-widescreen) – some done - uses hacked XNA version of SPGL / LWGL
- Droid Assault – 95% done with crippling performance problems - uses hacked XNA version of SPGL / LWGL
- AndroidSPGL - done (for iOS / Windows Phone 7)
- AndroidTools – done (for iOS / Windows Phone 7)

What was missing? – there’s desktop SPGL and desktop LWJGLApplets - hmm, I’d already done a bunch of SPGL work for Android and a bunch of ‘hacked’ LWJGLApplets work for DA and TA. So I set about doing the full desktop versions of the Puppy libs using MonoGame - no XNA style hacks – properly this time, like the Android version.

And they are pretty much done…

SPGL 100%, LWJGLApplets is being tested right now. Just need to do the glue layer that sticks a Puppy game to a MonoGame game and add sound back in. Then, I can get the latest Titan Attacks code (it’s had some updates recently) and run the conversion monkey over it!

Phew, it’s been quite a ride!


What the dickens is a LWJGL?

Posted by Paul | Posted in Code, Droid Assault, Puppy Games, Ultratron, Uncategorized, XBLIG, XNA | Posted on 30-11-2012


I’ve been Tweeting quite a bit recently about the various libraries and frameworks I’m converting from Java to C# and I’m aware the posts are probably pretty meaningless to all but a few select developer chums.  So, in an attempt to enlighten the rest of the Pumpkin followers, here’s the low-down on the main players involved.

LWJGL – The Lightweight Java Game Library is an open source Java software library for computer game developers. It exposes common libraries like OpenGL, OpenAL, etc in a speedy, lightweight manner to the Java crowd. Cas Prince (@puppygames) was the original author. It powers all the Puppy games, Project Zomboid and Minecraft to name a few.

I’ve converted the graphical primitives like Color, Rectangle, Vector (and whatever interfaces they implement) as is – they are reference types and take precedent over the XNA equivalents. The input classes; Mouse, Controller and Keyboard are done too and they just delegate to their XNA namesakes.

SPGL – The Shaven Puppy Game Library, is a layer that sits on top of LWJGL. It’s got a sprite engine, sound players, resources live here (fonts, paletes, etc) a bunch of animation commands and some OpenGL and OpenAL stuff. There’s some nice ‘rich text’ classes GLStyledText, GLTextArea for use by the GUI.

It also contains the resource loader / converter which takes a bunch of XML and creates fully working (Java/C#) objects from definitions in the mark up:


The following XML snippet would create a GLTexture resource and an ImageBank resource at run time (or build time if you prefer)

<texture name="solid_background.texture" url="solid_background" dst="GL_RGBA" 
target="GL_TEXTURE_2D" min="GL_LINEAR" mag="GL_LINEAR" wrap="false" />

<imagebank name="background.imagebank" texture="background.texture">
  <spriteimage name="spriteimage.bg_bottom_left" x="0" y="0" w="10" h="12" hx="0" hy="0" />
  <spriteimage name="spriteimage.bg_bottom" x="10" y="0" w="42" h="12" hx="0" hy="0" />

Cool eh?! The similarities between Java and C# made this a breeze really which was a godsend as this is probably the core task when converting the Puppy stuff.

The sprite render uses XNA’s DrawIndexedPrimitives with dynamic Vertex and Index buffers. The Java renderer is a big array of floats so I created a corresponding VertexDeclaration and just blat whatever the sprite engine throws at it. Cas removed all (*most?*) of the immediate mode glVertexX OpenGL calls so there’s all sort of goodness going on here, with batching and buffers galore as sprites and arbitrary geometry all live happily together. There were a few glTranslates, glPush/PopMatrix calls left so I just created a GL wrapper object and mimicked the OpenGL matrix stacks (e.g glPushMatrix() becomes GL.PushMatrix()). The AndroidSPGL library I converted last year used OpenTK on the C# side but my new GL wrapper keeps the call parameters the same data types as OpenGL (public const int GL_TEXTURE_2D instead of All.Texture2D type enums)

LWJGLApplets - Next in the chain, this is the GUI and effects layer and is where the particle emitters live and all the widgets you’d need for a user interface. It contains a stack of Screens so you can navigate through the game; Title Screen, Options, High Scores, all the usual basic stuff. Games can subclass these screens to add features and obviously define brand new screens.

Java – I decided to convert bits ‘n’ bobs to aid the conversion process. So when SPGL needs a ByteBuffer I just use my C# implementation of it instead of changing the SPGL source code. Most of java.nio is done and some other misc stuff like Integer.parseInt but I stopped half way through java.io and now I just use .Net collections instead – with added extension methods if required to match the Java behavious (e.g. HashMap.put(xxx) -> Dictionary.put(xxx) extension method). Extension methods help massively in getting to that glorious ‘Build Succeeded’ message in Visual Studio but if after profiling all the wrapping hurts performance then the source code is changed to a native class / call.

The Java Conversion Monkey – this is an automated conversion Windows Forms tool I knocked up to aid the entire process. You point it at a folder containing Java files, give it a destination folder and out pops a corresponding .cs file with beautiful C# code.

It’s a pretty brute force approach; each file has a series of FileProcessors perform conversion work on it in order – I’ve got NamespaceProcessor, FindAndReplaceProcessor, RegExProcessor, plus about 5 or 6 more that I forget now. It helps greatly in the process but there’s still a fair bit of manual fix ups to be done. A special mention here to Resharper too as it flags all the code errors like ‘you need override here’ or ‘this methods hide blah in the base class’.

So what are the main problems converting a bunch of Java libs to C#? Sound normally gets left until last and I usually do a few iterations until I’m happy with it. Stupid Java interfaces with their fields definitions – anonymous classes, blergh. I tend to create a concrete implementation here and add some delegates. But the worst annoyance by far is Binary Serialization. Simple to convert in theory but it’s a major PITA (and is something I will be leaving until the very end). Compact framework doesn’t have a binary serializer,  can’t reflect over private fields on the Phone. Once you add some custom serialization, the built-in mechanism gives up and it’s custom all the way. Java uses an Interface to tag classes as serializable, .Net a [Serializable] Attribute. However, I still need the Java Serializable interface as some of the SPGL functions require a serializable object. But then I need to implement .Net’s ISerializable too. This is what I currently end up with..

public class SomeClass : Whatever, Java.io.Serializable, System.Runtime.Serialization.ISerializable {

hmm, it all gets a little bit messy and confusing :-)

That’s about the bulk of it. The ultimate goal is to convert Puppy Games’ titles to Xbox, iOS, PS Vita, Window 8 Phone, Surface with the minimum amount of fuss and  impact on the actual game code.

Java – done. LWJGL – done. SPGL – done (And the Android version). LWJGLApplets – in testing.

Titan Attacks – COMING SOON!



Posted by Paul | Posted in Code, Puppy Games, XBLIG, XNA | Posted on 25-12-2011


It’s been a while since I posted anything to the blog as I tend to use Twitter these days for gamesy stuff but I thought I’d recap exactly what I’ve been doing these past few months in Pumpkin Land.

I’ve been keeping busy converting various bits n bobs of Java, frameworks and libraries to C#, in an attempt to release some of the awesome games from Puppy Games on the iPhone via the awesomeness that is Mono / Mono Touch.

I’ve worked with the Puppy guys in the past, bringing Ultratron to the Xbox 360 via XBLIG / XNA Games Studio and entering a Droid Assault WIP to the 2011 Dream Build Play contest (we didn’t win).

Previously, I’d used a hybrid approach when dealing with the Puppy code in XNA. A bit of their stuff, a bit of mine, the Content Pipeline, etc, in a mash up of conflicting styles and designs goals. And while this worked, it involved a fair amount of hacking, bug hunts and lots of head scratching trying to fit square puppies in round, pumpkin shaped holes.

So, this time would be different! I’d convert the whole Shaven Puppy Games Library (SPGL), their support tools, their reflection based resource loaders, their GUI, the lot! Oh, and therefore any bits from The Lightweight Java Game Library (LWJGL) that the Puppy engine utilised. It would be a fairly complex conversion but ultimately make converting the games much, much easier.

I started sometime in October, maybe the 14th and by mid December I was done. A minimal SPGL proof of concept app running in the iPhone simulator on my brand new shiny MacBook Pro. Sprites, music, SFX, arbitrary geometry, text, touch all present and correct.

The actually journey from Java source to running appplication wasn’t too bad. A few folks commented that it should be a breeze to convert to C# due to the similarity of the languages, and while mostly right, there were a few bumps along the way.

Firstly, I ‘needed’ a new Mac. Mine was old and slow and the keys were silver instead of the new flat black ones and, ok then, I just wanted a new one. Then I had to set up the Mono environment which was quite difficult for someone that bootcamped Windows pretty much exclusively on the old one. Where do the libraries go? Ah, Nant is compiled with MCS and I want a v4 compler so I need DMCS, blah, blah, blah. I shouldn’t complain though as without Mono none of this would be possible. And it really is an outstanding piece of work created by magic, pixie dust and lots of hard graft by the folks at Xamarin

Next was down to a combination of too many late nights and grand incompetence on my part. Trying to run my Mono code on the iPhone. That’s desktop code. On the iPhone. What was I thinking!? Once I realised what I fool I’d been I created some Mono Touch solutions, referenced the correct framework libs and we were good to go.

Then there was all the Java bits ‘missing’ from C# that I needed to either duplicate or rewrite. I chose to duplicate and spent some time in java.nio, java.io etc dragging more and more bits of core functionality in until finally drawing a line, adding some NotImplemented exceptions and commenting out some stuff that probably will never be called anyway.

Generics are different. A bit of head scratching there. Annotations / Attributes close enough to hack around a solution (no generic attributes allowed in .Net). Reflection pretty much the same really just different keywords so I either added extension methods or changed the source code to be more Dot Netified. Default scope rules are different, no biggie though. Checked exceptions – gone. Iterators to foreach mostly ok (except for list modifications while traversing) and probably a few others that I forget now.

I must thank Cas Prince for putting up with me hassling him late at night on Skype about Java syntax or functions or why my sprites aren’t showing / are the wrong colour!

So there we are. All ready to go in the new year, hopefully with some cool games for desktops, mobiles and tablets. Cas will do the Java side and I’ll port to iOS.

Merry Christmas.

PS – I’ve also got a Windows Phone 7 / Xbox ports done now too. Happy days :-)

Pumpkin Games at GameCityNights

Posted by Paul | Posted in Uncategorized | Posted on 29-04-2011


I attended GameCityNights yesterday.


Stuart Gilray from Just Add Water was there doing the one on one, describing how he got into the industry and showing some of the new Stranger’s Wrath HD artwork, which looked pretty.  There was a live video interview with Lorne Lanning of Oddworld fame which was thoroughly entertaining; touching on socially designed games and why he believes classic games can stand the test of time just as well as classic movies. And a section on Second Life that was highly amusing by (I think) a fella called Paul Butler.

They also showcase indie games there which is the main reason I attended. I must thank Bob Fearon for putting my name forward and Chris White for making it happen.  There are usually 3 or 4 screens available to indie devs so I took my Xbox and demoed Doppelganger and the latest WIP build of Droid Assault. It was fascinating seeing other people experience the games for the first time and try and learn the mechanics (by trial and error – not a SINGLE person read the ‘how to play’ screens, not one).

It quickly became apparent that Droid will require some kind of tutorial – without reading the instructions (or having me direct their actions) players simply attempted to kill all the bots without using the transfer mechanism to build a team. Some players struggled with the twin stick control too so my intention to add a few different methods was vindicated.

So, all in all, it was a really enjoyable evening – a few beers, a decent chicken curry, some interesting chat and I got to show off a couple of games.

Cya next month!

(if you fancy showing your stuff send me a message and I’ll put you in touch with Chris to set it up).



Colour blindness HLSL shader for XNA

Posted by Paul | Posted in Code, XBLIG, XNA | Posted on 22-04-2011


I’ve recently been thinking about accessibility and ways of adding various aids to my games to make them more enjoyable / playable to gamers with physical disabilities.

So, first up, I’ve written a shader to simulate various forms of colour blindness and a little sample application that allows you to switch between 3 different forms of colour deficient vision: Protanopia (absence of red retinal photoreceptors), Deutanopia (absence of green) and Tritanopia (absence of blue).

Normal color vision is trichromatic. It is initiated by the absorption of photons in three classes of cones, the peak sensitivities of which lie in the long-wavelength (L), middle-wavelength (M), and short-wavelength (S) regions of the spectrum. Therefore any color stimulus can be specified by three numbers, the cone responses; and all colors visible to the color-normal observer are included in a three-dimensional color space. Reduced forms of color vision arise from the effective absence of one of the retinal photopigments of the L type in protanopes, the M type in deuteranopes, and the S type in tritanopes.  For dichromatic observers any color stimulus initiates only two cone responses, and all colors that they can discriminate are included in a two-dimensional color space. Compared with trichromatic vision, dichromatic vision entails a loss of discrimination and results in a reduced color gamut.

If anybody is interested, the code can be found here:


The ‘magic’ numbers used in the shader were initially designed to work with older CRT monitors.  I’m not sure how this will affect the filters when viewed on newer LCDs. I’m continuing research around this area and will post findings as and when.

Typically you would use as a post process filter to simulate how your game would look to dichromats.


Sometimes it is not possible, desirable or practical to alter artwork offline to cater for all gamers.  So the next task is to create a post process component that can (in real time) dynamically alter the colour range of the final output so that it is more friendly to colour deficient players. This component could be turned on or off depending on a players needs (e.g off for a ‘normal vision’ gamer and on for a dichromat). The approach I’m attempting to take is outlined in the following paper:


Droid Assault Screenshots

Posted by Paul | Posted in Dream Build Play, Droid Assault, XBLIG, XNA | Posted on 22-04-2011


Some images from my latest project.

A conversion of the excellent Droid Assault by Puppy Games – coming soon (hopefully) to the Xbox 360 via Xbox Live Indie Games.

The game is currently experiencing some severe performance problems but I’m hoping to sort all that out in time for June’s Dream Build Play competition.


Hello World!

Posted by Paul | Posted in Uncategorized | Posted on 15-04-2011


I sort of have a blog thing! Not sure what I’ll write here yet though. Most probably some rubbish about XNA and Xbox Live Indie Games more than likely.

It’s a work in progress at the moment, so things will likely come and go, move around a bit and generally get redesigned on the fly as I find my feet.