Just in case anyone is wondering what Minotaur Arcade is and how it relates to the old Minotaur Project mobile phone games, well, I shall explain.

The Minotaur Project games were a series of 9 games I did during the two awful years I worked on mobile phone games. Although those two years ended up being the worst of my entire career, the games themselves werre actually pretty decent little things, and garnered good reviews wherever such things were published. Over time the games became nonviable on iOS as Apple decided that nobody would be able to run older games on newer versions of their OS, and we had neither the hardware nor the inclination to invest any more time in updating them, and anyway I had no intent of going back to mobile at all any time soon unless someone was to pay me handsomely in advance to do so. Just too horrible of a market.

Some of the games were ported to Android, and indeed free versions of those are available elsewhere on this site. But basically those games were languishing and pretty much unavailable to most people.

At the beginning of the year Giles was working on the Tempest ports, and I was in need of something to do myself, and I thought it might be nice to somehow maybe resurrect some of those old mobile games, rescue them and bring them to actually viable platforms. Of course I didn’t think that just straight porting them over would cut the mustard; I’d have to be able to make them more interesting in some way and polish up and extend them.

One of my favourites of the old Minotaur games was Gridrunner, which I’d developed in the style of a classic old Namco arcade machine.

Now most old arcade machines were sprite and tile based, and so was a lot of the old Minotaur Project stuff, so I started thinking about how I might go about creating some kind of framework into which it would be easy to port sprite and tile based stuff, making it easy for me to plug the old MP designs into it, whilst also allowing for the possibility of introducing new features with which to extend the designs once ported, and to make them look nicer and more interesting than just straight mobile phone game ports.

I thought it’d even be nice if I could make it so everything could be playable and look cool in VR as well as on a normal monitor, since by now we have a fair bit of VR experience and the necessary bits in our engine, so why not?

And so the framework for Minotaur Arcade was made – a ‘virtual arcade game’ environment designed to be easy to port MP games into (and therefore by their very nature *any* sprite and tile based games also), which would allow me to get ports up and running relatively quickly, then allow me to add extra stuff to make them more interesting and fun. And have playable VR versions fall out by default too.

I don’t have that many screenshots of the actual porting process unfortunately but there are a few taken during porting of Goatup so you can see something of how it works.

Here’s Goatup on iOS. It’s a platform game where you have to climb up as high as possible while eating grass, grabbing bonuses and having kids. As you can see it’s not particularly complicated; there’s a bit of an effect to make it look like it’s mapped onto a section of a cylinder but it’s really pretty minimal, you can barely notice it in the screenshot.

And here we are at the start of the porting. The sprites and tiles have been recreated in a voxel editor, as everything on the “virtual arcade game” screen is a voxel object. To the code we’re porting our environment just looks like a char map and some sprites though, so it’s easy to quickly start getting bits of the game logic ported and working even if they don’t look that nice yet. You can see the platform generation is working and the central column is sort of being drawn even though it looks a bit odd. The Spectrum-style score display of the original is now replaced by our Namco-coinop-style status area at the top.

A bit further on. The “screen” doesn’t have to be flat any more since it’s a 3D object in its own right, so instead of simulating the game being drawn on a section of a cylinder, we can simply actually make it so. It’s looking a bit sparse and odd here but you can see that major bits of the game are actually starting to work and become playable. The goat is running around eating grass and leading kids around already.

And here the basic port is nearly complete. There’s still a few inconsistencies (like it saying ‘lives’ in the top right instead of ‘kids’), but it’s pretty much all working. It looks more interesting than the old mobile versions, it’s fully playable in VR as well, but as far as the game logic is concerned it’s just running on a stock sprite and tile system. It means we can get a nice looking port done really quickly.

Once done we can polish up the game and add extras as necessary. The end results look pretty nice compared to the original starting point.

Original iOS game

Similar scene in Minotaur Arcade framework

MAv1 Goatup general gameplay

Of course we would like to be able to sell these games, and hopefully to be able to do so at a reasonable price, as we’ve learned through bitter experience that the ‘race to the bottom’ pricing of games on mobile led to them becoming devalued to the point where charging over a pound was considered to be “expensive” and it’s now at a point where people on mobile simply expect games to be free and developers have to resort to trickery like serving adverts or designing games that funnel users through IAP pay bottlenecks as part of their core design. This is not something I am willing to resort to.

Ideally we’d like to charge perhaps a bit over a fiver for MA releases. I do appreciate that some people might think that a little cheeky for enhanced mobile phone game ports even if they are quite significantly enhanced (but I would argue less cheeky than selling emulator roms of old games for that kind of price, which seems to happen a lot on various platforms these days). So I figured to make the perceived value better it might be nice to organise the MA releases as pairs of games – hence the “Volume 1″. I figure two decent games, including VR versions, for a bit over a fiver isn’t that bad of a deal.

The other game of the first pair is Gridrunner, as you have no doubt figured out by now. Here are some screenshots of what it looked like on iOS, and what it looks like inside the Minotaur Arcade environment.

Gridrunner on iOS.

Gridrunner ported to Minotaur Arcade. Here is the title screen of the attract mode.

Gameplay from an early level.

Logically the game thinks it’s on a flat tile map. We can use the Minotaur Arcade framework to warp it onto a hemisphere though, so why not.

The display of the “virtual arcade machine” isn’t constrained to the tilemap surface, so explosions can happen in 3D space. Something you will appreciate even more if you put on a VR headset and get inside the display!

Different levels can offer different perspectives and topographies.

And of course it wouldn’t be a Llamasoft game without going a bit mental with the voxelshatter stuff at times (usually at times when you are not directly controlling the action, as here, where you are busy exploding)

and here, where you’ve just completed a level, so we can go a bit bananas with the voxelshatter and postprocessing effects just to punctuate that pleasurable moment of completion.

The games come with all the usual Llamasoft modes you’ve come to expect – Gridrunner has Pure, Endurance and classic Restart Best modes, for example, with online and local score tables for each. The games now also have a new mode called Arcade Mode. This only affects the score table behaviour. Basically on completion of a game, instead of entering your login name automatically as would normally happen, in Arcade Mode when you get a hiscore it brings up an oldschool arcade-style name entry board into which you can enter whatever you like. This entry is then saved on the local (but not online) score table. You might find this mode handy if you have a bunch of mates round, for example, and you want to take turns competing for hiscores, just like in the old arcades, without requiring each participating player to log into Steam or whatever.

Well there you go, that’s what Minotaur Arcade is about. We’ll see how it goes releasing this on ps4 and Steam, and if it goes well enough to warrant it there could be ports to other VR platforms, and further Volumes. It’d be nice if it does do well enough to justify further developments, as I’d enjoy not only porting other Minotaur Project games, but perhaps also doing modern updates of some of my other sprite-and-tile based games (just about anything from the c64 and 16-bit eras would fit well). Or even develop new content for it as well, since I’m not about to just be rehashing old stuff even if I do considerably enhance it.

And it beats selling straight MAME roms for nearly a tenner apiece IMO.

I’ll finish off with a video of MAv1 running on ps4. Look out for it soon, probably on Steam/Oculus first and ps4/psvr subsequently.

The bathtub curve

You may be wondering what this has to do with the development of Polybius, as we’re hopefully not going to be analysing failure modes here. Quite right. It’s just that the shape of the curve for me outlines pretty accurately the stages that you go through during the course of making a game (or any bit of software really, I suppose).

Here’s my version of the curve:

The yay-grunt-phew curve.

Consider how you’ve felt at various times when coding. We’ve all had those times when we’re super keen, when we wake up in the morning and our first thought is how much fun we’re going to be having coding today and how awesome it is to be working on what we’re working on. We’ll call that state “maximum groovosity”.

Conversely we’ve all had days when it’s difficult to brain right and when coding feels like nothing works, nothing flows and it would actually be better for the code if we just did nothing for the day. We’ll call that state “minimum groovosity”.

Our graph here is a plot of groovosity over time for the duration of our project. As you can see there are three distinct phases, as follows:

Yay phase. This occurs right at the outset of the project. This is always a groovy time, as you’re working on something brand new, filled with enthusiasm, and the wins come pretty quickly as the most important basic components of your game design are implemented and become operational. Every day you’re seeing more stuff make the transition from out of your brain into something on the screen, that you can touch and feel with the controller. Working in the Yay phase is pretty effortless as you are having so much fun. Over time though, with the core systems established, the individual wins slow down and you begin to feel aware that there is an awful lot of underlying work that needs done before you can get to the end of the project. You can feel the general level of daily groovosity declining, until eventually you have to grit your teeth and settle in for the next phase:

Grunt phase. This is the part that feels most like real work. When I came back from London with the initial concept approved I was also aware that I had a whole bunch more levels to do, enemies to implement, all that good stuff – it was definitely the start of Grunt phase. Levels in Polybius, although fundamentally simple, still took days each to do, because they had to be fine-tuned so that I knew there was a perfect, exhilarating, no-crash flowing run down each one of them, and that fine tuning means a lot of just going over and over them until it felt right. And doing so in VR, since I wanted the VR experience to be excellent and without any motion sickness to the best of my ability. (It’s a testament to the durability and comfort of the PSVR headset design that I was able to use it comfortably for hours and hours every day, and I must have donned and removed it thousands of times and there’s no sign of any of its components wearing out).

Grunt phase  can be a hard time. It feels like the project stretches out endlessly before you, and things can start to feel a little Sisyphean. You’ll be doing a lot of gruntwork like UI and leaderboard stuff that’s never particularly fun to do but which is absolutely necessary. It’s during this phase that your fears and feelings of inadequacy come out. You’ll have a rubbish coding day and just feel like you’re too rubbish to be attempting what you’re attempting. You’ll have a level design that’s not working out and tell yourself you’re a rubbish game designer and everyone’s going to hate your game. You’ll sometimes feel that the game’s just not “clicking” with you the way you’d hoped and you’ll fret about the possibility that you might be on a hiding to nothing.

This happens to everyone. This is normal. Keep calm and carry on, as they say.

The grunt phase is often what separates hobby projects from professional ones. We all know loads of people who start out on projects, get through the Yay phase, start out on the grunt phase, feel like it’s too much like hard work and end up distracting themselves with something else – often the Yay phase of a new project. And there’s nothing wrong with that, when you’re learning or just out to have some creative fun. That’s why short projects and things like “game jams” are so much fun – you basically move speedily from Yay to Phew without ever having to go near Grunt.

Come the day you sign a contract, though, you’re going to need to be able to have the endurance to get through Grunt, so it’s an important skill to learn if you’re heading in that direction. I’m sometimes asked what I think the most important skill that an aspiring game programmer should learn, and my reply is usually “Completion”.  Having the strength of will to push through the hardest parts of the project even when you feel like smeg and would rather be doing something else is the mark of a professional.

It’ll be worth it, because one day you’ll realise that actually there is light at the end of the tunnel and it’s not even a train – the end is in sight. Rather than stretching out endlessly you can actually start to feel that in a few months, weeks, days the thing could actually be finished. You’ve crossed the desert of Grunt and entered:

Phew Phase. Finally you’re almost there. You’re finishing up all the loose ends now – there are still plenty of those but you work through them and as the list of outstanding issues gets smaller the better everything feels. It begins to look and feel like a well rounded whole; title screens and menus all fully populated and working, levels complete and nicely balanced, score tables functioning, all the little bits and details that go to make a complete game present and correct. As the work crystallises around you into its shiny final form you will find your groovosity level rising day by day.

It’s a great feeling, and it’s well worth the effort it takes to get here; nothing quite beats the onset and experience of the Phew stage. You feel justifiably proud that you had the fortitude to push through to the end despite everything. You realise that your game actually isn’t as bad as you’d feared during the hardest times of the Grunt phase (one developer said something like “our games only finally become good a month before they are finished” and I know I’ve felt the same thing and I think it comes naturally from the feeling of relief that pervades the Phew stage).

Completing and releasing a game is an important milestone in a game designer’s career, too. Showing your mates some cool ideas and demos is one thing, but releasing a complete creation to the world is another. It feels excellent and having done it once you now know that you *can* do it, and that makes it a bit easier next time round. And the more times you do it, the more you’ll feel able to completely rely on the belief that you *will* get it done, no matter how hard things get during the Grunt phase  and no matter how your own insecurities will try to bull you off the path.

Of course in real life the profile if your project isn’t quite as pessimistic as it looks on the curve as drawn there. You’re not going to necessarily spend the grunt phase at your lowest ebb of groovosity. Most of the time you’ll be fine, ticking along at medium  groovosity. Yes there will be bad days but there are also great days too, when something you’ve implemented that day adds a vital spark to the design and it makes you grin when you play through a level and reminds you of how you wanted the game to make you feel. But there is that kind of general shape to it – Yay at the incept, Grunt to push through and get the main part of the work done, and Phew the lovely phase where you bring it over the finish line and realise yep, I’m a game designer, I can actually do this.

There is an extended version of the curve though, which applies specifically to those of us who intend to develop on consoles. It’s pretty much the same regardless of which console you’re on; it happens the same way in all cases. The extended curve looks like this:

The extended baa-thtub curve.

You’ll note the addition of two new phases beyond the actual Phew phase of the original curve. These are console specific and we denote them as follows:

Smeg phase. In terms of blood pressure this can be the most demanding stage of the entire project; usually it is relatively brief compared to the grunt phase but by its very nature it will feel unreasonably long. I sometimes also refer to this phase as “the bureaucratic phase of the release” as you will inevitably be filling in loads of forms, many of which require almost but not quite exactly the same information as each other. You’ll be going through arcane procedures, juggling obscure product and service codes, and have to come up with screenshots, videos and marketing-bollocks style descriptions of your own game for the metadata (I always feel like a knob writing stuff that praises my own game to the high heavens).

You’ll also have cert to get through; oh, the joy of cert. I’m sure you’ll think that it won’t be that bad, after all you’re a conscientious developer and you’ve tested and tested and fixed up all the important bugs you can find before you even think about entering cert. Everything looks fine, nothing falls over and the game feels great. Nonetheless, it is quite likely that despite your best efforts you’ll get at least one bounce at cert, and possibly even multiple bounces (see that serrated section of the Smeg phase plot where these occur). You’ll start to feel pissed off and you’ll hear Italian swearing fill the air. In order to survive this phase it’s important to just chill out and remember:

The people doing cert are not looking for the same things that you are.

Consider the following three issues. Which one is the most important and should halt the release process?

(a) Game occasionally crashes during a level.

(b) Sometimes you don’t get an extra life when you should.

(c) On the credits screen a bit of trademarked text is momentarily obscured.

As a developer you’re naturally enough thinking (a) for sure, because nobody wants a crash bug to spoil their game; (b) also because although it’s not a crash it does alter the gameplay in some way. (c) doesn’t matter because who gives a toss about that?

To cert though everything is the other way round. They will of course report any overt crash bugs, but the chances are you’ve nailed those already yourselves. A relatively infrequent crash bug will certainly get reported if it manifests during test but it’s not considered to be the most serious.

So what is the most serious? According to cert it’d be (c). It’ll all be stuff like incorrect use of copyrighted terms, calling things by names that aren’t officially sanctioned, that kind of thing. It’ll drive you nuts because it’ll be things that to you seem utterly trivial but which are OMG MUST FIX in the eyes of cert. Things that we’ve had raised as MUST FIX bugs over the years include:

• Putting (TM) instead of (R) next to a product name
• Mentioning the system’s name in the credits
• Referring to “right joystick” instead of “right stick”
• Message that we’d put reading FINAL SCORE being read by cert as ANAL SCORE
• Using the term “d-pad”. Never use the term “d-pad”.
• Failing to use the word “button”.

And so on. The more you go through the process the more you’ll get used to it but almost inevitably there will be a few gotchas in there. Usually when you get kicked back from cert it’ll halt the process and it’ll take a few days to restart, so even if the list of bugs is entirely trivial to fix (I think the most severe one we had took Giles and I 20 minutes to find; by far most of the rest were literally just text string edits) it’ll cause the release phase to stretch out in a way that can feel agonising.

This is normal. Just remember it’ll pass, you will get through it, it’s not being done to annoy you or hold you back, it’s just that platform holders have to look at things a particular way because they’re in the middle of all kinds of ethical and legal expectations and they can’t just shove any old code out there into the hands of millions of people without checking it against a specific set of rules, and a lot of those rules will seem arbitrary and peculiar to you. Cert is just something you have to do if you want to play on those platforms, is all. Relax, chill, realise it’s just something that needs done with calm. If there are iterations the chances are that the amount of work you have to do to fix any issues will likely be quite small, often literally just text edits. Fix, reiterate, and then go out and spend some time outdoors or something. After all, you’ve been grinding through Grunt phase for months. Get some air.

Eventually you’ll fight your way through the Smeg phase, everything will get approved, and you’ll enter the final phase of console game development:

Pub Phase. In which your game is finally published on the console.

Also your natural destination after having successfully traversed Yay, Grunt, Phew and Smeg phases. Well done. You’ve earned your stripes as a game dev. Get a few pints down you and let the wrinkles in your brain smooth out.

Soon enough you’ll be doing it all again .

I am very glad finally to have got to this point. It’s been quite a journey.

I want to do a detailed post about the design of Polybius and the process of making it, but as I am actually due to go offgrid for a few days with my brothers on Friday I don’t know if I’ll have time to do it all. So I thought I could break it up into chunks. This first entry isn’t going to say much at all, really, just show a bunch of images.

Back before I knew exactly what Polybius would actually be (and it took rather scarily longer than I expected before I could say that I knew what it would be, but I’ll get to that in another entry) pretty much all I had was the name and a vague kind of feeling about which direction I was going to set out in. One of the first things I did was go out and gather together in a folder a set of screenshots and images, each of which contained some aspect of some part of the feelings that I wanted to feel about the new game. I didn’t want to just outright copy any of these things, mind; just to think about what I liked about each of them, and how they might inform whatever I was going to end up coming up with.

Can you recognise them all?

I’ll be posting more about the making of Polybius over the next day or two, and if not finished by the time I’m off with my brothers I’ll finish it up when I get back.