Hyper Sentinel LOADING – Part 5

by Jonathan Port. Continued from Part 4.

Hi-Score Table

The game has come a very long way since the early build on the iOS platform when I first showed the game to Huey Games in a noisy and dimly lit pub meet up for indie game developers. Since that time, we have all shared the same vision for where we wanted to take the game and how we wanted it to turn out. From a design point of view there have been few, if any, major roadblocks. The game has mainly progressed the way we planned. Any issues we may have come across during development have by and large been solved without too much fuss or hair pulling. We’re a small team and I think, for this game at least, that has worked to our benefit. There have been no great committees or drawn out planning meetings. We’ve stuck to our design, followed through on our philosophy and solved issues with relative speed as they have come along. There have been times where something in the game may not have quite clicked straight away and we couldn’t put our finger on why. More often than not the evolution of the game itself has presented the solution. An important part of problem solving has been taking the game out and getting people to actually play it. This has been an ongoing process during most of the game’s development.

Hyper Sentinel has been to many game shows and conventions across the UK, Europe and the globe, including Gamescom, EGX, Play Expo and many Retro gaming events. These events are, of course, a great way to get the game known and recognised by a wider audience. It’s a real pleasure to see your game advertised on a big banner, in the same hall as well known AAA games from major platform holders. Having people who have just played on the latest Mario or Call of Duty, sit down to play your game is a real treat – it’s hard work to get them there – but once you do, it’s a thrill. Once you’ve been to a few shows with your game, you start to learn that there is a much more important reason to have your game on display and available for all to play: feedback.

20170824_141522.jpg
Meeting Kickstarter backers at Gamescom 2017 – always a pleasure.

When you’re making a game, you get very close to it. You understand the mechanics without thought, you understand the objectives without requiring prompts, and having played it so much you are totally adept with how it controls. These are tools a person doesn’t have when first sitting down with your game. When you first show your game, it’s a proud time and you are eager to explain how it works and show off all the great things it can do. You are keen to hang on to the player’s shoulder and help them out immediately, should they get stuck in any way. You learn over time that these are the things you shouldn’t be doing. In the first few shows, even if you know this golden rule, you’ll find you need to be on hand to help. This is how you find out how well you have executed your design.

For Hyper Sentinel there were many small snags and areas of the game that weren’t immediately intuitive during its early showings. These included (but were not limited to) game objectives, game controls, play area, and misinterpretation of what is and what isn’t an enemy in the game. At each show we would all make our own notes and then afterwards combine them on to a Trello board of issues to be addressed. This is an ongoing process, each and every show, and is critical! Sometimes it would take a few showings for us to successfully address something that we could see players were struggling to understand. Most of the time the adjustments required are actually very small, it may be just a single sound effect or a change in colour that needs addressing.

If you have been following along with the Kickstarter video diary for the game you might even be able to pick out some of these adjustments. There have been many and most have gone into the game without fanfare. You won’t notice them now when you play the game and that’s really the point! As the shows went by, the aim, as I saw it, was to become less and less involved with having to explain the game and how to play it. In the last couple of shows I think we got to the point where we could hand the controller over and say nothing. Only then did we feel confident that the game was ready to ship.

I remember driving back from one of the Insomnia events at the NEC in Birmingham. One guy had come back to play Hyper Sentinel time and again, and he had figured out a way to exploit the score system! Jonathan and I discussed the issue on the motorway heading back to Manchester and basically thrashed out a re-design for what became the final score system, in the space of a car journey.

These kinds of conversations are my favourite moments in any game development project – when you are on completely the same wavelength with another developer, the solution simply emerges organically until everything clicks. This happened a great deal working on Hyper Sentinel with Jonathan Port and John Ogden, both of whom are without a doubt amongst the most talented developers that I have had the privilege of working with.

Rob Hewson

Completion

As I’ve mentioned, the driving force behind our game has always been Neo Retro; the philosophy of making a game that is imagined in a retro style, but that plays in the modern world. I could point out many examples that highlight this idea at work: pulsating Fractures soundtracks, supersonic speed in 4K at 60fps, layers of particle effects and alpha trails, and even the retro graphics modes using modern shader techniques to toggle between them at an instant. But perhaps one of the most interesting examples of our Neo Retro approach has been our work on the Mixer Mode. Here is a cutting-edge technology (and believe me when I say we’ve really pushed this) gelled together with our core retro-styled gameplay.

Multiplayer has always been something that we’ve thought about, but as a small team with tight deadlines it hasn’t been top of our priority lists. But with the delay we had to make for a 2018 release, it did free up a little more of my time. So, while John Ogden was busy burning the midnight oil to get the game optimised perfectly for all the launch platforms, I got involved with our Mixer project.

Rob had obviously been keeping his eye on the technology and had drawn up, what turned out to be an ingenious design concept for how Hyper Sentinel could work with Mixer. A mock-up of the concept was first put together by John while I was finishing some of the final elements of the main game. The concept and design received such a great response that I was soon working on fleshing out the prototype in full. It was a bit of a whirlwind of game development as we were working on a roughly ten-day work around between content demonstrations. I started out with getting a solid code base for the back end (a term used for the non-visual ‘behind the scenes’ parts of the game code) in place. I knew this needed to be done first so that it could be afforded proper time; if this wasn’t done right, the rest of the game mode could fall like a house of cards.

Thankfully it fit together well, and after the first week or so, I had a working set of code that implemented the design for both the attacker and defender parameters of the game, which included the code that calculated cooldowns, costings, click-counts and player scalability. Rob and John demonstrated the game behind closed doors and were getting an excited response. Next up I worked on ‘object tagging’ for the game. I developed a way that from an incoming Mixer message I could gather various attributes such as player gamer tag, which team the players were on etc., and then put them together into a virtual tag that I could attach to any object in the game. For example, if a player launched an Asteroid attack, I could attach the ‘tag’ to the asteroid so that when it hit the player I had the metadata that I needed to record away for each team. I’m not sure whose idea it was, but at this point it struck us that we could then show a name label on screen when a successful hit was made. Other participants in the game would then be encouraged to get their name on screen too! The whole design concept worked really well and came together surprisingly quickly considering this was brand new technology for all involved. Thinking back now I’m still surprised how quickly and solidly that code was made!

The origin of Mixer mode is an interesting story. My Dad and I had attended an Xbox event, which was primarily about publishing on Xbox and the best ways to approach marketing. Mixer was a new area of focus, so they had it as part of their marketing presentation. At first, I couldn’t see a way of applying it to Hyper Sentinel, but gradually an outline of the idea emerged in my mind as I sat there in the audience.

Later, at the Develop conference in Brighton, I had a meeting with a representative from ID@Xbox to run through our marketing plan. I had slotted a slide for the Mixer mode idea into the plan as potential DLC:

This became a focal point for our discussions – they thought it was a really cool and unique idea. We agreed there and then for a follow up meeting with another Microsoft representative at Gamescom.

My trip to Gamescom was challenging to say the least, as readers of the Huey Games blog will know (see https://huey.games/2017/09/15/gamescom-a-tale-of-triumph-disaster/). However, the Microsoft meeting went brilliantly, and I have a feeling I will forever remember Gamescom 2017 as one of the most important events for Huey Game as a result.

Rob Hewson

As everything was coming together, the idea came about that we could make this game mode different still. We already had Survival mode fully implemented in the game, and the Mixer mode was originally considered as an online version of that mode. However, as we were thinking about game balance the idea came about that we could play it a little differently. We decided the main game player would start with a fixed score, which would increase as she or he evaded the enemies of the attacking side. To balance this out, players would lose score if they shot down any enemies. As the intensity of the level builds, the player must quickly decide whether to evade (leaving the enemies on screen) or lose some score, but get some breathing space.

mixer_social_4

Next we needed to consider the defending side, the idea being that defenders could give the player energy or Powerdroids that could be used against the enemies without affecting the player’s score. Cooldown periods would be set so that the defenders needed to be strategic on when they launched the power ups. It was set up to play like a game of cat and mouse between the attackers and defenders. To tie it all together, I coded in scoreboard panels during the game so that each side could see how many hits and attempts they had made and individual players could see the best-performing people on their side (attacker or defenders). At the end of the game we thought it would be cool to have a sliding swingometer that would show the winning side. The whole concept is a thoroughly modern design and it just slotted straight into the game code with little disruption to the main game.

I guess it’s amazing how these crazy ideas sometimes work out. Come to think of it, that just about sums up Hyper Sentinel from my point of view. A crazy dream that worked out!

END

 

 

 

Hyper Sentinel LOADING – Part 4

by Jonathan Port

Continued from Part 3

Press a Key to Continue

The Kickstarter was done but it was business as usual in dev land. There was a mountain of work to get through in a short period of time: nine levels to build, nine boss fights to build, a raft of effects to implement and several more layers of polish. There were also little issues and niggles that we were picking up. Just before the demo build was cut (some weeks before) Rob had been play-testing and mentioned in passing that he thought the laser fire wasn’t reacting quite as quickly after your flip the ship compared to the original iOS code. John Ogden had originally laid down the early groundwork in the Unity build and I knew how he had implemented the code for the flip manoeuvre. Essentially the pitch of the ship alters from 0 through to 180, and at each extent the direction state will be facing either left or facing right. The lasers are not allowed to fire as the ship is pitching, so I knew the laser code would only kick in at 0 or 180. I therefore knew the code was correct and I vaguely ignored Rob’s comment. Then during the start of the Kickstarter campaign somebody else mentioned the same thing. Hmmm, I’d better take a look. I debugged and determined that the code was behaving correctly as I expected. As soon as the ship has finished pitching, its state allows firing. I pored through the code a bit and realised that although physically the laser cannot shoot until the ship has fully flipped, the reaction time of the player meant that you would end up with a half-second delay. I pulled the code around a bit to alter the timing of pitch and direction states and made a mess. The animation cycle of the ship is tied in with the pitch and everything went wrong. I decided since it had only been mentioned once that it would be best to just ignore the whole thing. Never ignore an obvious issue, it will just come back and bite you some time later! It did. Someone else was now mentioning the same thing and I wasn’t going to get away with it.

So, I went back and re-read through the code and state changes and the solution just appeared in front of me. I had been looking at the direction states for a solution when I should have gone back to the pitch. A simple bit of normalization code and the timing issue resolved on its own. So now the laser fire is enabled as the ship reaches the halfway point of the flip (90-degree pitch) allowing plenty of leeway for the reaction time of the player. This change gave a much more reactive feel, you can zoom away with a Hunter on your tail, flip around and still have enough time to fire off a salvo of laser bolts to take it down: a trick that was very difficult to pull off previously. Lesson learned.

Around this time, I was working on the Sentry Guard ion cannons. I re-did the graphics for it about three times before settling on its current state. The first go was a bit spiky and not intimidating enough. The next go looked nicer but wasn’t quite the right style for the game, it would have sat nicely with 16-bit graphics of an Amiga, but not the more pixelated look of the 8-bits. So, I pixelated that out a bit more, but still wasn’t quite happy, so I re-did it and came up with a graphic that fit with the chunky, pixel look of the other cannons and gun turrets in the game. It’s important that the style is retained throughout the game. It’s no good having something chunky and pixely sat next to something that is smooth and shiny. It’s the same for the explosion effects. There are lots of off-the-shelf particle effects in Unity that could have been thrown in, but it would result in a disjointed looking game rather than a retro looking game. You have such a high resolution to play with on modern hardware that it actually takes some effort to pixelate and get the right look across all game effects! The Neo Retro philosophy that we are following does not exclude consistency. It’s a surprisingly tricky process to decide: when you should look for a modern solution and when you should stick with something more retro. With Hyper Sentinel, I believe we got the balance just right

The code was progressing fine, but I now had very tight timescales to meet. There are many things during game development that are not obvious when looking in from the outside. For our backers we had set a delivery date that I obviously needed to meet. But the reality was that my real delivery date for first draft completion was much sooner than that. Lots of things have to be in place for the various game review cycles that have to be done by third parties. I had a plan that would hopefully get all the levels and assets in place early, with filling out and polish coming afterwards. We discussed timescales together on a Skype call and Rob suggested that John help with the game metrics, and analytic data capturing during gameplay. That could then be aggregated to form the basis of the in-game medal system and the achievements that are required by the console versions of the game. I noted that the clocks were going forward that weekend too  – another hour lost.

r2
There are 60 medals in Hyper Sentinel – 5 per level. John Ogden wrote much of the code which underpins this system, which is also involved in the Achievement and Trophy code.

As John and I continued with the game code, Rob was busy organising all the other stuff that goes into making a game, including marketing. It was a nice surprise then when, at the end of March, Hyper Sentinel received a two-page spread right near the front of Retro Gamer magazine! I knew it had been possible that we’d be in there somewhere because I had done an interview for them a few weeks earlier during the Kickstarter campaign. But a full-colour, two-page spread was more than I had hoped. I even got my mugshot in there too. I checked for paparazzi around the house when I got home that evening, but there were none. I considered wearing my Hyper Sentinel T-Shirt and popping into the local Game store at the weekend, but decided I would be better just cracking on with the code. My wife Sarah, noticed that our Denby cups were also in the picture (with Rob holding one). She said we’d better keep hold of those in case a collector wanted a famous set of cups in the future! They are nice cups.

retrogamer
The Hyper Sentinel interview in issue #166 of Retro Gamer magazine

By the end of March, I had finished the layout of all the levels and that was a small milestone because it kept the game on track to meet the first deadline for a ratings build. We wanted to get the ratings done early and out of the way for scheduling reasons, but that meant the game needed to be feature complete. Not necessarily polished but with the main gameplay in place, all the level designs, enemies, and bosses had to be in place. The game was feeling good and solid but was lacking a lot of polish in many areas. The biggest challenge was building the bosses. So far there were four completed which left eight still to do, and those would be much more complex than the others. I had four weeks to finish a first pass for all of the bosses. If you do the maths, that’s half a week for each boss. It was going to be too difficult to do properly. I decided the most efficient way would be to put the finalised boss designs in but give them limited and similar movement patterns to each other. We could expand on that later down the line. Meanwhile the Nintendo Switch I had purchased earlier that month was looking sorry for itself in the corner of the room. Sorry Zelda, but this was how it was going to have to be for a while.

At the start of April we received some great news; confirmation that we would be good to go for the Switch version of Hyper Sentinel. I knew Switch was going to be a perfect match for the game. Incidentally, I would have liked for the game to be on Vita too, but it just wouldn’t have made any commercial sense. I put together some gameplay videos so Rob could make the announcement to our backers and then the wider world, but I had to be careful doing these, as the bosses weren’t properly done yet and there was still quite a lot of unpolished content.

hypersentinelswitch_tn

Nevertheless, at this time it was one of the first confirmed shoot ‘em ups for the Switch, which was exciting! Speaking of bosses, that was my entire focus at the time. I spent the week putting together the Level 6 boss. The boss on level six contains two Battle Orbs that spin around and introduce the Sentient enemies. The Sentients hunt in pairs, tracking your position before pouncing forward. They mostly worked, although sometimes crowded together which I needed to fix. My deadline was to have the first pass of all bosses finished in time for Easter. One of the nice things with Unity development is that it is very heavily component based, so I can write small action routines, attach them in, and then later replace them with a set of all-singing, all-dancing routines. For the time being, this approach was ideal for the bosses, as I was basically creating prototype behaviour scripts for them.

Level 8 boss, Pytharg, took a bit of fiddling to get right. I had made a few errors in the curve plotting which was causing the boss to ‘hyperspace’ at the end of a movement cycle. I think the error was partly due to fatigue and general tiredness; I spent an hour or two that night trying to fix it without any real focus, but the next day I fixed it in about 15 minutes! I was beginning to find the initial boss framework a bit tiresome to make and couldn’t wait to get them laid out for every level, then I could go back through each one and add proper motion, transitions and effects; that’s the stuff I really enjoy doing. It wouldn’t be long now though, the Level 12 boss layout, then Level 11 (much easier) would hopefully leave us on target for two weeks of development to get a level select screen and other game modes sketched and laid out. Yes, that’s right, at this point in development there were no option screens or level select screens or medal screens or general UI elements in place at all. Still so much to do.

Pytharg

I decided to upgrade to the latest version of Unity. Previous upgrades had generally gone well, with little in the way of issues to resolve afterwards. This time, that was not the case. I installed the latest version and then opened the project file, waiting patiently for all the assets to be imported. The environment opened up and only one error appeared in the console, not too bad, I thought, could have been worse. A quick look seemed to indicate that one of the methods of the Animator class had been removed. I couldn’t seem to find any equivalent method or much in the documentation on what had happened to it. In the end, I restructured the animator state machine, so I no longer needed the method anyway. I carried on to check that the game was still functioning okay. Level 1 looked fine, but the enemy destroyer decks on all the other levels had disappeared! Not the best thing to find to be honest. On closer inspection the game objects that build up the destroyer were all present, but nothing was being displayed; just a pile of destructible objects floating in space. I kept looking. It seemed that every game object from the destroyer prefabs now had an empty sprite property. After some playing around with various processes and functions, I knew the only way forward was to manually add back each and every asset to the prefabs. Three hours later I was back to normal. Playing the game in the editor wasn’t looking great either, I was getting screen tearing all over the place. I did a quick build of the game and thankfully the compiled code ran smoothly at 60hz, so it had to be an editor issue. A bit more faffing and I found that turning on the new Metal support for the editor seemed to smooth things out somewhat (all my game development is done on an Apple Mac). By 11pm that evening I was ready to continue finishing off the first pass of the level bosses.

We were now a couple of weeks into April and gremlins were appearing all over the place. When I noticed that the Arc-Steamer mines seemed to be destroying immediately on release instead of on the correct timer, I set about debugging everything. The mines are pre-created and stored in an object pool due to the sheer volume that can be created. This means that when a stream of them is released, they are just pulled out of the pool and made active. When they explode, rather than being destroyed, they are reset and made inactive. So I checked that the pool was behaving, which I was sure it would be since it is a generic piece of code that is used in many other places without issue. After confirming this was all okay, I debugged and logged the timer code for how long the mine stays on screen before exploding. I set the timer to a really high value and the mines were definitely ignoring it. I scratched my head and decided to look at the animator instead. I was using a trigger, so that when the timer goes off, a trigger fires and sets off the destruction animation. Once that is complete, the mine is put back in the pool. I stared at it for a bit and then noticed that the state machine wasn’t being reset back to its starting state. Hmm. So, in a rush of intuition I added a new flow arrow to the diagram and dragged it back to the starting state, and then tried it out. Fixed! It seems I must have missed a bug in the previous version of Unity’s animator that was resetting the state. Now that, that was fixed it had triggered another bug (which is only noticeable if you are using pooling). Adding further to my gremlin woes, I had also upgraded one of the Unity assets I was using, and that had bugs too! When I was firing at gun turrets or bosses, rather than them flashing white during a hit, they were disappearing from the screen entirely. Arggh! I found a quick workaround, but it didn’t fix all the issues I was finding. By this time it was far later in the evening than I thought, since my watch had (unbeknownst to me) stopped working and I thought it was only 11.30pm. It was in fact, approaching 2am, I was tired, but hurriedly put together a mildly angry email and fired it off to the company who made the asset. By 9.30am the next morning, I had received an email of thanks and a notice that the bug was fixed and available to download. Wow, now that’s service! I humbly replied with another email thanking them for their effort. As I was in a debug kind of mood so decided to spend a bit of time with the profiler and optimised a few routines that were spiking higher than they should for what they were doing. I hoped there would be no more gremlins for a while now.

There was going to be more pain in April though. I usually go for a long run on Sunday mornings. In fact, I often solve many problems during those runs as it helps me to focus on my thoughts. This time was to be different though and I discovered that pavement is a very hard surface. Bad perception on my part meant that I thought I had judged the height of a curb correctly: I hadn’t. All I remembered is falling like a tree and feeling a very hard surface hit my chin. My first concern was to do a quick system check to make sure I hadn’t broken any limbs. That area seemed good, thankfully! The next concern, being British as I am, was to quickly get up and run along hoping nobody had witnessed my embarrassing fall from their front room windows. As well as my chin I had cuts on my knees, hands and the tips of my fingers. It is the latter of these wounds that caused most of my problems. Making a game can be mentally painful, but let it be known that there is code underpinning in Hyper Sentinel that was also physically painful to write; key-press by searing key-press.

Nearing the end of April, the deadline was soon going to be upon us. I was busy working on UI for the new option screens and medal layout. At the same time John had been completing the code for the medals and putting unit tests around them so that we didn’t accidently break them later down the line. We needed to merge the code with our fingers crossed – there wasn’t going to be any time for issues – and I also had a sprint deadline at work. My code was pushed to Git – our distributed source code repository where we all share and maintain the game code – as was John’s code. Once the branches merged it compiled, ran, and nearly worked first-time. The systems were talking together and I could cycle through the medals – cycling through the medals proves the interface works – but there appeared to be a few teething issues, as the descriptions of the medals weren’t displaying correctly. A quick debug, revealed I was passing a level number value into a routine that was asking for a medal number. My fault! I hadn’t picked it up before because I was using a stub routine that was just returning random data to test my user interface. The other issue was a little more subtle, and without going in to too much on the technical side, it was due to how C# handles capturing variables for closures within coroutines. Sound nasty? Yeah, it doesn’t cause a graceful error that can be tracked either. I made a simple refactor of the code and it seemed to fix it, but I couldn’t be 100% sure due to the nature of the bug (turns out it worked as I never saw the problem ever again). There were some issues retaining and saving out the medal data too, but I decided I would blame the Unity serializer for that.

At the start of May we were preparing for the Switch announcement. Better than that, we were showing off a Nintendo Switch trailer for everyone to see, and Nintendo were going to help us a little by promoting the announcement on their YouTube channel; a pretty cool thing indeed. There were lots of other things going on at this time too. The ratings submissions seemed to be going well with an ‘E’ for everyone coming through so far, which was what I’d been hoping for.

From what Rob was saying it seems the process is wildly different for each territory. Some are happy with videos, others happy to go off of trust, some require hand-written letters before submitting, and others want the content delivered on a USB stick rather than digitally! As always,, Rob was on top of it all. The next goal was to get most of the game together and ready for preliminary Xbox submission. We all sat and chewed on the large volume of code and paperwork still to get through. Things to discuss included: platform holder requirements, territory localisation, menu screen completion, content, polish, leaderboards, and much more. Still so much to do. The elephant waited for us to finish our discussion before quietly entering the room and pointing out the fact we now had three weeks to finish the majority of the content. Okay, so that was going to be tight again! I needed to finish the bosses and get all the menus in proper working order for the various modes and completion statuses. I also needed to go through the game code and find everything that required language localisation (I hadn’t picked up on the need for this earlier in the year!) and then find a cunning way to adjust the code with little disruption so that it could work from language resource files. I hadn’t done the pause screens yet either! Meanwhile John was on to the console port work, achievements, CRT filters, screen modes, and leaderboard systems. In for a penny, in for a pound.

Ratings! That seems so long ago now that I have almost forgotten how much of a pain it was. I had prepared builds for ratings before, but usually with a team of 20–30 developers working on it and a publisher to do the actual submissions. I have since learnt that while publishing is significantly less complex than development, there is still a huge amount of work to get through, and it must be done repeatedly and differently for each ratings board and each platform. Looking back, this difficulty with ratings should have been the first clue that things were going to take a lot longer than we expected, self-publishing a game on multiple formats.

Rob Hewson

By the end of May it was time to take a break. It had been a tough slog getting the level completion screens completed with various bits of fanfare. It’s not particularly hard work but there’s a reasonable amount of code required to pull various UI elements in and get them operating smoothly together. I had managed to get first pass completion of the pause screens, which was mostly an exercise of reusing code from the main menus because we are allowing players to change the various settings (volume, graphics modes etc.) on the fly mid-level. It ended up a bit more work than expected, mainly due to the time flow in the game, which is halted during a pause. This was also affecting the animations in the menu panels (such as fading in and out). I hadn’t anticipated this when doing the menu code previously: it’s stuff like this that eats up your time. Nevertheless, a whole lot of work had been completed in those last three weeks, and quite frankly, I was knackered! Good job I was going on holiday with the family for a week then! Time to leave the keyboard at home and drink some beer!

When you code as a day job and then make games during your evenings it can sometimes feel as though you’re missing out on stuff like just sitting and watching a film with your feet up. It is good sometimes to just take the night off and eat pizza, but most of your time must be spent coding and creating. I had a great holiday, but those who love to code (making games or otherwise) will know that feeling of being away from the keyboard for more than a few days. It’s like an itch to just get back and make something. Rob Fenn, our awesome musician, completed most of the new music and speech for the game while I was away, and a little email on my last day on holiday meant that I knew what I was going to do as soon as I got back. I plugged the music in and, as expected, it sounded fantastic. The game was feeling good – I’d played it so much over many months – but with the new music in place and a week away to reflect, it felt nice being back at it. I knew our backers and fans and hopefully many more were going to really love playing Hyper Sentinel. It was now time to get it feature complete!

00 Soundtrack Album Cover

Rob Fenn did a fantastic job with the music, and I really love the digital voices he added for the game too. I remember one of the quotes from my father’s book; Hints and Tips for Videogame Pioneers: “One thing that became very clear to me over time was the importance of music and sound effects, because they actually carry a great deal of the emotional content in a game”. Rob understood our Neo Retro philosophy perfectly, and his chiptune style soundtrack simultaneously prods at your nostalgia, whilst being technically beyond anything you could dream of achieving on a retro system.

I am particularly fond of the boss theme. One of the references we gave to Rob was the Dr. Robotnik boss theme from the original Sonic – perhaps you will recognize the influence when you play Hyper Sentinel.

Rob Hewson

We were getting close, but still none of us were entirely happy with the colouring of the decks. Rob went and got some expert feedback from an Art Director friend he knew in the industry and this made a huge difference. Adjusting saturation levels and the like gave the enemy destroyer far more depth and the gameplay graphics really began to pop out. As well as that, I was now on to yet another polish layer. I was progressing with adding a ‘white hot’ glow to the enemy bullets so they would quickly be identified during frantic action – prior to this the enemy bullets were solid red.

The game was progressing, but it was becoming apparent that the volume and complexity of the port work meant that a delay was likely to be incoming. Initially this was just a small delay and at least it meant I could continue with adding extra polish for the game. Unfortunately, that delay became a longer one by January 2018. We had still been confident of getting through the platform specific code in reasonable time, but the timing had landed us right in the middle of game release silly season. October, November, and December are no-go areas for Indie games, to  put it frankly: it would have been commercial suicide. There are so many AAA games being released during that time that there is literally no space to promote smaller games. We really wanted to get the game out for backers in time for Christmas and we sought advice to see if it was possible, but in the end it simply wasn’t sensible. Despite all of our very late nights and hard effort, we just couldn’t hit a 2017 release.

When we delayed to January 2018 it seemed like such a long time away, we couldn’t imagine missing that window. We decided to use the time to add even more polish to the game – extra touches like the “Boost Attract” and “Death Dodge” which we knew would add further quality – after all we had plenty of time! Then there was the opportunity to produce the pioneering “Mixer Mode” in partnership with Microsoft, which we simply couldn’t ignore.

Ultimately, we underestimated the amount of bespoke code, even when using a cross-platform engine like Unity, which would be required. Some platforms required us to completely re-write the save/load structure or re-write the leaderboards. We also underestimated the complexity and variation in requirements for each platform and the sheer volume of work in the publishing process. Above all, we simply didn’t have enough developers to work on these things concurrently, so we had to juggle from one platform to the next.

Suffice to say we have learned a huge amount and we have also built a solid code foundation, which can be re-used for subsequent games instead of needing to develop everything from scratch.

We are hugely grateful to our Kickstarter backers for their understanding and support throughout this process.

Rob Hewson

r4

 

Hyper Sentinel LOADING – Part 3

by Jonathan Port

Continued from previous blog…

Rewind

During the original Kickstarter, John Ogden was making a start on building Hyper Sentinel using the Unity engine. Very early on this was a straight port of existing iOS code, I’d written some C# code several months earlier that would import the plist data structures from iOS over to Unity, but not much more than that had been done. John took that code and built a level import utility so we could get all the decks and level objects laid out, before starting work on player ship controls and enemy movement. It quickly became apparent that, instead of attempting to port code, it would be best to make the game completely from scratch. The iOS game was built entirely in the Swift language without any level designers. Unity is a very different environment and we decided together that the game would not benefit unless we broke that link and re-made it from the ground up. It was 100% the best decision to make.

After the Kickstarter finished the game went into a short period of limbo. I think we left a few weeks to consider our options. Eventually over a Skype call we all decided that the game should continue to be made, as we had a lot of fans from the Kickstarter who encouraged us to continue the project. I agreed to take over the game code in Unity and make the game for a second time. I think I was a little anxious, I had already spent the better part of a year making the game once, and the prospect of doing it all over again didn’t fill me with great delight right away. I had no experience using the Unity engine other than a little poking around some months earlier. Imagine if you would, having finished writing a book only for the entire manuscript to be destroyed. For the book to come to life you were going to have to write the story again entirely from memory and in a foreign language that you would be learning on the go at the same time. This was my situation. There was a little silver lining, and that was that John had made some very good progress in just a few short weeks, also Huey weren’t putting any pressure on me. It was very much a case of taking the code we had, understanding it and seeing how it went. I spent the next two weeks feeling around and learning the code that John had made; I was feeling much more comfortable by now and was able to make various tweaks and additions. I knew early on that I could do it. We were off again, but the challenge I had was to put together a commercial quality playable game demo by Christmas, and that was only four months away.

During this whole project I had been making the game in my evenings and weekends. I did my professional day job as a business programmer and would then come home to spend some time with my family and grab the hours I could with the game. This is not uncommon for an indie game developer, but nonetheless it was tough going. And it was about to get tougher. My daughter had been having a lot of stomach troubles for most of the previous nine months and was struggling to find any food that she could hold down. It had been getting worse and she had lost a lot of weight. We’d been seeing some specialists, but the tests were all coming back okay. Unfortunately, it ended in us having to rush her to hospital where we finally got a diagnosis that she had Crohn’s disease. She ended up in hospital for a week or so with various drips to stabilise her weight before being allowed home along with a long prescription for a cocktail of drugs. It was a tough time for us all, and not much game development happened. Once things had started to settle a little (as best they can when dealing with Crohn’s) I was ready to pick up and carry on with the game. Only a few weeks later, and another roadblock presented itself. It turns out that the company I worked for had decided to outsource our department overseas. There were several weeks of uncertainty over what would happen, followed by a lot of time spent discussing the future with various IT recruiters. I started a new job at the end of October 2016, but by this time I had lost nearly an entire month of game development.

It had been a real rollercoaster of a year, but things were about to get better.

PRESS PLAY ON TAPE #2

As Christmas approached the game was starting to come together again. I had become more proficient with Unity and was back in full production mode. John had laid some solid foundations, and I was able to use my knowledge of how the game had previously worked to get things feeling just right. There’s a certain “weight” to the controls that we needed to get spot on and all sorts of tiny details that aren’t obvious unless you know the game well. It all had to be done again from scratch and it all took time. At this point there was still only the first level. I  decided rather than quickly plug all the level designs in, it would be better time spent to get the details, the animations, the tiny pieces of polish in place for just one single level. We wanted a three-level demo and I kind of knew what those levels would be. There wouldn’t be too much extra work I would need to do if I nailed everything just right for Level 1. I think I finished Level 1 just before Christmas and started implementing Level 2 during the holiday break. Thankfully, using the level import utility that John built, along with all the prefabricated game objects I had already made, Level 2 almost happened over night.

I quickly packaged it together for Huey Games to look at. We had some discussions over Skype and decided that another Kickstarter would be worth a go. I had roughly three weeks to build the third demo level while Huey Games would work on building up for the Kickstarter. It was an exciting time again and we were all very happy with how the game was playing. Looking back, I think we did a terrific job to get so close a feel to the original game, even though we were using an entirely different programming language, game engine and code base.

We were now at the start of February 2017 and the demo build was still not ready. I had not yet written any code for the Powerdroids in the game and Level 3 still wasn’t complete. It was about ten days until the Kickstarter launch and there was much to do, not the least of which was; we needed to do some filming. Rob came along with cameras and lighting and we spent most of a morning and afternoon videoing in my front room. It felt a bit easier than the last time around, but never fun to do, I was hoping that some clever cutting would do the trick! We also chatted about the upcoming Nintendo Switch console and a little about Zelda (of which we are both big fans). I lamented that I didn’t think Nintendo had got their launch timing right; didn’t they know I was trying to make a game of my own and wouldn’t have time to play Zelda, as well!

I worked some very late nights over the next ten days writing a lot of code. We needed the demo to be as good as the first Kickstarter, so I was going to have no choice but to build it with very fresh and untested code for many of the features. Over those ten days I wrote the code to bring the Powerdroids in with the enemy formations and wrote several of the power ups themselves, such as the Astro Mace and Buddy Drone, which I did using various techniques that I hadn’t done before in Unity. There were now only four days left until the start of the Kickstarter, and I suddenly realised something… Hewson we have a problem! I didn’t have a hi-score table in the game and it was an essential feature because we wanted to put the top-ten players into the final game credits. In what probably ended up as the fastest piece of code I would write for the game, I researched and coded the online leaderboard in a single evening, and miraculously it worked the first time. It was only temporary placeholder code for the demo and wouldn’t be re-usable in any way for consoles, but it got us out of a hole.

The night before the Kickstarter I sat down with the demo build – just three levels coded – and it still felt as exciting to play as it did when I first made it on iOS. I told myself, if I can enjoy my own game having spent 18 months in development, then it has to be a winner!

fa6fbaeb6d3bf2e6d3d9402a34899897_original
The Limited Edition USB Cassette reward from the second Kickstarter

Ready

It was the 14th of February and like any well-oiled machine everything had been meticulously planned and we were all just sitting back and having a beer ready for the Kickstarter launch in the morning (ahem, well not quite). I woke for 6am, went for a morning run, and then came back to check the start of the campaign. Kickstarter campaigns are stressful and at no point does a Kickstarter campaign make you feel comfortable. There is worry over getting off to a good start, there is worry that new backers will dry up, there is worry that people won’t enjoy the demo you put together, there is worry that your demo will crash, and there is worry that cunning gamers will find exploits in your game that pull it apart. Breathe Jon! We got off to a fantastic start; half of the campaign was funded in the first day and we were already trending on Twitter. Really, I’m not sure we could have received better backing from everyone. It was a great day, we had gotten so much more right in this campaign compared to the first one, but that’s how life teaches you after all.

In the 1980s when I was a young boy playing games on the ZX Spectrum and C64, one of my favourites was Cybernoid, a game I remember getting for a birthday present. Those graphics, those effects, that music! So, when I saw that the game’s developer Raff Cecco, had downloaded and played my game, well shall we just say that was my personal highlight of the first day. I was so thrilled he liked it enough to back us. As a young boy that would have been a dream come true, and so I savoured the moment.

As a Kickstarter backer, Raff Cecco, also has his name in the game credits, which always makes me smile when I see it roll by.

Rob Hewson

Raff Cecco (0-00-00-00)
Raff Cecco himself backed us on Kickstarter!

The campaign carried on and I enjoyed some of the limelight that we were getting. There were several online publications and video reviews of the demo coming through and everything felt positive. There was so much generosity from the gaming community I could almost just sit at home watching it go by. But I needed to crack on with the code if we were to get this game done in time. Some things that should be quick to do took ages and some things that should take ages ended up being quick. I was adding in the ability for the player to skip through the bonuses on the level completion screen. It sounds simple, just put a key-press in. I wanted it to work so that the bonus scores would roll through if you left them, but if you pressed a button, it would skip to the next. It turns out that I didn’t implement this screen in a way that was conducive to this working. I had just coded each section as a coroutine with delays, and that’s no good for user input! So, I spent an evening annoyingly having to do it properly. That meant adding a proper state machine with key-presses that could easily move the state along while keeping the automatic timings right. Small things that work well tend to go unnoticed, but if they don’t work well the player will pick it out straight away. Sometimes the satisfaction in making a game is all the stuff that makes the game work (and took ages to do) but nobody talks about. That’s when you know you got the design right.

It is also one of the reasons game development can be so difficult to predict. Some things are quicker than expected, others take much longer, but overall no matter how much contingency time you give yourself, the project always seems to eat through it and then some!

Rob Hewson

It was the 26th of February and we were £200 short of the £15,000 goal we set for the Kickstarter. I went for a 15K run that morning to urge it on! The game had started out as an iOS-only game written using Swift and Xcode. That code has been played by lots of gamers, but alas, it would never be the code that goes into production. That iOS code was damned stable and ran non-stop without issue at many game events around the country; it had been a terrific little workhorse for us. So it was with a heavy heart that I had to let it go on that day. The King is dead, long live the King! We had hit our goal and were officially funded. Hyper Sentinel was going to be released. Thanks to the amazing gaming and retro-gamming community, we had done it while still less than halfway through the campaign. That’s was a pretty proud moment.

When I was 12 and 13, I clearly remember playing the Hewson games; my favourite game of all-time, Steve Turner’s Dragontorc and its predecessor Avalon.– those two games were way ahead of their time. I played a lot of Exolon on both the Speccy and later the Atari ST. Uridium, of course, was superlative. Cybernoid was an extravaganza of effects. Just lots of great games that are as clear in my mind today as they were when I first loaded them up over 30 years ago. I wonder what childhood me would have made of it all had I known that my own game would be released by the same company (now known as Huey Games) years later?

During the last week of the Kickstarter I did my first live stream, which was quite fun (much more so than filming for the campaign) and I enjoyed the questions coming in live and just having a good chat with people about the game. I think I also did my first live podcast with Rob at this time too. To top it off, we had a grand finale to the campaign. With just a few hours to go I was wondering if 20K was possible, then almost within the blink of an eye more and more people started to come on board and back the game. Suddenly 21K was a real possibility. Rather than spend the next couple of hours clicking refresh, I decided to go to bed and see what the morning would bring. And bring it did! We somehow managed to get a flurry of backers that took the total over the 21K stretch goal to include a C64 graphics mode! It had been a tremendous campaign. The first day was the most exciting and gave us huge momentum to carry forward and trending on Twitter, was quite cool. We really do seem to have a hugely supportive set of backers, a great mix of knowledgeable retro gamers and people who we’ve met and who played the game at various shows over those previous six months. It was a dream come true, but now it was time to work and get on with making the best game I could. Time stops for nobody.

stretch_goals4

 

Hyper Sentinel LOADING – Part 2

by Jonathan Port

Continued from Part 1 in previous blog entry…

Found: Hyper Sentinel

Development continued for iOS much the same as normal for a few weeks. I was just cracking on with filling out levels and building bosses. It felt like I was getting reasonably close with everything, although at this point there was no delivery plan as I was awaiting design feedback from Rob at Huey Games. At the end of January 2016, a ping from my email came through announcing the design feedback was waiting for me. I was expecting it to highlight a few tweaks here and maybe an addition or two there; the game was nearly done after all! I opened the document and my initial reaction was that it was much longer than I was expecting. I started to read with an expectation that much of the suggested changes would probably be unnecessary and that there would be far less work to do than the size of the document implied. Looking back, I had convinced myself that I had nearly completed the game, simply because most of the levels had been coded. But the more feedback I read, the more I found myself thinking, oh yeah, that makes sense! Or, Yeah, that would be better.  As I arrived at the end of the document, I realised that I hadn’t disagreed with any of the feedback at all. This was my first lesson in what it takes to polish a commercial game. There was a lot of work needed to improve this game. I later discovered that this was only to be the first layer of polish, there would be many more to come in the months that followed.

feedback

You can make a game functionally complete, but that is only the start of making a modern game. I think it was John Ogden who later mentioned something along the lines of: 20% of development time is making a game functionally “done” while the other 80% is what completes the game through layers of polish and player feedback. Looking back, I wouldn’t disagree with that split. It was probably at this time that we also started to inject more Neo Retro ideas into the game, but it wouldn’t be until we redeveloped the code base in Unity, that these ideas really took on a new level of sophistication.

Part of my job at TT Fusion was to give extensive design feedback on all areas of the game. You quickly learn the importance of being detailed, precise and diplomatic. It is not about providing all the answers, it is about putting your finger on the pulse of the project, so the team can collectively discuss the best solutions. This needs to be done repeatedly throughout development to ensure a game fulfils its potential.

From our point of view this document was also an important way to ensure that we were on the same page as Jonathan. Hyper Sentinel was his baby and creative control should always remain with the visionary behind a project. Since we were proposing a co-development partnership, it was important that we all put our cards on the table to ensure our views aligned. If we were going work together to make this a commercial, console-quality game, then we all needed to buy in to the same roadmap.

Rob Hewson

Over the next four months the game improved tremendously. I would work in two-week sprints, sending a build off to Huey Games at the end of each one, which naturally resulted in more ideas and further improvements. It was a very productive time for the game where we developed a lot of ideas; many of which have made it into the final release. A good example of this was the hyper-boost function, which up until this time, didn’t exist in the game. I always had a nagging feeling that the game speed needed to be more dynamic, and then in a bolt of inspiration one evening it occurred to me; if I let the player hold down the fire button, I can implement a speed boost. It was such a simple thing but made such a huge difference to the game and design-wise it’s a natural balance to firing. Tap to fire, hold to boost: but you can’t do both together. It turned the game from simply shooting and dodging, to allowing much more strategic gameplay and is one of, if not the most, important design feature we implemented in the entire project. It might seem such an obvious thing to do, but you have to put it in the context of touch screen controls. At this point we were running on iPad and iPhone where we already had four buttons on screen (realistically the maximum you can have for touch controls on a fast arcade game). The best ideas are always the simple ones, the ones that in hindsight appear obvious.

It was about this time that I also ported the code over to work with Apple tvOS. I seem to remember that it was relatively straightforward and maybe took a week or two whilst also implementing gamepad controls to go with it. This code set became very important to us over the rest of the year, it was the version we took to many expos and used as a live testing ground for real players.

By mid-May of 2016, the game was really coming along and it was time to start thinking about how we would take this to market.

By this point is was crystal clear that Jonathan was a special developer and that the relationship we’d formed was working brilliantly. We all understood and respected each other, and the game was coming on in leaps and bounds.

Rob Hewson

R Tape Loading Error

By May 2016, I had spent nearly a year single-handedly coding the game as well as making all the graphics and animations. It had been a lot of hard work, but fun and rewarding. A few people had played the early version of the game (prior to Huey Games’ involvement), but since that time the game had essentially been on internal lockdown. I think Huey Games may have taken it to show a few people behind closed doors at a few industry events (I recall that Julian Rignall had a play of it at one of them). We now needed to plan where we were going to take the game.

jaz02

That’s right, we took an iPad to GDC 2016, and Julian Rignall, the legendary games publisher, played Hyper Sentinel! It was the first time my father Andrew, and Julian had seen each other in about 30 years, and the first time for me to meet the former editor of ZZAP!64!

We also showed the game to a connection at Apple, who was pleased we planned to release on Apple TV. I believe he was the first to offer the feedback that; bumping into obstacles disrupted the flow of the game for him.

I discussed this with Jonathan on my return to the UK, but although he understood the feedback, he was worried about maintaining the challenge. A few days later Jonathan told me the answer had come to him while out on a run: although the player would be able to fly over obstacles as our friend at Apple had suggested, bullets would still be blocked by them. When this was implemented it instantly felt right, but we did agree to have a “Retro” difficulty mode in the final game, which would maintain the obstacle collisions with the player ship.

Rob Hewson

The idea all along was to release on multiple platforms including console. The game was in pretty good shape, it played well and most importantly, it was fun. Everything seemed to be set, apart from one slight issue that had been nagging at me for quite a while. The game was only running on a mobile platform, specifically Apple hardware. The game was written in the Swift programming language using Apple’s proprietary game engine, SpriteKit. If we were to release multi-platform we were going to need to port the game in some way to be able to run on both consoles and PCs. This was far from a trivial issue. We decided that it would be best to move the game over to the Unity engine, which would enable us to target everything we wanted plus, Huey Games had prior experience with Unity. We had some discussions about how we would go about implementing the move and it came down to either porting code or rewriting code. It was going to be significant work whichever way we decided and significant work had a cost. We were going to need to bring in some funds to help move the game over to the other platforms.

Some years previously Andrew and Rob had successfully funded their book; Hints and Tips for Videogame Pioneers through the crowdfunding site Kickstarter. I remember them both saying how surprised they had been with the warmth of reception they received for the campaign. Following on from this they had built up a good social media presence, reuniting with the retro gaming community around the games made by Andrew’s previous companies (Hewson Consultants and 21st Century Entertainment). It all seemed to fit together, another Kickstarter campaign would be a good avenue to raise the necessary funds needed to support both the console and PC development. We already had a good game with a playable demo, which was essential because raising funds for a new game on Kickstarter was fast becoming a difficult ask of potential funders, without a playable demo. Fortunately we had one that was already well polished. Andrew and Rob had experience putting together a successful Kickstarter campaign and John Ogden had a videogame development background that would lend us technical credence. It all made sense.

kickstarter-logo-color

We wanted to get going as soon as possible and Rob didn’t waste any time getting the wheels turning. It came together quickly but there were still a few things that needed to be in place. One of those was an action-packed and attention-grabbing piece of artwork for the game.

The cover for Andrew’s book had been produced by Mike Berry, who had also created some terrific Voxel art dioramas of Hewson hits such as Exolon and Uridium. The style seemed to fit Hyper Sentinel well, so Rob contacted Mike to see if he would be interested in making an original piece for the game. Thankfully Mike agreed and it was very much a collaborative approach that we took. To start with we chose a level from the game that would be a good fit for Mike to model. We went with Level 3 due to its striking purple colour and interesting design. I seem to remember pulling out various in-game assets that we would send to Mike to model out in Voxel 3D. Then Mike would send us back multiple renderings with slight differences so we could choose our favourites. The process went both ways though and it was at this point that we decided to throw away the existing Hyper Sentinel logo and Hyper Sentinel spaceship and rebuild them both. This was all happening just a few weeks before the Kickstarter campaign was set to begin! Rob had been showing our game demo behind the scenes to some trusted friends and feedback was that the game logo was difficult to read – I think someone even thought it was written in Japanese!

Hyper Sentinel 3

The final logo that we went with was made very spontaneously over an evening. I produced about four versions with slightly different styles and colouring and then Rob, Mike and myself all voted for our favourites. The Hyper Sentinel logo we have now was the unanimous winner.

App Title Logo

The Hyper Sentinel spaceship in the game came about through the process of Mike, creating the cover art. The original art asset simply didn’t render well in Voxels, which requires a certain amount of detail so that the 3D model stands out. The original spaceship was too subtle to render well, so I started from scratch with a brand-new spaceship concept with Mike doing various 3D renders: some had wings hanging low, others angled upwards.

set 01

After various tweaks and voting we decided to go with the version that had a poised attack style. That is the one that made it to the final game. This approach has been very much a theme in the development of the game: collaboration and cross development of ideas. I think the final cover art really catches your attention and it looks unique and stunning.

Titled Hero Art

The feedback regarding the original logo came primarily from my sister, Charlotte. She has a graphic design background and a keen eye for detail, and she found the word “Sentinel” very difficult to read. When I look back at the old logo now it is striking to me how obvious it is that “Sentinel” is difficult to read, but I had grown accustomed to it at the time. That is why getting fresh eyes to review your work is so important.

Working with Mike Berry was an absolute pleasure and he was very accommodating to our iterative approach to creating the cover artwork. Jonathan, Mike and myself went through several review cycles agreeing to the next tasks step-by-step, and we couldn’t be happier with the result.

Rob Hewson

By the start of summer there were a lot of things going on. Rob was organising various events where he could showcase the game, and I there was even a teaser competition being carried out over social media. Rob was in contact with a lot of people in the retro community and had also arranged for a piece in Reset magazine for the C64, which was to coincide with the launch of the Kickstarter campaign. I was taking a holiday at the time and did the interview on my phone while sat in bed in a caravan. Good times!

The Kickstarter was scheduled to start on July 1st, 2016. I remember waking up that morning and watching my phone as people backed the game, but I had to leave before too long so I could get to work on time. On the very first day of the Kickstarter campaign we got an unexpected feature on the Eurogamer website. I had been out with a colleague for my regular lunchtime run and when I came back everyone in the office was congratulating me. It was a great little feature and a complete surprise. I spoke to Huey Games over email and they seemed as genuinely surprised as I was. It was a great write up and we had some really good comments from it. We were working hard during that Kickstarter; we did a games show in Leeds with the game available to play. We had a lot of the retro community shouting out for us as well. I even got the chance to chat to an Ex-Rare coder who had worked on Donkey Kong 64 (I played this game to death with my wife during the Christmas of ‘99), which was a fantastic privilege for me. Here I was with my little game and I was chatting with someone who was excited to play it and who had worked on one of my favourite N64 games – dreams really do come true!

Unfortunately, our first attempt at the Kickstarter campaign wasn’t to be. By about the halfway point it was becoming clear that we weren’t going to make it; we ended the Kickstarter having only reached half of our funding goal. I think there were several reasons: we only had a demo on mobile, consoles were a stretch goal, too many pledge tiers causing a lack of focus. It was a bit of a Catch 22 though. We needed to raise the funds for a rebuild of the game in the Unity engine, but to do that we really needed the demo available on PC. We didn’t have a demo on PC because that required us to have the game in Unity. Despite the Kickstarter failure, we did get a good amount of backing from the retro gaming community and made lots of friends along the way. We didn’t know it at the time, but ultimately this is what set us up to fully realise the game on Console and PC. However, in that moment, the path ahead remained unclear.

I don’t think it is possible to overstate how important it was to have so much support from the Kickstarter backers and the wider retro community at that time. If they hadn’t cheered us on in the way that they did after the Kickstarter failed, things might have turned out very differently.

Rob Hewson

explosion 1

Hyper Sentinel LOADING – Part 1

by Jonathan Port

Instruction Manual

Before we dive in, I would first like to mention what a relief it is to tap these words on a keyboard, with the knowledge that the game is finally finished. At the end of an extended project there is always relief that you did it. It doesn’t matter if you started out with absolute confidence or with worrying doubts – finishing anything that you have worked so hard on is always incredibly satisfying. But this game wasn’t just another project.

Think back to when you were maybe ten or eleven years old, can you remember your favourite thing? Maybe it was a memorable film, or a catchy song. Perhaps it was a toy you took with you everywhere. And maybe, as it was in my case, a computer game had the biggest impact. As an imaginative young person, you also probably dreamed that one day your name would be credited with creating that seminal film, a great song, or an amazing computer game. Maybe that happened, maybe it didn’t. For me, as time slipped by and over 30 years passed, I never really stopped imagining that the dream I had as a young lad might one day come true.

And then it did. Please enjoy the story of how it happened.

 

Titled Hero Art

The first spark of an idea to make Hyper Sentinel came to me while I was on a holiday in sunny Spain back in the summer of 2015. A lot has happened since then, and it would be tempting to use this opportunity to write events down in a standard diary format. The reality of making a game though, is that much of your time is taken up by the routine and often mundane work of simply getting your head down and cracking on through. That’s not to say that nothing interesting has happened over this time, quite the opposite in fact!

This isn’t going to be your standard development diary, nor will it be an overly technical breakdown of how the game was made (the process, the tools, etc.). When I was building Hyper Sentinel, I always tried to stop regularly and ask that all-important question: where is the fun? While it may be interesting to focus on just the technical process of making a game, I don’t think that would be particularly fun. I didn’t set out to make a game that was just interesting to play – nostalgically or not – I set out to make something that is fun to play. So, instead of being a complete diary or a process, I am going to look back and pull out the events, details and anecdotes I think you will find the most interesting and the most fun.

Well, in the interests of keeping it fun, I suppose I ought to jump in with the odd comment here and there, just like in the magazines of old!

Rob Hewson

PRESS PLAY ON TAPE

I’m fairly certain that the first game I owned was a Grandstand game called Astro Wars (I had a chance to play one again recently which was quite a treat!). For those who know, the game played a little like a mix of Space Invaders and Galaxian. In Astro Wars, you controlled a ship at the bottom of the screen and had to clear the waves of enemies that circled above you. Successfully clearing all of the enemies triggered a tricky docking sequence. The game was housed in a boxy silver case with a screen that sat up so that you could place it on a tabletop. There were a few other similar electronic games by Grandstand at the time, such as Munchman, housed in a splendid yellow case. Perhaps I chose Astro Wars over the others for a Christmas present, or perhaps it was bought as a surprise. Regardless of how it happened, space shooters have been one of my favourite type of games ever since.

tbltp-gm002-620vintage20grandstand20astro20wars_a-max-800

Growing up playing home computer games in the early 1980s really was a privilege; I don’t think there has been a period of creativity and variety that has matched it since. I’m sure there are many reasons why this may have been the case, but chief among them was that anyone had the chance to make something, assuming you could afford the computer of course. There were no barriers to entry and age didn’t matter. Variety was not hard to find, if you wanted to be a pilot, an adventurer, or a robot for the afternoon. Even a coal-collecting mole (with a political agenda that passed me by at the time) got a look in! Let’s just say that if you grew up during that period, any game you create today likely bears the influence of those early classics.

As I sat down in the Spanish sunshine with a long gin and tonic in hand, I cast my thoughts back to more of the games I used to love playing during those days. There was a game called Tornado Low Level (T.L.L. – Costa Panayi) that had you piloting a Tornado jet fighter over a super-fast scrolling map with scenery obstacles that you needed to avoid. You had to fly really low to the ground to disable all the ground mines; it was a tricky game. There was something that game had that made it a bit special though – you could sweep back the wings of the plane and fly at supersonic speed! The game could be played perfectly well without it – it didn’t actually need that feature – but that feature was where the fun was! There was another game I remember playing on the ZX Spectrum, called Orbiter. I didn’t know it at the time, but Orbiter was actually a home computer clone of the legendary Williams classic, Defender is still an absolute masterpiece and hasn’t aged a day – a wonderful mix of speed and precision blended with lovely chippy sound effects. The magic and the fun of that game was its lovely one-shot kills accompanied by screen-filled particle explosions. Take some time and watch a video of Orbiter alongside Arcade Defender. You’ll notice there was quite a gulf between home computer games and video arcade games of the time.

The first time I saw Uridium (Andrew Braybrook) playing on a friend’s Commodore 64, was quite a moment. Here was a game that was super slick and smooth, running on a humble home computer. You could spend hours playing, just zooming around and doing the flip-roll manoeuvre without really caring about much else. It was just fun to be the pilot of a super agile spaceship, dodging and weaving and hoping to survive. If you were good enough – or lucky enough – you even got to see the set piece end-level destruct sequence!

c64-wuridium-cover

Thinking back through these games, I could see they each had an element of something in them that was just fun to play, something you didn’t have to work hard for or earn the right to. All you had to do was pick up the joystick and play. The more I thought about it, the more other examples popped into my head. I’m sure most people reading this will have played the classic game, Space Invaders. It’s a good game, although a bit of a grind until you get through half the invaders, that’s where things really start to heat up and, of course, that special moment when the saucer comes in to view with its own signifying sound effect. You need to hit the saucers to get a good score in Space Invaders. The fun of Space Invaders is timing; that shot made just right to hit the saucer (without losing focus and a life to an enemy bullet).

post-34769-0-24767200-1365376650

As I sat there on the beach sketching out some ideas on a pad of paper and sipping my chilled glass of gin, I thought about what kind of game I would like to play, and how it would be fun. I knew at this time, I wanted to make a game that played like the games I grew up with. I wanted to incorporate some of those elements that had stood out to me from these games.

I knew the Alienoid passing across the screen (and the associated sound effect) reminded me of something! I’m not sure if we discussed this influence before and I have forgotten, but it makes perfect sense.

Rob Hewson

It had to be instantly accessible, easy to control, with a fast and smooth scroll. There would have to be plenty of action and things to shoot; shooting the baddies’ ships had to give instant reward.

Looking back in your memories at the games you used to play can be a little deceiving and nostalgia itself can deceive us. Our brains are deeply wired to remember the good things while smoothing out any of the bad, until most of that memory appears good. We don’t always remember the limits of the hardware at the time, some flickery movement here a bit of jerky animation there, a steep difficulty spike (designed to stop you from completing a game too soon). So instead of trying to emulate these games I decided it would be more fun if I tried to create a game that played the way you imagine games used to play in the 8-bit period of the 1980s. A game that stood on the shoulders of giants while using current technology to give a thoroughly modern nostalgia trip. This was my vision of Hyper Sentinel.

This philosophy is very astute, and it immediately told us that Jonathan was somebody who knew exactly what he was doing. It also provided the foundation for what we now call our ‘Neo Retro approach’, which continues to underpin all the thinking around the project.

Rob Hewson

After returning from the sun I got to work on prototyping and experimenting with some of these ideas. I already owned all of the tools I needed: an iOS developer account, a Mac and an iPad. Output on iPads are automatically VSynced, which basically means they are locked to 60hz for a nice smooth display. If your code falters you will get lost frames as the display waits for the next update. So right from the start of development, 60hz had always been the only option for this type of game. The first thing I did was to get a basic ship on screen that could fly over a scrolling background. It quickly became apparent that flat coloured backgrounds worked better than those with too much detail. Even at 60hz, small pixel details get turned into a blur when using the high-speed scroll that I wanted for Hyper Sentinel. Rather than look nice, that pixel detail starts to streak the display. Next up was, creating dynamic enemies, I wanted to have the enemy ships fly by in formation groups that would change both shape and pattern as they moved. It seemed to work well having them fly back and forth a few times, giving the player a chance to hunt them down. I put together a basic tile set for a first level and after a few weeks had the basis for a game up and running. I started to think about gameplay objectives and after a bit of experimenting it seemed that having to clear targets on top of the enemy decks that you were flying over would work well. Even at this early stage, the game was starting to have the feel of those elements that I had previously thought about trying to incorporate. I started a second level layout, but this time introduced a new enemy to the mix: one I would later name, a Hunter! I thought it would be nice to have each level progression introduce a new element into the game, something that would surprise the player. Things were hanging together well. I introduced a large gun turret as the end-of-level boss for the first level and decided to video it up and throw it out there to get some early opinions.

In my excitement, I might have mentioned that Hyper Sentinel would be, ‘coming soon’ even though I only had a couple of basic levels and a few enemy types coded in. To my surprise, it somehow managed to catch a bit of traction. It got picked up in an article by Touch Arcade (a website devoted to mobile games) and in a screenshot section of a popular indie gaming website. It looked like I was on to something! At this time the aim was a six-month development cycle, which meant the game was intended to launch sometime around January 2016. I had about four months of development time to make a game for the Apple App Store. It was around that time when I realised I needed to get some game music in place. As it happened, at that same moment, Rob Fenn (Fractures Music) had come across the Touch Arcade article and was interested in working with the game. This was my first piece of good fortune; Rob Fenn already had an established track record for producing incredible music for games. After an email or two Rob agreed to work on some music for the game even though I was still very early in development, but as it turned out, we were both based in the same neck of the woods in Manchester, England. This was the start of the Manchester team, or as we later tag lined it, ‘Made in Manchester’.

00 Soundtrack Album Cover

Searching

Within a few weeks, Rob and Fractures music had produced some amazing chip tune theme and level music. During that period, I decided it would be worthwhile to put together an early-access open beta so, I continued to put the hours in to get a playable game together. I am a full-time professional business programmer by day, so all the work had to be done during the evenings.  Making a game is a lot of work and it really does pay to plan ahead. I used my relatively long daily commutes to work out designs, solve problems and set milestones for myself. By November of 2015, I had a working beta up and running complete with a title screen and level select options. I had already picked up a small amount of momentum for the game on Touch Arcade, so it made sense to distribute some beta codes through the forums on the site and get some real feedback. Anyone who has tried to make a fast-paced arcade game on a touch screen mobile platform will sympathise with me at this point. I had put a control scheme in place that I thought worked well: up button, down button, fire button and a button to flip the ship around. The ship moved at a constant speed, but to give the player a little more control on the touch screen, it would slow down a little as you fired your lasers. Initial feedback was completely split on the controls; some wanted absolute control position, others wanted a virtual stick, some players wanted sliders to move and others thought the controls were already great. What to do?

I was lucky enough to bump into some great people on Touch Arcade who really put the hours in to test the game and give proper detailed feedback. I continued to work on the game, tweaking and changing things around here and there. The gameplay itself was coming together just fine, but the controls continually caused issues; it’s hard to make touch controls that suit everyone. I had yet to implement physical controller support, although this was never going to be a solution in itself because very few mobile gamers own them. It was around this time that I received my second bit of good fortune: a colleague at my daytime job, Tim Keenan, posted some screenshots and a video link of the game on a forum for indie game developers. The exact order of events that followed are still a little unclear, but somewhere along the way a person named Rob viewed the images and video of Hyper Sentinel and posted a comment saying he liked the look of the game and that if I sent some more media links he would share them on his Twitter feed. The Twitter account it turns out was, Hewson Joystick and Rob was in fact, Rob Hewson, the son of Andrew Hewson of Hewson Consultants fame! I was shocked, to say the least: a little unknown mobile game being made by my humble self was going to get a chance to be shown to a horde of retro gaming enthusiasts.

Uridium is one of the first games I remember playing. In fact, I remember learning how to spell my surname from the title screen. When I saw the first video of Hyper Sentinel, I obviously recognised the Uridium influence and thought it would be something fun to share with our community on social media. Then I noticed all of the original elements – the power ups, the boss battles, the enemy gun turrets, the Space Invaders style Alienoids – it was clearly a game developing its own identify so I knew I had to play it.

Rob Hewson

But not just that, Hewson Consultants were one of my childhood legends, and publisher of my favourite game of all-time “Dragontorc of Avalon” by the Steve Turner. Before the dust had settled, I learned that Rob Hewson lived in Manchester too. Not only that, he was popping in to a local indie game developer meetup in Manchester in a few days’ time. It so happens that my colleague Tim regularly attended these meetups too and offered to bring me down with Hyper Sentinel to show Rob for real: this was to be my third piece of good fortune. By the time the arrangements had been finalised I had just one day to cut a build of the game to take down and show.

250px-dragontorc

But I had a problem. The touch controls were bust. I had been trying various schemes in the hope of achieving a balance that would suit all my beta testers, and everything was becoming a bit of a mess. I would later learn that it is best to offer a few different options instead of trying to balance a single control scheme for everyone, but at that moment in time I only had one broken control scheme. I spent the whole of that evening and well into the wee hours of night, putting in an options page with various sliders and buttons in an attempt to give the player some control adjustment. I then quickly cut a build for the next day. I didn’t know what to expect, this was all a bit out of my comfort zone. I had no real idea what was going on to be honest, but maybe that was a good thing. The gameplay was in a pretty good state, but the controls sucked and I knew it. I met Rob in a pub in Manchester (along with a host of other indie game developers) and showed him the game. I remember his opening comment was that he really liked the font used as the game started up. Rob played the game and I could see the controls weren’t great; but Rob didn’t let on. He was pretty good at picking them up and was quickly playing through several levels; I figured that this was a good sign. Rob seemed very enthusiastic and we chatted in detail about various elements within the game. That night, we ended up agreeing to keep in touch and speak again after Christmas (this was early December). What an exciting opportunity!

This was in the Port Street Beer House in Manchester’s Northern Quarter. It was clear that the game had potential, even in that early build. I do remember that the controls needed some work, but it wasn’t anything that couldn’t be solved with some careful thought and discussion.

Rob Hewson

True to a promise, Rob contacted me after Christmas wanting to chat some more about the game. He asked if it would it be okay if he popped over to my house in a couple of weeks along with John Ogden (Technical Director at Huey Games) and, oh by the way, his dad Andrew Hewson? Andrew Hewson, to my house for a chat about potentially working together on Hyper Sentinel? I think my reply was, ‘Err, yeah okay that would be fine’, in a typically British and understated manner. This was undoubtedly my fourth piece of good fortune.

If you were a young kid who played games on your C64 or Speccy during the 1980s, you are surely familiar with Hewson Consultants. Over a period of many years Hewson Consultants produced a consistent string of top-quality hit games. They published some of my all-time favourite games and I’m sure many of you reading this will have similarly fond memories of their games and the names of our heroes behind them. Imagine for a moment how I was feeling, having Rob and his dad Andrew turn up to my house to talk about my game! The only way I can descried it is: this was an incredibly surreal moment.

20131107-FEED-HewsonInterview - Copy

It was a great day, I can remember it very clearly and always will. We played the game, John checked over my code, we chatted about old games and Andrew talked about how the industry used to work and some of the great programmers he worked with. I nearly forgot to offer anyone a drink, which normally would be seen as a little rude, but I think given my excitement level, I can be forgiven this once. Everyone was happy to see where we could take the game and the plan was to get a build of the game for Rob, so he could have a proper play through. Rob would then put together some professional design feedback and assistance. The partnership with Huey Games had begun.

Jon, Rob, John, Rob and Andrew – this was going to be fun!

It was a memorable day for me too. I was still serving my notice as a Game Director at TT Games (TT Fusion) and John Ogden was in a similar position, so this was right at the beginning of our Huey Games journey.

One moment that sticks in my mind is when Jonathan pointed out that the ship slows down almost imperceptibly when shooting in that early build. It was that sort of nuance which, with my designer’s hat on, showed me that not only could Jonathan program, create brilliant pixel art and produce fantastic sounds effects, it showed me he also had great design instincts. My Dad was particularly animated in his appreciation of this touch, as he understands better than most that it is this sort of elegant thinking which is the hallmark of only the most talented developers.

Rob Hewson

 

Neo-Retro: a design philosophy for Hyper Sentinel

Nostalgia has had an interesting history. The term was originally coined in the 17th-century by a Swiss physician to describe the anxieties of soldiers stationed far from home and was considered a disorder up until the late 1990s. Today, thanks in no small part to research carried out at the University of Southampton, the emotional significance of nostalgia is better understood.

“Nostalgia, once evoked, re-establishes psychological equanimity. It elevates mood, self-esteem, and a sense of social connectedness; it fosters perceptions of continuity between past and present; it increases meaning in life; and it ‘fights off’ death cognitions. Finally, nostalgia has motivational consequences, as it facilitates approach-oriented (e.g., prosocial) behaviour.”

For the entertainment industry, this will come as no surprise. From Stranger Things to Ready Player One, the indulgence of nostalgia has proved to be a winning strategy in TV and film, and with the best part of four decades of video gaming behind us, nostalgia is ripe for game developers to exploit too.

142027593-980x620
Nostalgia is powerful in the entertainment industry

Enter Neo-Retro game design. If retro gaming is collecting and enjoying classic games, the equivalent to owning and watching old movies, then Neo-Retro is the equivalent of Stranger Things – a modern entertainment product which weaves nostalgia throughout the experience.

Neo-Retro games like Resogun, Lumo, Broforce and Hyper Light Drifter, to name just a few, successfully inject a blast of nostalgia into a contemporary gameplay experience. The extent to which each game embraces its retro influence varies – pixel art graphics and a chiptune style soundtrack are not necessarily a requirement – but all of these games are unmistakably new experiences which embrace nostalgia knowingly.

screenshot3
Broforce – a great example of Neo-Retro design

When Jonathan Port conceived of our recently released game Hyper Sentinel, he told we at Huey Games that he wanted to create a game which felt like 8-bit games did in his imagination when he saw screen shots in CRASH magazine or ZZAP!64 back in the 80s, rather than the often-disappointing reality of replaying those games today. Distilling this philosophy and identifying it as Neo-Retro, which we think of a distinct genre which is yet to be widely acknowledged, provided us with important focus for the project.

Titled Hero Art
Hyper Sentinel was conceived from the outset as a Neo-Retro title

Mark Brown’s principles for nailing nostalgia

As with any design philosophy, the successful production of a Neo-Retro game is about method and execution. As Mark Brown so eloquently explains in his excellent YouTube analysis “Shovel Knight and Nailing Nostalgia”, there are principles and best practices which set successful Neo-Retro games apart.

He identifies four below, which served as a starting point for Hyper Sentinel:

  1. Take from multiple sources

Rather than emulating one classic game, borrow from multiple sources, creating a rich tapestry of nostalgic references to enrich the experience and capture the feel of a whole era rather than a single game.

When people see Hyper Sentinel for the first time, they immediately notice the stylistic influence of Uridium, the iconic Commodore 64 shooter created by retro gaming legend Andrew Braybrook. Uridium was published by Hewson Consultants (a company founded by our own Chairman Andrew Hewson), in 1986, and when Jonathan Port first showed us an early build of Hyper Sentinel, it was this influence which caught our attention.

However, when you dive in and play Hyper Sentinel, you will find that the speed and feel of the gameplay is more reminiscent of Defender, and that the power-ups and boss battles evoke memories of Armalyte and R-Type. Some of the Alienoid enemies reference Space Invaders and there’s a touch of Cybernoid to the explosive pixel effects. Meanwhile the boost ability was inspired by TLL (Tornado Low Level) and the boss music was influenced by the Doctor Robotnic theme in Sonic The Hedgehog.

influences
Uridium and Defender were arguably the biggest influences on Hyper Sentinel, but there were several others
  1. Emulate What Works:

Capture the best bits from classic games, such as the instant plug-and-play nature of the experience, the simple control systems or particularly cool mechanics.

Hyper Sentinel emulates the immediacy of classic arcade shooters, providing an experience which is easy to play but difficult to master, and the elegant simplicity of their controls. There is also a purity about the game which keeps players engaged from one level to the next without an overly intrusive storyline getting in the way. The game is unapologetically an arcade experience.

  1. Modernise What Doesn’t

In our rose-tinted memories, we exaggerate the best elements of classic games and forget the worst. Things like the punishing death systems, lack of checkpoints or thin, limited game modes. This is where modern designers can get creative and weave in contemporary game design principles.

In Hyper Sentinel, the “3-lives + continues” legacy of the arcades is replaced by a contemporary regenerating health and checkpoint system. We have found that even the most dedicated retro fanatics, who appreciate the arcade influences of Hyper Sentinel the most, did not notice or care that this is fundamentally different from the arcade classics of yesteryear. Checkpoints are now an expectation.

Following the success of our Kickstarter campaign, we’ve also been able to add Survival and Boss Run modes, in addition to the core Arcade more, and have included 60 medals for players to complete in modern, meta-game style. These allow the player to choose different goals while adding replay appeal to the experience, again a modern expectation amongst all generations of gamer.

Finally, just because you’ve been inspired by the past, that doesn’t mean you can’t look to the future. For Hyper Sentinel, we teamed up with the Mixer team at Microsoft to implement a cutting edge MixPlay mode – the worlds first interactive livestream arcade game.

assos
Hyper Sentinel on Mixer is the world’s first interactive livestream arcade game
  1. Give it a Rose-Tinted Look

If you are considering a retro aesthetic for the graphics, make sure you are doing so for the right reason. In Hyper Sentinel, the 8-bit visual influence is not just a stylistic choice – the high contrast, crisp pixel art style has been specifically tailored to aid readability when enemies are flying at you thick and fast.

And if you do decide to give your Neo-Retro game a classic look, that doesn’t mean you should stick religiously to the technical constraints of a bygone era. Keep the style, but ditch the limitations.

Hyper Sentinel is like 8-bit on steroids. As you might expect, it runs at as blistering 60fps in 4K resolution, but we are also filling the screen with enemies, spectacular bosses, and explosive lighting effects which would not be even remotely possible on actual 8-bit hardware.

1.png

And while the soundtrack is very much chiptune in style, the SID chip, mighty as it was, could never dream of producing the richness on offer here.

Some Neo-Retro rules of our own

The general principles in Mark Brown’s Shovel Knight video provided an excellent starting point, and if you are developing a Neo-Retro game, I’d strongly recommend watching it.

However, Shovel Knight is a platformer, not a shoot ‘em up, so for Hyper Sentinel, the next step was to drill down into these principles to determine a checklist of crucial criteria specifically for Neo-Retro shooters. We divided this checklist into two categories; Neo, where we were considering the contemporary angle and Retro, were we were considering nostalgia; the yin and yang of our Neo-Retro philosophy. It included the following:

  • Contemporary Challenge (Neo): Classic shoot ‘em up games were challenging in the extreme because they were emulating arcade games and because they needed to get maximum play time from the minimal content developers could cram into a few kilobytes of memory. Today they feel overly punishing, but when players experience a Neo-Retro game they are not making a direct comparison. Hyper Sentinel needed to feel challenging in a modern context, so players are kept on the edge of their seat. We wanted people to have the perception that Hyper Sentinel is a hard-as-nails shooter, just like classic arcade games, without being as unforgiving in reality.
  • Difficulty Options (Retro): Having said that, while players should not be required to experience the brutality of a classic shooter, why not give them the option to do so? This led to the inclusion of the ferocious Retro difficulty mode.
  • High Score Heaven (Retro): Classic arcade shoot ‘em ups were all about chasing high scores, and we wanted this to be at the core of the Hyper Sentinel experience.
  • Medals (Neo): High score chasing alone would make Hyper Sentinel feel a bit one-dimensional. Including a medal system, Survival Mode and Boss Mode would provide players with the freedom to pursue other goals while adding replay appeal.
  • Juicy Feedback (Neo): The best modern games include multiple layers of feedback for every event in the game, creating a sense of dynamism, sometimes referred to as “game feel”, which classic games lacked. We wanted Hyper Sentinel to feel ultra-fast, just as classic shooters like Defender did, but with so much more happening on screen a rich set of intuitive cues for the player was essential to keep them in the zone.
  • 4K, 60FPS (Neo): Classic shooters dazzled us with graphical showmanship, fighting to provide a feast for our eyes across a crowded and noisy arcade. It goes without saying that Hyper Sentinel needed to run at 60fps, in 4K resolution.
  • CRT Filter (Retro): On the other hand, if you want to bathe in the nostalgic glow of a curved, CRT-style display, you should also have that option.
  • Spectrum & C64 Filters (Retro): Why stop at CRT? Thanks to successful stretch goals on our Kickstarter campaign, players can also play in the graphical style of their favourite 8-bit system.

Neo-Retro marketing

Having embraced the Neo-Retro philosophy in development, we began to explore how it could also influence our marketing and PR.

The USB Cassette pre-order edition of Hyper Sentinel, conceived as a reward for our successful Kickstarter campaign, is itself the epitome of Neo-Retro. An authentic cassette jewel case houses an authentic cassette inlay and an authentic cassette shell, but the magnetic tape inside has been replaced with an eight-gigabyte USB drive packed with special features and bonus extras, including several Neo-Retro game demos from other Indie developers. It was a huge success on Kickstarter, and never fails to delight the punters when we show it off at expos.

collectors2.png
The Hyper Sentinel collectors USB Cassette

Even the Kickstarter stretch goals were conceived from a Neo-Retro point of view. Although we knew the CRT, C64 and Spectrum graphics modes would capture the nostalgic hearts of our backers, Survival Mode and Boss Run Mode, two contemporary gameplay options, had to come first, because they were a crucial for delivering the depth and variety which modern players expect.

Reaching the Neo generation

Identifying Neo-Retro as a distinct genre and applying its principles to Hyper Sentinel has provided the framework for our entire production process. The payoff has been most apparent when exhibiting at expos, where we have found a diverse audience engaging with the game enthusiastically.

One gentleman, passing our stand with his young son, was drawn to Hyper Sentinel because it reminded him of the classics he played in his youth. He drooled over the USB Cassette and beamed when we showed him our collection of original Hewson games and signed copies of Sinclair User. His son, on the other hand, wasn’t particularly interested in any of that. He simply sat down to play Hyper Sentinel and set about beating the day’s top score.

When the pair returned for a second time later that afternoon, the father gestured to his son, who had jumped back into Hyper Sentinel enthusiastically, and said to me “he actually came here today to play Minecraft, but Hyper Sentinel is his favourite game of the show”.

Hyper Sentinel was brought to life by the passion of the retro gaming community, but if by embracing a Neo-Retro philosophy we can also engage a new generation of players, we will be satisfied indeed.

The Development Diamond: Modelling the Anguish and Despair of Game Production

Last year I was invited by a former colleague to give a talk about project management to game development students at Manchester Metropolitan University. During my career I have held the role of both lead designer and game director, but since I have never actually been a project manager, my initial reaction was to submit to the creeping sense of impostor syndrome the invitation had provoked.

Having recently made the move from the world of big budget, big IP development to running a small indie studio, I realised that I could no longer afford to pretend that project management was somebody else’s responsibility. More importantly, if we were to flourish, I knew I had to slay the demon of impostor syndrome whenever and wherever it raised its ugly head. So, I accepted the invitation, and set forth into the darkest corners of my memory, in search of the dreaded closet of development nightmares I had buried there.

Instead of applying the experiences I found to models pulled from project management textbooks, which presumably the students had studied to death, I thought it would be fun to create a new model to properly encapsulate the sense of anguish I wished to impart.

The model I came up with is called the Development Diamond, and this is how it works:

A Universe of Problems

Often, when we measure the progress of a project, we look at tasks and bugs. These are assigned to team members, and the rate of resolution versus the rate of creation gives us a sense of project’s progress.

However, tasks and bugs are but a drop in the ocean. They are well-defined subsets of a much larger universe of problems which amounts to your project. That’s right, your project isn’t made of ideas and mechanics or art and rainbows. It is, at the quantum level, nothing but an infinite soup of problems.

problems0

Not all problems can or should be formally encapsulated in a task, but we need to be aware that for every task and every bug there exists a multitude of additional problems which affect the progress of the project. Here are a few examples:

problems1

Here is the Venn diagram again, this time with every potential problem I can think of:

problems2

This universe of problems is both vast and constantly evolving. After the big bang of entering production, it will and must inflate, but more importantly it must at some point begin to contract back towards a big crunch if you want to release your game. This, of course, is the tricky bit.

The Development Diamond

The Development Diamond is a way of encapsulating this idea of inflation and contraction. For the ideal project it would look like this:

a

Start: A singularity of infinitely exciting ideas erupts in a big bang, and we plunge into the unknown convinced that it will be the best project yet, and that “this time it will be different”.

Inflation: The period of inflation is a cauldron of problem creation, as design documents, art tests, prototypes and plans conspire to rapidly expand the scope of your project.

Turning Point: Somewhere before the turning point, the high-level structure of your game materialises and you can now comprehend the bigger picture. You’ve stopped adding new features, and at the turning point you begin to sense that you are now solving problems faster than you are creating them. Since this is the ideal project, the turning point occurs about one third of the way into your allotted time.

Contraction: With the turning point occurring early, you have an extended period to continue solving more problems than you create as you gradually collapse the project towards completion.

Release: Your game is alive, and you have created and solved all the problems you needed to reach a releasable state.

Finish: As Leonardo da Vinci said, “Art is never finished, only abandoned”. Somewhere beyond the actual release of your game is the theoretical “finished” state. Like a mirage in the desert, you can never actually reach this point, but if you’ve done a good enough job, your consumers won’t know about it anyway.

Meanwhile in Reality…

The ideal Development Diamond, if it exists at all, can only be observed in hindsight. When we recall a project from memory, we subconsciously edit the tedious bits out of the narrative. If you are lucky you will believe that you have experienced it at least once in your career, but this is probably just rose-tinted spectacles playing tricks on your mind. I believe that I have come close to experiencing it once, maybe twice, but I am almost certainly wrong.

In reality, the Development Diamond of your project will end up looking warped, stretched, and mutated, like something out of the lab scene from Alien Resurrection.

alien-resurrection_0

Here are three monstrosities let loose from my aforementioned closet of development nightmares:

1. The Whale of Glutinous Over-Scope

b

We all know the rule: never go grocery shopping when you are hungry. Similarly, you should never define the scope of your game when you are excited by the possibilities of your awesome ideas. If you do, you will end up with an extended period of inflation, leading to a delayed turning point, an intense contraction period, and a broader set of unresolved problems on release. This bloated beast can be painful to give birth to, but if you battle through, you can still end up with a great game at the end of it. Then, when a journalist casually comments that the game is “a bit on the small side”, you can indulge in a face-palming session of Picard-like intensity.

618px-JeanLucPicardFacepalm1-e1319987031577

2. The Tadpole of Piss-Poor Planning

c

Just as your project is about to start, all of your plans are turned upside down by the decision to overhaul the development pipeline at the eleventh hour. Or perhaps there was no plan, and you are thrust into production completely rudderless. Maybe your entire team are pulled onto another urgent project, leaving you with a skeleton crew as you set sail into uncharted waters.

The deadline for releasing the game is immovable, but forget about solving problems more quickly, you are not even CREATING them fast enough to properly kick-start the inflation phase.

3. The Mutant of Eternal Despair

d

The mutant of eternal despair develops multiple tadpole tails, each one emerging from the last, because not only is it poorly planned, but the fundamental design of the game keeps on shifting beneath your feet.

Goalposts aren’t just moved further away, they are uprooted and launched into entirely different stadiums. The cause might be difficult-to-tame technology at the heart of your project or loose cannon, nutcase managers. Perhaps it is the result of an overly ambitious, unrealistic design or the switching of publishers half way through. Perhaps it is a mixture of all of the above.

If you are lucky, this abomination is mercifully euthanized — shot dead by concerned investors, or slowly suffocated by a dwindling team, as bleary-eyed developers question whether the games industry is really for them. Sometimes, however, whether through grit and determination, pure tenacity or naked naivety, the turning point is eventually reached, albeit years later than planned, and with a drastically reduced scope, the mangled project finally crawls towards release, amidst mutterings of, “I no longer care if the game is any good, it just needs to die” from the team.

Killer of companies, destroyer of souls, the mutant of despair will leave you a shell of your former self, but if you live through it, you will be eternally bound to your teammates, even after they have been scattered to the wind. And when your paths cross again, you will exchange knowing glances across crowded rooms with an unspoken acknowledgement that you are never to speak of it.

Control the Inflation and Reduce the Pain

The mutated Development Diamonds described above represent some of the more difficult projects I have come across, from a production point of view. No doubt you could describe some interesting abominations of your own.

Although the circumstances were different in each of these cases, the fundamental problem was a disruption to the inflation period, which was either swollen (whale of glutinous over-scope) or prolonged (tadpole of piss-poor planning and mutant of eternal despair), leading to a delayed turning point and therefore a bigger set of problems to solve in a shorter period during the contraction phase.

When I cross-reference these with the smoothest production experiences I can recall, the key difference was our ability to control the inflation phase, and if you can control the inflation phase, the contraction phase takes care itself.

That is easier said than done, and even if you do achieve it that doesn’t mean the project will be painless. But there is standard project painful and then there is, in the words of one insightful former colleague; “I no longer see the point in anybody’s existence” painful.

So, how do you control the inflation phase? Here are a few strategies.

Learn to Love the C-word

Picture the scene. Project leads are gathered around the boardroom table discussing how to get development back on schedule, when the producer casually throws the C-word into the conversation. A shiver ripples down the spine of the lead designer, culminating in a prolonged sigh which sinks the room into silence. The design team had been pushing for more time and more resources, but once again the dreaded “cutting content” conversation is rearing its ugly head.

C-word

It doesn’t have to be this way. Experienced designers learn not only to plan for the cutting contingency, but also to actively embrace it as an opportunity to practice design by subtraction and to focus in on the features that matter most. Defend crucial content passionately and vigorously, but also be prepared to re-examine the structure of your game objectively. The requirement to cut is just another constraint forcing you to find clever, creative solutions.

The end consumer doesn’t know what content you planned; they only know what you deliver. They can’t miss content they never knew about, but they can appreciate a focused, elegant and polished design.

Practice the Pre-Mortem

Hindsight is a wonderful thing, and many studios routinely conduct post-mortems to channel lessons learned in hindsight into the next project. However, each project is different, and no matter how much you learn there are an infinite number of new problems waiting to be discovered.

While it is very difficult to predict specific problems before they occur, you can help to prepare yourself for the consequences by conducting pre-mortems not just at the start of every project, but routinely throughout development every time a major production decision is taken.

The pre-mortem works by imagining the worst-case scenario and then constructing a narrative that gets you to it from where you are now. Imagine yourself, for example, as the Democrat party in early 2016, constructing a narrative for the seemingly impossible scenario in which Donald Trump actually becomes president. As you invent the story of your own nightmare, you may discover that not only is it less far-fetched than you imagined, but that there are some clear dangers which you can prepare for, if not prevent, by considering and acknowledging them beforehand.

donald-trump-president

So far as I can tell, the pre-mortem was originally devised by the Harvard Business Review.

PCU Problems Table

The requirements for each project are different and there will always be difficulties which are unavoidable. If you are working on a movie tie-in game, for example, then cutting content becomes a much bigger challenge because your backstory is fixed.

The pre-production phase is the ideal time to draw up a PCU (Preventable, Controllable, Unavoidable) table of problems that might afflict your project, so you can prepare and mitigate accordingly.

First you draw up a list of every potential problem you can think of, like this:

Realistic setting: Can you name a realistic Nintendo game? Why give yourself the trouble of things needing to make sense when you can design freely in an abstract setting? Consider how far you can push towards a more abstract setting within the constraints of your IP.

Too many mechanics: If you’ve ever worked on a game with a large cast of super heroes, each with their own set of mechanics, you will understand intuitively that each unique mechanic in your game brings with it a multitude of problems. Boil your game down to as few mechanics as possible and make them shine.

Technical issues: As sure as death and taxes, you are guaranteed some technical complications during your project. Although this subset in your universe of problems is of unknown size, you can expect it to swell into a monster if you are doing anything innovative or ground-breaking.

Personality conflicts: Hopefully this doesn’t happen too often, but it is always a possibility.

Losing team members: If you are working at a large studio, you may find team members are pulled off your project to firefight elsewhere, and at any studio there is always the possibility of crucial team members leaving.

Scope too big: Problems increase exponentially with the scope of your game. Sometimes, you have no choice but to build Middle-earth in its entirety, but always consider how you can rein in the scope of your project further.

Fixed narrative: When you can adapt the story, you have more flexibility to find solutions when things get tight. If you are working with a license, be aware that this will limit your control over the project scope.

Feature creep: Every time you add a new feature to your game you are unleashing a Pandora’s box of additional problems that will prolong the inflation phase.

Building your own game engine: It is difficult to imagine a more catastrophic decision in terms of the volume of problems it will create. Unless you are a AAA studio with mammoth resources, don’t do it!

Untested innovation: Innovation is great, but don’t underestimate the work involved in getting it right. Test and prototype as much as possible before entering full production.

Weak high-level design: Make sure you have specified the high-level structure of your game before production begins in earnest. Without a framework, your project can feel rudderless.

Next, you put each problem into the appropriate column in your PCU table, like this:

PCU

While you won’t be able to identify all of the problems which could afflict your project, at least you have thought about how you can tackle those that you can.

Embrace the Anguish

I thoroughly enjoyed delivering my Development Diamond talk to the unsuspecting students of Manchester Metropolitan University, and I trust that my “universe of problems” analysis wasn’t too disheartening. Making games is, after all, supposed to be a dream career.

But that is the point; despite all the anguish involved, making games is a dream career.

Many other jobs are full of stress and pain. The fact that game development is also thrilling, captivating and wonderous is what keeps us pushing onward through the storm, but it is no use pretending that the storm does not exist.

As Theodore Roosevelt so eloquently put it, “Nothing in the world is worth having or worth doing unless it means effort, pain, difficulty… I have never in my life envied a human being who led an easy life. I have envied many people who led difficult lives and led them well”.

shutterstock_132684239