The People’s Popular Front (End)

Not much action on the dev front for a while, partly because I had a coding thing I needed to do that was a little on the boring side, so found motivation tricky. I’ve since mustered up the chutzpah to break the back of that, but it still needs a bit more work. (It’s all about traffic control, and I’ll blog that later).

Today though I got around to playing with a bit of front end (UI), which – in the early stages at least – I usually tend to enjoy. When working in the industry I found front end was often treated as a necessary evil – nobody really wanted to do it, but it had to be done. And OK, there’s a lot of unglamorous stuff in there that is a right PITA (and that’s why it can become a chore) but it’s also a massive opportunity. This is the first thing the players will ever see of the game, so this is where you should be setting the tone, and the feel. It should be treated as an opportunity, rather than a burden.

First off I had a choice to make – I either use Unity’s UI system, or I make my own. Neither is ideal. Unity’s UI stuff seems pretty good, but I don’t know it that well, so there’s learning involved in bending it to my will, and even then I’m sure I’ll find something I want to do that it’s going to have a hissy fit about. Whereas implementing it myself involves, well, implementing it myself. I did that for my Picross game, and the front end for that is a right royal mess (I’m talking about the code, which is borderline diabolical – I think the user experience is at least adequate).

However, I’ve got loads of past projects to loot for old code, and one of those has a menu system that makes a stab at simplifying some of this stuff. It also currently uses 3D objects rather than fonts for all the letters, numbers and symbols, which brings a raft of advantages and disadvantages (you can do a lot of cool things with 3D objects, but you’re wrangling it all yourself, so things like word-wrap and letter-spacing are now your problem, rather than the system’s, and that’s just for starters). However, all I want to do is get a front end up and running fast and worry about the actual implementation later, so yoinking this and pasting it into Road Bastard is the quickest way to go.

A bit of copypasta later and I have a rudimentary front end in place (the font is what was used for the old game obviously – I’ll make a new one if I decide to keep this system). I also have a new working title – International Road Bastard. This was a fairly obvious step. The game is nice and small in scope – a vertically scrolling racing game. What it needs is variety to keep things fresh. So the idea is to make it a global rally type of thing – an International Cannonball Run perhaps. Ice stages, desert stages – a nice change of scenery and a chance to add a bit of local fauna and flora (to smash up like a bastard).

Previously all my front ends have been largely hard-coded – and that works, but starts getting unwieldy as the number of menus and sub-menus increases. This new system is implemented in the editor largely by setting up individual menu items that can either launch a sub-menu, or call a function – such as starting the game, or quitting. It’s much easier to work with for these straightforward things, but at the moment I haven’t considered the awkward bits – volume sliders, reconfiguring controls, choosing screen resolutions etc. A problem for another day… The other thing I need to do is find a way to make this localisable (is that a word?). Currently the text for the menu options is English only – I need to find a simple way of redirecting this to any number of languages. Again – a problem for another day.

So next I start thinking about look and feel, and the first thing that occurs to me is to get car sounds in there. When I start a new project (however short-lived it may turn out to be) I always copy three sound effects from an old project across to the new one – menuMove01.wav, menuSelect01.wav, and menuBack01.wav. It’s so important to get feedback on a user’s actions that these get plumbed in immediately I get a front end up and running. So replacing the beeps I’d copied across initially with a revving sound and horns gets me this, which is a start:

And then I take into consideration that the game is called Road Bastard, and the next step seems very obvious. Bear in mind this took twenty minutes tops, and is just a case of me twiddling (technical term) with the pitch and volume a tad. I like it (I’m tempted to try making it top out with angry horn beeps on top of the revs).

So, that’s where it’s at right now. I’ve no idea how much of this will make the final cut, but I had fun doing it for the most part. I do need to sort the issues with my front end system – doing it right isn’t the nicest job and will take time, but could be so useful in any future projects. However I know myself well enough by now – I’ll probably kick it in the right direction a bit, and then leave it until next time to do it properly. It’ll slowly work its way toward completion, and that’ll have to do.

Let’s Get Physical

The day after I wrote my previous post I opened up the Road Bastard project, and realised right away that I was sick of the way it looks. Almost every project I start gets made with Unity’s standard primitives – cubes, cylinders and spheres etc. and I tend to just throw a few plainly-coloured materials at them to make sense of things. It’s a really quick way to get a project up and running, but it does mean they tend to all look the same. And I’m a bugger for picking the same colours. I like most of my colours to be a bit on the blue side, so I generally have bluish grey for metal or concrete, and bluish greens for grass and trees etc. and I’m now thoroughly bored of it. So the first thing I did was find a couple of better materials for the road and the grass that I’d downloaded free from the Asset Store, and then darkened up the remaining flat colours a bit to make it look a little different. I’ve no idea what the final art style will be, but this at least isn’t boring me silly:

(There is an issue with these materials in that something about the way they’ve been made means that lights and effects don’t show up anywhere near as well as they should, so I will need to replace them again, shortly.)

Next up I added some camera shake for when the car is on the grass. I have this in almost all my projects – it’s a very quick way of adding a bit of visual interest – so it was just a case of copying and pasting some code from another project. I forced this in, by just applying it when the car is a certain distance from the centre of the road for now. I stupidly didn’t think to also check that the car is moving, so it shakes even if you sit still on the verge. Never mind – needs doing properly at some point anyhow – the point was more to get the code up and running.

I also got around to buying a fog asset from the Asset Store. I added this with default settings, and it didn’t seem to show up, but then I remembered the new materials don’t like special effects, so I tried turning the lights out:

Looks like it’ll work, but I’ll play with this later. I’ve bigger fish to fry.

Next up I decided to do something a bit more important – change the control of the car over to being physics-based. This actually involved re-working pretty much everything. If you’ve read the first post on this game you’ll know that the game was originally meant to be a very simple lane-changing game. Because of this, it was written in a very cheat-y fashion. Basically the player’s car never moved down the road – the road moved towards the player. As the player accelerates the road just moves towards them faster. Likewise all the other cars are moving at their own speed, but also towards the player at whatever speed the player is currently at. I can’t remember exactly why I did this at the time, but it was a valid approach – it would have worked. But now I want to use physics to get proper collisions etc. and so this all needs ripping out and putting back in properly.

A quick change to the player code adds physics-based handling – but in a limited way. I’m not about to write a vehicle simulation – that would be beyond me, and unnecessary for what I still see as a simple game. So I’m cheating again. When the player accelerates I apply a force to the car that pushes them straight down the road. When the player steers I apply a force that pushes them across the road, and I also turn the car to face into the turn. This is different to what should be happening – which would be turning the car and then applying acceleration along the car’s forward axis. I could be wrong, but I think that doing it properly would cause lots of problems. My way allows me to take advantage of Unity’s physics system for collisions, but also gives me very tight control of the car. I’ve also restricted the physics quite a lot – there’s no gravity involved, and the car can’t rotate in any axis due to a collision. I may relax some of these if needed, but for now I want control. Anyway, basically I get the car running with physics quite quickly. The handling is awful, but I can tweak that later.

Next up I redo the road system, which was always a kludge. Basically the road is made up of a number of “tiles” that move towards the player. As the nearest one moves out of camera, I simply moved it to the back of the queue, and the whole thing just continued, looking like the player was moving, but they’re never actually getting anywhere. The change is a simple one – decouple it from the player’s position and move the piece further away from them, so that as they move down the road there is always a new bit to encounter. It’s still a kludge but it will work.

The final piece to getting this working is to change the camera so that its position is tied to the player’s car, rather than just floating in space (without this the player’s car zooms off out of view quite quickly). With that sorted we’re almost back where we started I just need to deal with the other cars.

At this point I added a traffic manager script to start controlling the way cars are spawned. I’ll go into this later because it’s complicated, but for now I’ll just say I had a couple of ideas about how this would work, and I’ve already realised they won’t work at all. So it goes. For now it just chucks cars along each lane at a different speed at 2 second intervals. I also added oncoming traffic on the other side of the road at this point. I then tweaked the cars to add physics to them, and then unleashed them.

Phew! A lot of text to get through, but that leaves us with things being done a little more correctly, physics is enabled so the player can collide with stuff, and there’s a script firing lots of cars with no AI at all down the road at varying speeds. Which results in this:

Now that looks like there’s proper potential to be a “Road Bastard” there to me. It’s actually quite good fun just driving along nudging other cars off course and seeing the results, which given that it’s all so basic is quite encouraging. One of the first things I’m going to do next is add an explosion for major car-to-car collisions to start getting a bit of feedback in there. Then I need to probably look at creating better traffic patterns, or maybe add some car AI.

One thing I need to think about though is how to keep as much as the action on-screen as possible. Because the player is driving fast (and at the moment nowhere near as fast as I’d like) there’s the potential for a lot of the chaos created to be lost as the player zooms past as it’s happening. I need to try to make as much happen further down the road as I can so that the player a) sees it, and b) has to deal with it.

Who Turned Out The Lights?

I only managed a couple of hours work today, but they were pretty good ones. As mentioned yesterday, the empty spaces off to the sides of the road were annoying me, so the first thing to do was knock up a couple of quick bits of scenery – one for either side. As with the rest of the game so far, these are all made with Unity’s primitive shapes right now, because otherwise I’d have to finally get around to learning how to use Blender to create 3D objects (I’ve spent 20-odd years using 3DS Max, but can’t justify the expense right now so need to make the change, but it’s a very reluctant one. Also, I hate learning new software – I genuinely find it immensely frustrating to have powerful tools but not the knowledge to use them – and it’s one of the few areas in life where I lack any degree of patience. It’s why I generally learn the bare minimum I need to get by with any software package, and use those tools exclusively – even if I’m aware there are better ways to tackle a job, but would need to learn how to use them.)

Anyhow, after maybe quarter of an hour of playing with capsules and cylinders and cubes I’ve got something serviceable, and I think it helps a lot. The grass verges make me think the car should shudder when travelling over them, and kick up dust. It’s also a good excuse to add camera shake, so these get added to the list of things to do. All non-essential, but all will add to the feel of the game, which is all I’m after right now.

Next I decided to address the horn, changing it from a short beep to a loopable sound, allowing the player to sound properly angry if they wish. I suggested yesterday that maybe the horn would intimidate the car in front – I’m wondering now if making that a function of time would work too – so some drivers panic immediately, while others need a longer blast (possibly over-complicating things, but probably worth looking into). I recently got a bunch of sound effects in a Humble Bundle, so I looked through these and found several car horns, but none of them looped. So I picked one I liked, opened it in Audacity and cut out the middle section and tried playing it looped. Huge clicking sound when it looped, so I nibbled a bit off the end and tried again. And again. And again. Then I tried nibbling a bit of the start. And again, and again. After whittling away at it for ages I finally had a (very short) loop that wasn’t too bad – it still clicks a bit, and will need replacing, but it will do for now. Audio is one of my least favourite jobs (which is a shame, because it has such a huge impact on a game).

Next up I decided to look at adding night time to the mix (this will also pave the way for all manner of colour schemes). A little tinkering with the light settings helped me find decent values to make a start, so I then coded a routine to fade between different sets of light settings at the press of a button (for now). That worked a treat – could hardly see a thing, so next up I strapped a couple of spotlights to the front of the player’s car, and – crikey – for something so cobbled together it actually looks rather neat. As you can see in the video below – night falls like a dropped brick right now – I’ll slow that down later. Next up I added tail lights to all the cars, and then when night falls the game manager script tells all the cars to put their lights on. The important thing here is that the cars each generate a random delay before they do this, to prevent all the lights coming on at the same time as if a switch had been pushed. Pleased with this.

Whilst rummaging around in the RenderSettings to adjust the lighting values I noticed the settings for fog too – I hadn’t thought of this, but fog would work a treat. So next up I spent a bit of time monkeying around with fog values – again putting them on a button press for ease of testing. I’ve soon got a real pea-souper. It’s not right, but it has definite potential:

So, next I think what happens if I mix it with night time, and this is what you get, which again could be really nice:

This is part of why it’s so very hard to finish a game. At this end of development, it’s almost like the game makes itself. It’s like it runs away, and you’re just trying to keep up with it, new ideas coming thick and fast, and you cobbling stuff together in minutes and getting cool results. It’s almost intoxicating. At the other end of development, you end up desperately trying to drag the bloody thing across the finish line, and it’s really reluctant to go. Every little thing seems to take an age to finally put to bed, and whilst what you’re working on is probably essential, you know nobody will even notice it. At some point the balance tips from that rush of ideas to that slog of just trying to kick the thing out the door, and at that point starting something new and interesting is always going to look much more appealing.

Anyway, at this point I decide to make a build to grab a video, and realise that the fog doesn’t show up in a build. A quick Google shows this is a known issue – fog works in the editor, but not in the final build. I try a few of the suggested workarounds, but none of them work for me. I soon get bored of this, so turn to the Unity Asset Store and find a few snazzy-looking foggy assets – and that’s where I’m at now – trying to decide whether to buy some fog I didn’t know I needed 20 minutes ago. They do look very good, so I’m very tempted (who knew you could make money selling fog?).

Tomorrow I’ll probably decide about the fog, and maybe look at adding camera shake and a few particle effects. After that I’m probably either going to have to bite the bullet and start using Blender to get some proper geometry in there as I search for an art style, or I’m going to have to look at getting the traffic working properly (which is perhaps the biggest unknown right now). Or I might put these off, and mess around with a few more cosmetic touches, because that’s much more fun.

Is This Thing On?

Hello. Long time no see. With a week off work I have a little time to tinker with potential new projects, and so I thought I’d also look at firing up this blog again – hopefully I can stick with it this time.


So I decided to sift through all my old prototypes looking for something I fancied revisiting – and came across the rather uninspringly named “DrivingGame” (I’ve mentioned before that the first thing you need for a new project, even before you’ve drawn a pixel or written a line of code, is a name for your game, and I’ve long-since given up trying to be clever with these).

Regardless, I want to do something nice and quick, and this feels about right. It was originally meant to be a very simple game of dodging traffic, with the player not having full control of the car – just the ability to switch lanes, and accelerate and brake. It was loosely based on a spiteful old arcade game that I have a fondness for – Road Fighter:


This first attempt never went anywhere – perhaps because it felt a bit “appy”. But firing it up again, I rather liked the look of it, and remembering the game it was based on, I came up with a new idea and a new working title – Road Bastard! This isn’t just a working title – this is pretty much my entire game design document right now. Enable the player to be a “road bastard” (whatever one of those is), and reward them for it.


A word on game design documents. When I worked as a Creative Manager, and then as a Game Designer, game design documents were things I came to hate with a passion. You had to write one for every project, detailing the story, and the characters, and the gameplay mechanics, and every other aspect of the game to win a contract with a publisher initially, and that’s fine and understandable. But the moment you win that contract the thing should be thrown in the bin and never mentioned again. It isn’t though. It’s maintained throughout the duration of the project to record the current state of the game. But because the game will almost certainly deviate from the design document within weeks of the start of development (at most) and continue to do so throughout its development, the game design document then spends the entire project chasing the current state of the game, needing to be updated every time a new change is made. It’s a colossal waste of time for a document that I’m pretty sure never gets read by anyone other than the poor sod who has to maintain it.


Anyhow, the first thing to do to make this better was to rip out the old control method and put in a new one, allowing proper freedom of movement. First up this meant just getting the car to move across the road, rather than snapping from lane to lane. This was an improvement, but not enough. So then I just added the cosmetic touch of rotating the car as it moved from side to side, and that immediately felt so much better with the car weaving, rather than sliding, around (so often these tiny touches are critical). Obviously, this is made entirely out of placeholders so far, but it has potential, I think:


As you can hear in the video, the car has a horn – if you’re making a car game then you can’t add the horn early enough, IMO. Maybe wait until it can move and steer first, but there’s no harm in doing it first. It doesn’t matter if you don’t plan on making it affect the gameplay at all – there is no downside to adding a horn. In the case of this game I’m thinking of perhaps making it intimidate the car ahead of you – maybe make them act erratically – that could be funny.


So, that’s the current state of play. Next up, I want to work on some “low hanging fruit” to push it towards where I want it to be. I’ll add in some scenery to fill in the gaps off to the side because they’re bugging me. I also want to add a night-time mode. Whilst working on this I remembered some of the very early arcade driving games like Night Driver, and I think a brutally dark colour scheme would work well here (whilst the player should be a bastard, the game will probably be a bastard right back at them). Also – and this is very important – I’ll look at replacing the current horn sound (beep) with an angrier looping sound, so that the player can hold it down for as long as they want – that’s what a “road bastard” would want.