Monthly Archives: November 2014

Subterranean Nightmare – How Jet Set Willy Destroyed My Life

It’s 1984, and I am a spotty fourteen-year-old obsessed by Mathew Smith’s latest bizarre creation – Jet Set Willy. Jet Set Willy is the sequel to Manic Miner, at that point one of the most popular ZX Spectrum titles to date – and amazingly it’s a quantum leap ahead of its predecessor. There are something like 60 levels in the game, all of which can be explored in a nonlinear manner. It’s surreal, atmospheric, and feels absolutely vast.

But – there’s a problem. The original release of the game is impossible to complete due to a number of bugs. One room in particular – The Banyan Tree – has what’s obviously supposed to be an exit blocked by an impassable block. My brother and I have some limited experience tinkering around with ZX Spectrum machine code so I make a fateful decision – if you can’t beat the game fairly, hack it!

Fortunately you don’t need to be Mathew Broderick in ‘War Games‘ to figure out the Jet Set Willy level format and even a certified numpty such as myself can manage it. I start by writing a BASIC program to PEEK at every address in RAM and print out the associated ASCII character (we’d done something similar in an unsuccessful attempt to win £25k for completing Domark’s text-based adventure ‘Eureka‘*).

Scanning through the memory it becomes clear where the level data is stored as you can read the names of the various rooms. From there it’s a matter of POKE-ing randomly in the nearby memory space – then launching the game, seeing how the level has changed, and trying to figure out what exactly you’ve just done. Wait five minutes for the game to reload from cassette tape, rinse and repeat.

I can’t remember exactly how the level data was formatted but it was pretty straightforward. Each byte (I think) described four ‘blocks’ (two bits for each), with each block being either solid, passable, deadly or empty. After this was a bunch of data containing the graphics for the various blocks, the level name, and parameters describing how the enemies moved. Once I’d figured this out the excitement of designing my own levels quickly overtook the desire to complete the original game – I forgot about The Banyan Tree and wrote a level editor in BASIC aiming to somehow publish my own version.

That project eventually became ‘Subterranean Nightmare‘ – an unashamed Jet Set Willy rip-off that was published by US Gold / Americana Software in 1986. It was written from the ground up but used pretty-much the same level format as Jet Set Willy with a few additions. It contained a few bugs, a lot of bad puns, half-decent graphics and terrible sound. Critical reception was mixed and I received the princely sum of £6,000.00 for it which was a fortune back then and still a significant chunk of change now. From then on, barring a brief flirtation with graphic design and digital marketing in the 90s, it’s been game dev all the way.

There were a couple of (at the time) innovative features in Subterranean Nightmare which I’m still pleased with in retrospect. Firstly, you could save your progress to cassette tape (a feature I’d never seen on any arcade/platform type game at the time), and secondly there were a series of barriers which blocked further progress until a percentage of the game had been completed. It seems ridiculous now but games at that time were usually either completely open (like Jet Set Willy) or completely linear (like Manic Miner) – I wasn’t aware of any title that utilised this combined approach.

One supposedly ‘original’ (i.e. not completely lifted from Jet Set Willy) feature that a few reviews picked up on was the fact that you can jump on some of the enemy’s heads in order to catch a lift to higher platforms. I’m ashamed (ok, not that ashamed) to say that this was actually a particularly pernicious bug that I couldn’t be bothered to fix – deeming it much easier to write it in as a ‘feature’ instead.

Looking on the map you’ll see a level that contains a bunch of large numbers. This was my home phone number at the time and was only supposed to be accessible after completing the entire game. Unfortunately a combination of two bugs made that room just about accessible form the first screen (with some fiddling about) so my parents were inundated with phone calls from geeky kids thinking they’d won some kind of prize. Most of the calls were from Scotland for some reason.

Now, if you’ll forgive, me I must go perform a quirkafleeg…

Subterranean Nightmare On World Of Spectrum
With reviews, maps, emulator images etc

Subterranean Nightmare Walkthrough On YouTube
I can’t believe someone actually did this!

You can read about the next Spectrum game I created, ‘Skateboard Joust’, here.

* The £25k Eureka prize was eventually won, legitimately, by Mathew Woodley – a kid in my year at school.

cornflower
Jet Set Willy’s Bathroom – Where It All Started

floppy
The Banyan Tree – Bringer Of Much Pain & Sorrow

floppy
Bad Puns And Adolescent Search For An Arty Signature

floppy
The First Screen – The Barrier On The Left Disappears When You Collect Your First Object

subterranean-nightmare-map
The Full Subterranean Nightmare Map


Not Even I Would Have The Patience For This…


Thirty Years Later – It All Led To this(!)

Windows Phone Development On A Mac With MonoGame

This week I have been porting ‘Toss The Floppy Frog’ (my first Android and iOS title with MonoGame) to Windows Phone 8 – and it has been painful. Very painful. So painful that I though I’d write a simple step-by-step guide to the process of porting iOS and Android MonoGame titles to Windows Phone. Hopefully this will ease the pain for others.

Part of the suffering has, no doubt, been due to the fact that I am a complete Windows noob. I have been developing on a Mac since around 1995 and have barely touched a Windows machine since then – I even wrote my own JavaME emulator (running on J2SE) so I could do JavaME development on a Mac! Windows, and all its terminologies and conventions, is very much uncharted territory for me.

The largest chunk of pain has, though, been due to what are in my opinion three key deficiencies in the Windows Phone implementation of MonoGame. These are…

1. The Project Templates Are Broken
The MonoGame project templates provided with the 3.2 install don’t work with Visual Studio 2013 (which is the latest version at the time of writing). I don’t know about previous versions. The basic template doesn’t launch the game correctly and doesn’t get to the ‘cornflower blue’ screen we so long for. No errors are given, it just doesn’t work. This issue caused me around half a day of tearing hair out before I found a post on the MonoGame forum that gave a solution (see the ‘step by step’ guide below). If these templates could be fixed I’m sure it would save a lot of developers a lot of grief and avoid casting MonoGame in an unnecessarily bad light.

2. The Content Pipeline Requirement Sucks
I understand the requirement for a content pipeline, really I do. Optimising your assets for use on different platforms is a great idea, but it should be exactly that – part of the optimisation process, NOT a requirement for getting a basic game up and running. The fact that ‘raw’ image and sound assets can’t be loaded in the Windows Phone implementation of MonoGame but can in the Android and iOS versions kind of makes a mockery of the whole ‘Write once, play anywhere’ mantra. Many developers (myself included) will have games that run perfectly fine without the need for content pipeline optimisations and the requirement to use one is just an unnecessary barrier to ‘getting stuff done’.

3. The Content Pipeline Itself Sucks
I couldn’t get any of the MonoGame content projects to load correctly in Visual Studio 2013 and I was unable to find any information online as to how to get the Monogame content tools to work correctly without these. the MonoGame content tools were completely useless to me. Fortunately someone on the MonoGame forums pointed me to an open-source XNB compiler that I was able to edit (ie hack) to convert all my assets to XNB (see the ‘step by step’ guide). That’s at least a day of pain right there. Frankly, if I hadn’t have been pointed to this tool I probably would have given up (and I hardly ever give up).

Now I have the greatest respect for the MonoGame project and team – they have given and continue to give their time for free to provide an awesome product for the IndieDev community. The criticisms above are given in the hope that these areas of MonoGame will be improved which will lead to more developers adopting the platform and more fun/revenue for all of us. Hopefully they’ll be taken in that spirit.

And, once you’ve got past the pain, there is one gigantic plus to all of this, and that is…

100% code re-use!!

Yes, you read that right. Once I was able to iron out a couple of quirks I was able to get 100% resuse of my game code across Android, iOS and Windows Phone. That’s pretty much the holy grail of cross-platform coding and an extremely big upside! The only platform specific code is in the app-launcher stubs and about three lines in my image loader. Nice.

So, without further ado, on to the step by step guide to porting iOS/Android MonoGame titles to Windows Phone using a Mac…

1. Prepare Your Code For Windows Phone
If, like me, you’re more familiar with a Mac and Xamarin Studio than Windows/Visual Studio it’s easiest to get this out of the way before you even touch Windows. Here are the issues I came across:

System.Collections.Hashtable is not available on Windows Phone.

References to this class can be replaced easily by references to:

System.Collections.Generic.Dictionary<Object><Object>

Note that there is a slight ‘gotcha’ here in that Hashtable will return null when trying to retrieve a value for a key that doesn’t exist whereas Dictionary will throw an exception. Your code may need to be altered to account for this.

System.Collections.ArrayList is not available on Windows Phone.

References to this class can be replaced easily by references to:

System.Collections.Generic.List<Object>

System.Runtime.Remoting package is not available on Windows Phone.

If you use this package you will have to work around this somehow. I was using it for dynamic class instantiation and could quite easily replace it by hard-coded calls to instantiate the relevant classes.

The following MonoGame properties return incorrect values on Windows Phone:

GraphicsDeviceManager.PreferredBackBufferWidth
GraphicsDeviceManager.PreferredBackBufferHeight

GraphicsDevice.DisplayMode.Width
GraphicsDevice.DisplayMode.Hight

If you are using any of these to get display width/height the following alternative seems to work:

GraphicsDevice.Viewport.Bounds.Width
GraphicsDevice.Viewport.Bounds.Height

Texture2D.FromStream() is not implemented in MonoGame for Windows Phone.

Bummer. If you are using this (as I was) you will have to work around it. I caught the System.NotImplemented exception and loaded the relevant asset(s) using the content manager instead. I really hope this gets implemented soon as it’s an important function.

Assets are loaded without the file suffix.

On Android/iOS you will probably be using something this:

Content.Load(“myimage.png”)

to load assets which will have to change to:

Content.Load(“myimage”)

on Windows Phone. Ideally write code that catches the exception and tries the alternative method if the first attempt fails.

2. Install Some Kind Of Virtual Machine
You probably want either VMWare Fusion or Parallels. I used Fusion which seems OK though it took quite a bit of farting around to get the ‘shared folder’ feature (which allows you to access files on your ‘host’ mac from the ‘guest’ PC) to work.

3. Set Up The Virtual Machine And Install Windows
Set up an x64 virtual machine and install a 64bit version of Windows otherwise the Windows Phone emulators won’t work. I’m still running a 32bit version of Windows which means I have been unable to launch the emulators so far – I’ve been using an actual device for testing. I believe it must also be the ‘pro’ version of Windows in order for the emulators to work.

4. Install Visual Studio 2013 Twice(!)
From here. You want both the ‘Windows’ version (for Windows Phone) and the ‘Windows Desktop’ version (for the content pipeline stuff). Fortunately both will reside happily side-by-side (unlike my children).

5. Install MonoGame 3.2
From here. May well have been updated since this was written.

6. Install XNA
You will need this for the content pipeline stuff. Follow the instructions and use the PowerShell script kindly provided here.

7. Install Windows Media Player
If it’s not there already – some versions of Windows install it by default, some don’t. You’ll need it for audio processing in the content pipeline and it can be downloaded from here.

8. Set Up A New MonoGame Solution
Launch Visual Studio for Windows and choose the ‘MonoGame Windows Phone’ project template uncder ‘Visual C#’ templates. If it’s not there you need to check MonoGame has installed properly. Call the project something sensible (e.g. the name of your app) and save it anywhere.

9. Update The MonoGame Packages
This is necessary to fix the broken MonoGame template issue and must be done with a solution open in Visual Studio. Launch the NuGet console under Tools->NuGet Package Manager->Package Manager Console and type in the following:

PM: Install-Package MonoGame

This will update the template. It asks if you want to overwrite a few files – click ‘yes’ to each one but ‘no’ to ‘Game1.cs’ as this file will have been altered to reference your app’s namespace.

10. Check For ‘Cornflower Blue’
Now you have done this you should be able to build/run the project and get our old friend the ‘cornflower blue’ screen on your chosen emulator or device. Well done! It took me about a day to get to this point!

11. Import Your Source Code
Having wasted a lot of time trying to get Visual Studio to reference files on my Mac I came to the conclusion that this is impossible. Unlike Xamarin Studio, Visual Studio won’t let you import files as links – they have to reside within the project directory, so the simple-but-far-from-ideal solution is to copy the files from your Mac to the host PC and import. Note that you can ‘copy’ directories from within Windows Explorer and ‘paste’ into Visual Studio which I found the easiest way to import a lot of files at once.

12. Compile Your Source
Hopefully if you followed the suggestions in step one your source just compiles at this point. If not you will have to fix any errors, unfortunately I can’t tell you what these might be as I covered everything I came across in step 1!

13. Convert Your Content To XNB
This should be possible just by using the MonoGame tools but I never succeeded. I had to download an open-source XNB compiler tool from here, open in Visual Studio Desktop, then compile and run to convert my files. It works OK, but the tool only appears to allow you to add one file at a time. Thankfully it was fairly easy for me to modify the code to allow all files in a directory to be added and I’ve included my edited source here. The tool successfully converted PNG, JPG and WAV files for me. If you get an error regarding a missing .dll whilst trying to covert audio you probably need to install Windows Media Player as described in step 7. Whilst MP3 files seem to convert OK I haven’t managed to get them playing correctly yet but I will update this post if and when I do.

14. Import Your XNB Files Into Visual Studio
These go in the ‘Content’ directory exactly as you’d have them organised for iOS or Android. Once imported select the files and under ‘properties’ set ‘build action’ to ‘content’ and ‘copy to output directory’ to ‘copy always’.

15. Change The Template Code To Start Your Game
In Visual Studio find the GamePage.xaml file. Click the little disclosure triangle next to it to reveal GamePage.xaml.cs. Edit this file to replace references to the Game1 with references to your Game class.

16. Run Your App
Congratulations, assuming you followed the tips in stage 1 about loading assets your app should now run on device or emulator. It took me almost three days to get to this point!

I hope this guide is of help to someone – any suggestions for improvement just let me know!

Toss The Floppy Frog – Feels Like My Life’s Work


cornflower
Not Since Yves Klein Has A Blue Square Seemed This Exciting

floppy
At Last – Frog Tossing On Windows

Retry – Why Both Apple And Rovio ‘Could Try Harder’.

Everyone knows how difficult it is for indie devs without a massive marketing budget to get visibility on the AppStore, which is why the minimal amount of curation Apple does is so important for indies – and why it’s doubly depressing to see the “Editor’s Choice” section of the AppStore so often filled with big-budget, big-name titles. Do consumers really need to have yet another ‘Saga’ or ‘Angry Birds’ game rammed down their throats when King/Rovio’s overflowing marketing coffers are quite capable of doing that without Apple’s help? Whenever I take a look at the “Editor’s Choice” section the vast majority of it seems to consist of titles that have already been pushed at me through some other marketing channel (usually Facebook or in-app advertising).

Anyway, self-righteous moaning aside, I thought I’d give Rovio’s ‘Retry’ (which was #1 in the “Editor’s Choice” section a few days ago) a spin and see if there was enough quality there to justify it’s placement. Despite my sour-grapes cynicism and automatic distrust of big-budget apps I’m working on a pixel-art type project at the moment and the game art intrigued me if nothing else.

What a major disappointment. ‘Retry’ is a game so woefully lacking in imagination that it makes ‘Custer’s Revenge’ look like ‘Ocarina Of Time’. My real problem with ‘Retry’ though is not the paucity of original ideas within it, or that it’s a bad game (it’s not actually that bad if I’m honest). My issue with it is that the boardroom level thinking that must have given birth to it is so obvious that Rovio may as well have transcribed the meeting minutes in the App Description:

“Fellow Directors, I feel we’ve reached about level 7 of the game they call ‘Shit Creek’. People are getting bored of ‘Angry Birds’ and the shareholders are getting twitchy about all these layoffs. We need another Big Idea – something to prove “Angry Birds” wasn’t just a fluke. You all get paid enormous salaries – what have you got for me?”

“Well, that ‘Flappy Bird’ game was huge and it was made by just the one guy. Imagine if we took a concept that braindead and then threw shedloads of money at it!”

“Good idea – we wouldn’t even need shedloads of money. These mofos love that retro pixel-art shit and it’s a piece of piss to churn that stuff out. We can even copy some old SNES games!”

“Sold! We can’t use a bird though, too hard to animate. What about a plane – they’re easy to draw?”

“Genius idea – we could call it ‘Big Budget Flappy Plane’!!”

“We’re so cool. No wonder this company is worth biilions. See you soon Rovi-bros!”

I do like the art though, the art is pretty cool. And it’s not really nicked from a SNES title – it’s simple, chunky, colourful and general very appealing. And the plane control is quite nice when you get the hang of it. The main problem (and it’s a big problem) with the gameplay is that the sprite sizes and game physics are so designed that you simply can’t see far enough in front of you to react effectively to what’s coming up, making success more about memorising the levels than anything else. I guess if that’s your thing though….

Did I mention I have a ‘Flappy Bird’ clone coming out? Guilty as charged, your honour.

retry1
Retry – aka Big Budget Flappy Plane

retry2
Budget Wouldn’t Stretch To A Crash Anim Though

custer
Custer’s Revenge – Don’t Even Go There


Floppy Frog – NOT a Flappy Bird Clone, Honest