I originally wrote this entry back in October but, as it wasn’t finished at the time, I didn’t get to actually put it online. As we’re up and running with something again – more on this next post – it’s time to put my house in order again.

I suppose blogging is a little like keeping a diary in that you could be accused of not putting in the effort when it’s been over ten months since your last entry.

I would accept that as being true.

It’s also true that myself and Aaron have been busy in the background doing stuff, even if the results have been seen by nobody but ourselves. Game development is a hard, tough process that involves a huge amount of effort in both the ideas and the
implementation of them to the screen. Design work, game structure, level layouts, data formats, audio, artwork, technology, tools programming, prototyping among many others. As a two man team we currently expect ourselves to handle all of this so the part about telling everyone about what we’re doing falls lower down the priority list. And that’s pretty much what’s happened here.

We’re both consciously going to make an effort to be better at this. From this blog, which I think of as my own little side project, and the main website itself, where Aaron is more likely to talk about what he’s up to. However, we are just both middle-aged guys with partner commitments, and bills to pay, so we’re unlikely to ever be prolific at it.

So, enough of the excuses, now. I’m going to talk about some (not all) of the things we’ve been working on for the last year. Most of this has been prototyping and switching of ideas when we’ve had a project idea that has become no longer viable to work on. More on that with the individual projects I’m going to talk about later.

The first thing on the agenda has realistically been the gradual swing towards our development system itself. Like, at current estimates, around 34% of other developers, we’ve been discussing more frequently the idea of switching over to using Unity. Pretty much everyone who would read a blog like this would already know enough about that, so I won’t go too much into it. Just to explain our decision to switch is mostly down to the desire to reach a bigger market which is something we never thought would be an issue when we originally released iDef onto IOS.

iDef is a game we’re both still fiercely proud of. It was written from the ground up using the Cocos2D framework so all the code itself was objective C. The man hours that went into the coding over its long development time-frame definitely goes into three, possibly four, digits. Aaron was also restricted in the hours of the day he could work on it. When it was done, and polished up to an area we both thought was good enough for release, we were pretty-much stuck to having IOS as the only release platform. Android could possibly have been another option but neither of us at the time had enough technical knowledge to be able to bridge Xcode into allowing that. Not to mention that we did not have any of the numerous devices we would have required to test it properly with all the screen sizes and different manufacturers that we would need to ensure it was compatible with.

So out it went onto the AppStore with both of us already pretty much resigned to it being very unlikely to be a massive success, and that we should start thinking of developing something to follow it pretty rapidly. And to also rethink our ideas on what we would use as a development platform for the future.

And so we moved on to Swift.

At the time this also seemed like a pretty stable idea. We’re going back to the middle of 2015 where Swift is being touted to go open-source and we already had done some prototyping to test run projects that would compile natively for both IOS and OSX with some relatively simple coding tricks. Aaron proceeded to start conversion work on iDef to bring it to the Mac and the new AppleTV, which had just been released. Unfortunately, rewriting it from scratch took its toll because we both felt that it would need to be done that way, rather than doing any kind of bridging with objective C code, so the project got shelved to possibly continue at some point in the future. Or maybe we won’t.

If you do want to see the progress that was made then I did do a couple of phone recordings of the work in progress which I published on my YouTube page. That’s of the game running on the Mac and showing the impressive use of SpriteKit processing over 200 multiple frame objects as a technology test. It’s worth a look to see how powerful SpriteKit and Swift can be. Even on an older, less powerful machine like mine.

https://youtu.be/eTeogUimzXY
Aaron and I then both did some prototyping. I won’t blog about all the projects we considered, or did any kind of work for, because there’s potential that some of them could still come to fruition in future. We’ve been unlucky with more than a few ideas we have come up with recently where we get beaten to the mark by something coming out that making it pointless, for example. All strictly by coincidence, I’m happy to say. There’s some very creative work still going on in the games industry if you
keep regular tabs on the stuff coming out. I’m very proud to say that – even if it does mean we need to work extra hard to make an impact.

Aaron came up with Wacca-Wacca first of all. Everyone knows the game of Pacman, where you run around a maze gobbling dots, and this was basically his first Swift work, putting together a decent, but sadly unfinished, clone of this just so we could test the SKS system within Xcode and see how physics and collisions work.

I’ve hassled him a few times to try and get him to finish it, as it’s a pretty good clone, even at it’s early development stage. But he’s right in stating “What’s the point?” Namco could probably just sue us, even if it was unlikely. And the other this is does anyone really want to play Pacman now? And would they pay for a game to do so? You can find hundreds of free versions or even paid ones. What on earth could we do to make ours stand out?

At this time I decided to work on my own on a separate prototype just to get the basics of using Swift and SpriteKit for something as well. I chose to clone a game I’d developed previously using BlitzMax where I’d set myself a timeframe of 30 days to design and create it from scratch. Using the same assets and audio I did a fair part of it before deciding there was also little point because, as proud as I was of the original creation, the game itself was a simple tap to shoot asteroids thing to stop them wearing down a shield and eventually causing an extinction level event on the planet. And it was never something I planned to put out there as the gameplay just doesn’t stand up for more than a couple of goes.

But did I learn something from coding as much of it as I did? Sure. Any code you write will always teach you something. Looking back at this now I’m probably being too negative with regard to my work as anyone else would complete it just for the practice as you can never have enough experience in shipping a game. Where it’s gone from thoughts to realisation on the screen, through all the grafting processes in-between.

Gravity force was half written for IOS and I was having problems getting to grips with the IOS technology on the development side. My code was nearly always hard coded for the devices I was using and didn’t take into account any kind of changes in screen sizes between ipads and iphones at all. It was frankly a mess so I dumped it into an archive folder and rubbed my hands of it.

I switched back to Blitz for a short time just to try out BlitzNG with Bruce Hendersons support, and got a couple of games running on IOS from within a Blitz wrapper but there was too much background hacking of files and other general tweaking for me to consider this as a practical way to develop for mobiles at that time.

By this time we had another hybrid project in mind that we started doing technology testing for tilemaps and bought some expensive code to help out with that, as the game we were planning would be using a lot of custom 2d maps. I won’t go into too much detail of this project because we were forced to shelf it, when we could not safely get permission to use the idea as the original games copyright was now in another parties hands. In retrospect, I think it was a bit too ambitious for a second commercial project so it may see the light of day again in the future.

Next up came Deflector.

We had a tilemap system engineered by this time, as we were throwing stuff around on screen as testing for the previous idea. We thought a game about using lasers to open gates and solve puzzles could be interesting. As there wasn’t really a decent system for loading and saving tilemaps with spritekit and Swift at the time, and our expensive framework we bought wasn’t exactly what we needed, Aaron set about writing his own tilemap library.

While he did this I took the bold plunge of another conversion of one of my old Blitz projects that I had renewed my interest in due to porting it over to the iPhone as an NG test project. This game was Infection. A game that had taken me longer to write even with Blitz, than it probably should have done. Even though it was a relatively simple game and the longevity is a joke, it’s still a favourite of mine because it has the ability to grab you back and try and beat your best scores. Even with high score tables a lot of other games can’t do that.

The level progression structure was a bit flawed as it’s too random as to wether you can realistically always clear a level if you made the right move but the game was a no-brainer to convert to IOS as it was a one click type of game, where you made your choice and fired your bomb then hoped the collateral damage would clear the level for you.

The new Infection would be a total rewrite – in Swift – and be built to run on both Mac and IOS, with the option of PC, once i had a PC development system up and running again. As I’d never released the original game I decided to keep the name, rather than Infection 2 or Infection Plus, or something naff like that. But this time I upped the anti on the play style. You could fire several bombs at once now as you had more shots. Obviously the gameplay had to adjust accordingly.

Infection was in place and progressing along, albeit slowly, and then I got the same issue that Aaron had with iDef. I just got sick of it. A developers worse nightmare scenario.

As a game it wasn’t good enough to try and sell.

The gameplay was way too simple so it was just another prototype to bone up on Swift and carry the knowledge forward onto developing something better next. But even with the core gameplay and all the title scenes in place I had to try and get a decent level structure in place so it felt like a game rather than just random levels. I worked out what kind of bad guys I’d need and the rest of the data for 20 levels and had the game set up to work with game center but again shelved it as my frame of mind meant I would be unlikely to do it any justice. I do intend to go back to it one day as I consider it 95% done, pretty much.

Aaron pretty much gave up on Deflector around the same time. I had reservations anyway but we both saw more than a couple of very similar style games, that were doing a lot of what we wanted, but doing it better. In both isometric and 3d and our game wasn’t going to compete unless we changed the core gameplay massively and did something completely different.

We toyed with the idea of doing something like Trailblazer/Cosmic Causeway but got no further than a couple of drunken conversations.

We considered a platform game then but I was more inclined to go for a shoot-em up so we did little apart from shunt ideas and talk them through a lot further before doing any kind of research work on them.

We decided we were too limited keeping with Swift when there was no option to export to Mac because it’s all keyed in to XCode at present. Mac downloads are something like 7% of what PC’s are at present so it’s commercial suicide to consider having a game just running on Mac and IOS, where you’re going nowhere unless you have some serious visibility.

So we looked at a few of the alternative systems out there and finally got to Unity. We’re not settled on that yet – as it head fucks us as much as anyone. But we’re both tinkering with it, trying to make stuff work, and we have our idea of what to try next. Again, it’s not commercial so we’re not going to get money from it, but it’ll be something to test us, and the technology.

I got Aaron a customised mug for Xmas. It had a gravestone with the words “Wacca Wacca, ******** and Deflector on it. Just so he could see the games we’ve terminated this year. Hopefully next year he can have another one of our Dexterity Design mugs with another game other than iDef on it.

Categorised as: Blitz | Development | Gravity Force | Infection | SpriteKit | Swift | Unity