Xerra's Blog

Drunken coder ramblings

Polishing the blog —

I took the opportunity to do a little housekeeping on the blog today which ended up with me getting my hands dirty with some raw html again. Very basic stuff in the end, and the kind of stuff I used to do in my sleep in the mid 90’s when we had nothing else to do it all for us. But, like everything else, you forget it all, when you have everything spoon fed to you. Tools like WordPress actually make it pretty easy to do most of what you want, it was just being stubborn that made me do it the hard way to get a couple of linked images in the side bar.

I’m now linking to Aaron’s blog – as he’s finally up and running. He’s trying to discipline himself to the mentality of blogging about what he’s up to. Just like I’ve been trying to do all this time, hence the sporadic entries.

That 15 month gap between posts we can all just forget about, right?

So, on the cards for this evening is a jump back onto the Paradroid project. Aarons still knee-deep trying to rip some of the original graphics and work from them so I’m going to capture all of the droids in a play-through this evening in 2* canvas through Vice.

I’ve got a trained version of Paradroid to help me get to the upper decks a lot easier but it’s pretty tempting to try and get there myself the hard way. Having a bit more time on my hands would probably make me try that as it has been a long time since i last played right through the game.

Hopefully I can make some observations about the game itself tomorrow – once I’ve done this refresher session.


Putting it all on screen —

With a mocked up game board in place it’s straight onto probably the hardest part of the project, which is handling all the objects needed for the game. There are 14 holes to keep track of on the board, and 48 pegs. We need to know the hole location of each of those pegs, the x and y positions of them on screen, the status of these pegs (as they could be moving between holes) and what kind of pegs they actually are.

I’m using some basic gem graphics for the players view and they’re going to need to be shuffled around within the hole they are in so it looks like there are however many gems in that hole, even if I have a counter displayed as well. Sticking them all on one central spot is useless as it’s going to look like each hole only has one gem when it could have loads.

So my problem at present is getting a structure in space probably for the board, where it keeps track of how many pegs are in each location, a total counter, which can update dynamically as pegs hit the stash, and the actual data for each peg itself, as there is several bits of information for each object there, too.

I approached this with pseudo code first. Just writing on paper how it should work and putting it into actual code on the page as far as I could remember the syntax at the time. Naturally, with the worlds worst memory for remembering stuff like this, it wasn’t brilliant, so I dumped what I have into the editor and have to tinker around with that to display some counters and feed it some dummy move data to make sure it’s all going to work correctly as actual player movements.

The board object itself, with holes in place is also going to be needed for an AI to work out how many pegs are in each hole when it’s their move so they can react accordingly. It can be programmed to do different things depending on some kind of a user setting but , in most AI, it would be logical to almost always go for a move where you can capture five or more pegs in one go, even if the player is setting them up to get an even greater return. Only a very sharp AI should be able to work this out as most players would play that way, too.

I’ve mapped out the areas where player is going to click to choose a hole to move from as that’s going to be needed for input before I can do any of this. Some kind of visual feedback will need to go in there so player can know they have clicked and the move is taking place. Not sure how I’ll handle that from the computer playing his move as I can’t imagine any kind of AI needed being so time insensitive that there will be a delay.


Mancala & stepping back in time. —

Today was possibly the most productive day I’ve had programming in possibly as much as a year. If any of it is of practical benefit, apart from the pursuit of knowledge and keeping the mind sharp, I’d very much doubt, but I like to think that any time spent in front of the computer putting code together, working with development systems, and just generally plugging away at getting it right is always a good thing.

I’m not so sure that writing such long sentences is also productive, from a creativity point-of-view, but I’m going to let it go because I hate editing stuff I write when it’s a blog post, as I believe it’s meant to be straight to the point and puts your current mood across.

Initially I started the morning with an idea of getting Parallels up and running again so I could tinker some more with Visual studio 2015 on the PC and work further through my book on C# to try out at least some of the code in there. I don’t want to get too specific and work through the entire thing generating windows applications and the like but just a general feel for the syntax of C# when putting it into Unity scripts. This way it would be how to do something with Unity rather than how to get the code right and then fudge it into Unity each time I did anything more than the stuff Unity can do for you.

I’ve mumbled to pretty much anyone who’s ever been interested enough in game development – and asked me about it – my reservations of using bloated game engines or frameworks for simple games because I am not a fan at all. At present the idea of Aaron and I using Unity to recreate Paradroid is almost insulting. It feels like almost cheating in some ways with the tools we have at our disposal compared to Andrew Braybrook just having a buggy assembler and a basic debug monitor. But also it’s a burden as there’s so much you need to know just to do sometimes really basic stuff that you’ve done in other dev systems in seconds without even thinking about it.

Maybe I’m just set in my ways whereas my partner in development is a lot more open to chopping and changing technology as and when the need arrives. We’re approaching Paradroid as just an example to learn Unity in greater depth than our silly Mario projects we both created working from a book to try it out.

I’m very averse to using a 3d engine to create a top/down 2d game but aware that Unity does cater for that and it’s supposed to not be too difficult to do, even though logic screams at me to use something more 2d environment friendly for a project like this. But Unity is used by a lot of people for a lot of games now, and a lot of people thus consider it to be the way forward so you should just use it for everything. The more games you write with it then the better you’re going to get, even if it does mean they’re going to be bloated games with code in them you will never even see, let alone edit.

For me there’s a loss of control there which doesn’t appeal to me too much. But I’m digressing from what I’ve actually been up to – which is the point of this blog – so back on topic.

My idea is to create something relatively simple in gameplay and hopefully coding to work with C# and get to know the language. I wanted to use the Visual Studio on the PC environment on my Mac to do this as games need a window to run in and I want that side of things taken care of for me at this stage so i can just concentrate on the basic syntax stuff and progress up from there. I googled around for a while and finally came up with the idea I wanted to use which was Mancula.

Mancula is the African number one board game of choice apparently, and has been around for many, many years. I first came across it on my Nokia 3310 mobile phone back in 2001, where it was called Bantumi, and used to play it a lot on train journeys to and from work. I’d had an idea to develop a clone of it with Blitzmax after I finished writing the Rock/Paper/Scissors game I was doing at the time. I did finish that game but then moved onto Gravity Force before jumping over to Swift so I never got much further than a few notes back then.

So the basic idea of the game is sound and I could approach it as just being a 2 player game or maybe get clever and put a simple AI in there which, based on how the game works, shouldn’t be too tricky in code. I googled around for a while and found a web version to play for a bit just to remind myself of the rule set so it’s time for a couple of images to look at so you all know what I’m talking about.

If you look at that then you can instantly get the basic idea of the layout.

Here’s the basic rule set from my notes I jotted down as i played a few games. Just for the record I got murdered four games in a row until I got the gist again and then pulled a couple of games back. I was playing on the easy AI level as well. This is a very clever strategy game, for such a simple implementation, so I was more than keen to have a crack at it.

Starting from scratch with this as a C# project is a bit daunting for me, being completely new to it, so I then considered the idea of putting the game together with a language I do know and then approaching it as a conversion from ready-written code. This possibly isn’t that logical to some, as I will be essentially writing the same game twice, but this doesn’t really worry me as it’s all still banging out the code. And I feel I’ve been very lacking with that recently since we started looking at Unity.

My most productive coding was during my days of owning a PC and using BlitzMax along with Blide as a development environment. This was the system I used literally just before Aaron and I got together to form Dexterity Design and I was so comfortable with it by then that I knocked out Gravity Force in 30 days using my half-cocked framework to build it from. GF isn’t a great game but any game I write from start to finish I’ve always been proud of.

As I’m using parallels now for Visual studio, testing out Game Studio 2 – as there’s no Mac version yet, and ProgEd for C64 retro coding fun, it was no great hassle to get Blide back on the machine and start the new project from there. As I suspected the old framework is an absolute mess of a project but I can still use some of it to build from to save time so I did. Screenshot below of Mancala running from the framework and also the development environment of Blide with all the source files that will become the game once I’m done.

Don’t expect to see much in the screenshot of Mancala itself. That’s the frameworks code running only. Most of the code I’ve already written to support the game isn’t to do with the actual display side so that will be in the next post. I’ve got basic public domain images for the game board and pegs but I’m not at the stage where they are going to be on screen as yet. The IDE screenshot is a lot more interesting as I’m currently using a few source files from my crap framework and I’ll probably approach the C# project the same way once I finish this and start on that.

Small steps and all that.

Considering I’m using Blitz again to do the first draft here I did have a look at NG again, in the hope that it’s a bit less kludgy with it’s Xcode projects and I could work with that and put in IOS conditional code so I had the option to dump the game onto the phone again for the memories. Unfortunately, despite lots of hacking around, rebuilding modules, creating new builds of the binaries from git hub and hours of time hacking about with other stuff, I still can’t even build the project I used to build to IOS with a year ago now. It feels almost like stepping backwards with that now, which is a shame as I don’t even have any original builds of other games I used it to convert to the phone now. I’ll have to email Brucey and see if we can bang heads together and get me going again.


Getting the basics right —

The reason for developing our Paradroid project is primarily a learning exersize in how to “Unity”

This means, for starters, I’m going to need to have some knowledge of C#. I’m not going to need to be brilliant at it but Unity requires various amounts of raw code within a project unless you’re doing something really basic that you can bang together with just the drag and drop elements.

Paradroid is going to need a fair bit of code within it because it’s not a massive, pretty 3d project that can use dumped in particle effects, 3d landscapes and just rely on Unity cameras to do all the movement work within the limitations of what the UI lets you tinker with. And, with Unity, it’s C# or Java. I know very little about either language so i’m taking a bit of time to start getting the gist of the syntax in comparison to other languages I’ve worked in as it may save some of the inevitable headaches later on.

So I bought a book. A book on C# which has been written to work alongside Microsofts current implementation of Visual Studio (2015). All well and good, even though I work on a Mac system, as there’s a beta build of VS out for Mac now, and it should be identical in use to the Windows/PC one, right?

Wrong. It does things its own way. Probably just fine for advanced Mac users who know the product but are starting with new projects and doing things their own way. But I’m working from a book which holds your hand the entire way, and expects you to follow it pretty rigid.

My solution for this (thanks to Aaron’s suggestion) was to go the first few chapters where it’s dealing primarily with the functions of the language and outputting to console in a Unity wrapper. This means putting a basic Unity project in place, attaching a script object to it, and then outputting to the Unity output console with the results of what I’m doing.

You can see the result of that in the image below. It even shows the C# code which only logs “Hello” as is, kind of like the old Hello World program that every language ever written uses as an example to show its syntax.


I’ll be building all my test code which needs console output into a seperate function within that script and letting Unity give me the results rather than try digging around for a basic C# interpreter I can use in a Mac terminal window.

Could probably do that instead but it’s playing with Unity to do stuff like this that gets me used to using the thing. So why the hell not.

Here’s the script in copy/paste format for anyone who actually would find this useful apart from me.

using UnityEngine;
using System.Collections;

public class Blah : MonoBehaviour {
    void Start () {
    void MyGameLog() {
        Debug.Log (Hello);

That will be edited a lot once I start using it as it will need to put everything into a public variable and push to the log function but it’s just shown as an illustration for now. And because I might find it amusing a few years down the line when I look at this again. And maybe know a bit more about what i’m talking about by then.


Project Paradroid —

When creating Paradroid back in the early eighties, Andrew Braybrook created a masterpiece. A game consistently rated as one of the greatest games ever written on the C64, and also one of the most fun to play.

From a technical point of view, it’s also a master class in how to fit a huge game into a tiny amount of memory space – around 54k when using pure machine code, but you have to have all the graphics and sound data in there too. It’s no wonder it took him around six months to write the game because you somehow have to cram everything in.

Remaking the game for the modern age is, in theory, a lot easier. We don’t have custom built development systems banged together out of cereal boxes where you’re trying to squirt raw assembled code down a serial port and hoping the damn thing doesn’t crash, for example.

We have the kind of technology for development that the programmers from that era could only dream of. They had old 64’s held together by sellotape, and often with hardware faults such as the sound chips, linked up to Atari ST’s that had just about useable assemblers piping data back and forth because you couldn’t fit a development environment into the target machine itself due to memory constraints.

We have Unity so should have the edge right?

If only it was that easy.

Unity is a new direction for us so this is a learning exersize, rather than a game we plan to get out there and have people playing in the near future. If it doesn’t pan out, or we run into trouble trying to find out if we even can release it, then it’s probably going to end up nowhere. In our favour there have been many remakes of this game over the years, all free, which have never encountered issues, so we should be ok but it’s like going back to the stone age for us, in programming terms, trying to use this massive application to write what should be just a small, 2D game.

Got to start somewhere, right?

So Aaron and I have kind of set ourselves separate paths on how we would put this game together as I’ve been mostly tinkering around with the UI side of Unity while he has been having fun with tile maps. Logically I’ll work to start with on putting together the front-end side of the game, hopefully as close to the original as possible. Aaron will work on the actual gameplay side on his own scene and, in theory, we should be able to drop our sections together in Unity and update each others project fairly easily. We opted to use this project to work through the trials and tribulations of cross-party development as for a long while we probably won’t lock horns where we would both be working on the same part causing all sorts of headaches.

As a rough idea of splitting the project, and very likely to change later on, my side will consist of doing the following tasks. If I can talk Aaron into it then maybe he can blog about his side as the problems he has getting the gameplay side together are likely to be just as interesting as mine.

Title sequence.

Here I do want the same look as the original Paradroid – right down to the same scrolling text screens giving you information about the game you’re going to play. I thought the atmospheric element of that was wonderful when I first played the original game. Heaven knows how he squeezed in so much data as well as all that game.

End game sequence.

I may diversify here depending on how it pans out. That tv sequence with the scan lines jumping around could be replicated – maybe with a particle effect – but maybe something else could be done here as well.

Static screens.

These are the pages of information you used to be able to pull up by accessing any of the computer terminals in-game. Stuff such as the detailed robot descriptions for all 24 of the droids in the game – including your 001 unit.

Lift screen UI.

It’s not just a basic up/down floor system for the lifts in Paradroid’s maps. There were different connections to different floors depending on which one you actually used, and not all lifts could access every location. There was definitely an element of strategy and learning routes needed to navigate this and clear all the floors. Took me ages to get used to it.

In-game HUD.

How well I can work this into a scene being developed by Aaron will be an interesting test of dual development. In theory I can have an isolated object for the game HUD and a pause game menu system that can be written outside of his scene and then just dropped in and linked up. The in-game HUD will be for showing the droid unit in use, it’s command operation IE:Mobile, console, Lift, Transfer or whatever, and also the score.


We’re not musicians or sound effect masters so it’s a case of either track down the original sound effects, get sounds that are kind of similar, or rip them out of the original game, if it’s possible. The randomised robot communication thing on the original games title screen doesn’t do much for me though, so I’m using some tribute music I found instead.

Lots to think about then.

I dug up lots of old images for research purposes which will be mostly redone in a very close style for our version, rather than try to re-use. The walls of text can be recreated manually as memory constraints would be the least of our problem this time and they work on a C64 size screen which is something like 200*160. Hardly practical unless you want to put your nose to the screen every time you played the game.

The original Paradroid font was my first challenge and I did look around to see if someone had already converted it into a useable font to save some time. Having no such luck, I started converting some of the characters myself before realising that it was a mostly pointless exercise as they looked frankly terrible when sized up to something that would be drawn on screen today. After a couple of hours trying to salvage something that was respectful to the original and wouldn’t put off any modern gamers, I gave up and just found an alternative Space themed font instead.

Braybrook had also made a couple of the chars in his original letters double width to make them readable so it would have been even harder trying to build up text walls that fitted correctly when automating some kind of display from a text file I typed into Unity.

Looking at the droid information screens I am tempted to try and reuse the originals. Our intention isn’t to try and make Paradroid 2, just a tribute to the original, honouring it as best we can by copying what it did. I’ll try to upscale them to a decent size and throw them into a panel in Unity to see how they look before deciding if they stay in.

One of the beautiful things about Paradroid is that you were looking down on your player object, and said object was rendered as a simple droid because you were basically only being shown a primitive top down view using the same droid design as the others, with just the droid model number to identify other hostiles because the game plot dictated it. You’re an influence device which is on the shop interacting with these other droids, but you, as the player, are on a different ship sending in the old stunt robot to do the messy work on your behalf.

So, I don’t need all those different robot images for anything other than the static screens from the terminals. Hopefully I can keep them as I can’t draw for shit so don’t want to redo them unless I can talk Aaron into it…

I did a quick mock up test on the original Andrew Braybrook Paradroid logo screen with the music to test that I had the screen setup right in Unity for the camera view so I could also colour it and test the music plays ok. Although we’re likely not looking at putting the project onto IOS it did compile and export through Xcode ok to actually build on my phone but there were lots of ugly yellow messages that probably aren’t too good. Maybe I need to check my build of Unity. Anyway, it’s a good starting point to move on from.



Moving forward. New technology and terminated games. —

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.

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.


Writing your way to being remotely interesting… —

I’ve decided that it’s infinitely easier to actually write a blog, rather than so-called professional writing for projects.

With a blog you’re almost just throwing down your thoughts and you rarely put any structure into the posting, or plan ahead into paragraphs and layout. It’s kind of like a “My Diary” where you’re writing for yourself and don’t care if anyone else actually does read it. You just hope that, when you come back and read it a few years down the line, that it makes some sort of sense, and you made your point without waffling like some rabid baboon.

Punctuation, spacing, formating, prose, spell-checking? Who gives a monkey? It’s a blog not a narative for your next English class. Is anyone going to care how it’s been put to the page (screen) as long as it’s (hopefully) actually interesting.

And, as I currently look back at this one, I realise it’s actually not, and that perhaps I should just get to the point.

So, at present, I’m tinkering with a document that we’ll be putting up on the Dexterity Design website. I’d link to it but if you guys just look right then I’m pretty sure it’s not hard to find. Can’t believe I almost actually put a smiley there as well. Sarcastic soul, me.

And my point I’ve been working towards is just how much harder it is when you want to put words on a page that need to look professional. Or at least competent. I’m not a huge critic of my efforts mostly, but this one does make me question every character I practically type. Struggle isn’t the word.

I’m probably setting myself up for an actual asassination now once I actually finish with all the drafting and put the document up online but, what the hell. Here’s me practically asking for it. Wish me luck !!


As an afterword for this post I was intending to write a bit about the incredible work Bruce Henderson has been doing with BlitzMax NG that I’ve recently been testing out on some of my code. I’ll come to that next post, when I’ve got a little more time to do it justice but, suffice to say for now is that we got it working with a couple of my games on IOS. I was very impressed and it actually gave these two games a new lease of life in my eyes, so I’ll go into this next post.


Edit: I never got to making that post as I wanted to get BlitzMax NG working properly without having to hack about with the configuration so much. I hope to one day maybe do this but I’ve tried a few times since to get NG compiling workable XCode projects since my initial success without luck and I’ve not had the time to document the bugs and make Brucey aware of it. Tony – 8/2/2017



Infection —

Welcome back to my ramblings, if you’re a previous reader, and an even bigger welcome if you’re new here via our website, or however else you have found me.

I’ve mentioned a few times the simple project that I developed back in May using Blitz to create a game in 30 days, which was Gravity Force. However, prior to this I had been working on something else which is at a finished level but I had plans to develop further into a much bigger game. I never got around to going back to this as we formed “Dexterity Design” and started work on finishing and promoting “iDef” instead.

So I’ve dug up the compiled project (Mac only at present until I can get a PC build compiled again) which I’m putting up here for people to play with.

Here’s the download as it was from the last build I did: Infection0.26-OSX.

As with Gravity Force I do plan to throw out the source code at some point but I may work again with this one so I’m not sure when right now.

Very soon we will be starting off the blog on our Dexterity Design website which will be covered by both Aaron and myself talking specifically about what we’re doing as a company but this blog is going to carry on as is. I’ll be updating it as often as I feel the need to share my progress in whatever I’m doing outside of our joint projects. And mostly because Aaron will tell me off about blogging about my stuff before we started making proper-games 🙂