Oversteer Racing: Dev blog #42 – The one where it's quiet

Well January was a busy month and, as expected, February has also been really busy.

I have completed the move of my business bank account, to be honest I'm happy to be leaving my old bank as they were incapable of spelling my name correctly. So, I may not have been working on Oversteer Racing but I do feel like I've achieved something during February... small victories.

This time of year I also have to switch my attention to my 'other game'. For longer than I care to remember I've been running a fantasy F1 game and the new season will be starting soon so, as usual, there's a bit of house-keeping to do. I also have to keep an eye on the pre-season testing so that I can set up the competition etc. In some way this does help me with Oversteer Racing as I'm keeping an eye on what's going on in other forms of motorsport. There's just never enough time to do everything.

So then, next month, well I'm hoping that my fantasy F1 game will have launched for the 2020 season and I'll have a bit more time on my hands.

Oversteer Racing: Dev blog #41 – The one where we get down to business

As I mentioned last month I didn't expect to get much done this month and that proved to be correct. January is always busy because I like to finish off a few housekeeping tasks at this time of year.

In terms of Mucky Creature it means my own personal tax return and also doing the company accounts. These things don't take that long to do but I always seem to leave them until January rather than just get them done earlier in the year. It's not like I submit them at the last minute but I do still leave it until a couple of weeks before the deadline usually. It's not great but, to be honest, it's not the most exciting of tasks either.

An additional task I needed to finish off too was moving my business bank account... I know, proper "rock n roll" stuff this month. That said, I think it highlights the pressures on your time when you're working on fun projects outside of work. You get to do the fun stuff, like programming, but you also have to find time to do all the less interesting stuff, like switching banks.

I'd like to say that I'll be able to work on Oversteer Racing during February but in all honesty February is likely to be busy too. One of my other side projects always requires attention in February so I doubt I'll be back on Oversteer Racing in any meaningful way until March.

Oversteer Racing: Dev blog #40 – The one where it is festive

It's been yet another hectic month and I've done very little on Oversteer Racing. Although I've not done much it doesn't mean I haven't been thinking about the game.

This time of year is always tricky in terms of finding time to work on the game. There tends to be a lot going on at work and also at home because of Christmas and it's nice to be able to take a break from things every once in a while. Having side projects is great and really interesting but it can mean that you don't get any breaks and there's a constant stream of things to do - at times it feels neverending and can be a bit overwhelming.

Christmas tends to lead to me taking a break from things and relax a bit but then the pressure builds as I know that January and February are always busy and I may not get much free time to work on Oversteer for a while. I realise that this project has been something I've worked on for a long time now and it's still not close to being finished.

Is that a problem? I'm not sure. Conventional wisdom and thinking from a business perspective it's clearly not good business practice to work on a project for this long. However, that's not the whole picture. Mucky Creature and the games I create is not my primary business and I have a separate day job. So the pressure for these projects to pay the bills is not there which is a double-edged sword. On the one hand I'm not stressing about how to make money but on the other hand these projects turn into labours of love rather than something I ship quickly and move onto the next thing.

It's difficult, essentially I need to view these projects as something fun and, if life gets in the way, that's OK.

Oversteer Racing: Dev blog #39 – The one where we stop the race from starting

This month has been pretty busy, as I suspect will be the case for a while now, and so I've not spent as much time on Oversteer Racing as I'd have liked. One of the tasks I've started looking at is the start of the race.

Currently the race starts as soon as the level/track loads which is obviously not what will happen in the actual game. I've yet to decide how the race should start. It could have a "fly-by" recap of the grid positions or maybe some sort of overlay on screen. I think it would also be useful to recap the race length, pit stop prediction etc. Once that's complete there will be a start light sequence and the race will begin. This month I added code to prevent the race starting immediately. This enables me to trigger when the race should start.

One other component of the race setup is the starting positions of the cars. I've now configured a ten place grid on the test track (so the code now matches the texture) and can control the position of cars on the grid. I still need to add code to support random grid positions and also some sort of qualifying session. I think the most likely format for this will be a one lap shoot-out where the player can do an "out lap" from the pits and then a single flying lap.

So much still to do...

Next month...

I want to carry on working on the start sequence and also improve some of the AI car behaviour when they stray off line.

Oversteer Racing: Dev blog #38 – The one where we stop the pushing

One of the key things I've been focussing on this month is the behaviour of the NPC cars when racing closely with other cars. To be honest they can get a bit fiesty under some circumstances but are a bit too passive in others. Getting the right balance so that going wheel to wheel is fun is tricky. I don't want it to appear that the NPC cars can be easily passed but, similarly, I don't want them to put you into the wall either. I think it's fair for them not to yield places easily and, if they have the better position for a corner, then the player will have to back out of a move or risk a collision. At times this can appear a little unfair to the player. You might go for an optimistic move but find the NPC will give up no ground and will take their usual line into the corner and the player has to avoid them. The NPCs do have a notion of "aggression" and I'd like some "drivers" to be found to be much harder racers that others. I'd like a situation whereby a player can approach an NPC and think "OK, I can dive up the inside here and they won't turn in" or "I need to work hard to pass this car because I know they will shut the door on me if they can so I'll have to get alongside before they'll give up the place".

This month I've done some work to improve how the cars race and that largely involved a lot of play testing and tweaking of settings to find a sweet spot. Some issues have been more obvious than others, for example, a car running into the back of another due to a tow and then pushing it along. Other situations require a bit more finesse and lots of fine-tuning such as how NPC cars detect cars that are close to them and how they react. I think the racing is better now than when I started this block of work but it'll still require some tweaks I expect.

Some of the other things I've worked on include the correct display of the lap counter for the player car. For some reason, I'd managed to overlook this and it wasn't updating properly and could also display the car as having completed more laps than were in the race. This is now fixed although I'm still using a very rudimentary user interface. I also worked on setting the correct starting position for cars on the grid. Cars can now be allocated a position and they will start from the correct grid slot.

Next month...

I want to start working on the start of the race. Specifically how the start is triggered.

Oversteer Racing: Dev blog #37 – The one where we work out why we stopped

It's been another hectic month but one of the things I have been focussing on is the reason why non-playing character (NPC) cars stop.

There are a number of reasons why an NPC might not finish the race although the commonest reason is that there is a collision between the player and the NPC or between two NPCs. At the moment the code can detect if a car has spun and attempt to recover it back onto the race track. I've now started looking at what happens if the NPC car has crashed out or, for some other reason, cannot continue. The code will now retire an NPC car if required and record the reason for the retirement. This reason can then also be displayed to the player at the end of the race. The situations under which a car should be retired are reasonably easy to define (such as a crash, out of fuel etc) but the code will also handle situation where a car has spun and, for some reason, cannot recover back to the track. One thing I now need to decide is how to represent this in the game. For example, should the cars that have retired remain at the side of the track for the rest of the race? Also, at what point should the race be red-flagged due to the number of cars remaining? It won't be a lot of fun if there's a big crash and only a couple of cars can carry on. In this case I may look at the rules for some forms of motorsport to see what the "cut-off" is.

One other thing I've been working on is finishing off a few loose ends. These have become more obvious recently due to the lack of time I've been able to put into the project. As I've been playtesting I've noticed things that were not working correctly. On investigation I've discovered that I've not completed various tasks and that's why feature 'x' wasn't working! So I've finished off some of the UI and the code to supply data to that in addition to fixing some bugs and tidying up other bits and pieces.

Next month...

I hope to finish off the code handling retirements of NPC cars.

Oversteer Racing: Dev blog #36 – The one where we go too long

I've been away for a lot of this month and, being the only person working on Oversteer Racing, that's meant that work has been slow.

Having said that I have done a bit of play testing and I discovered that NPC cars were taking on too much fuel at pit stops. This made the cars heavy once they had pitted and they were then slow. For a while I thought that there was an issue with the code that determined what the correct fuel load would be for the car to get to the end of the race.

After some debugging and testing I found that the code to determine the fuel loads was correct. The issue was actually far more simple. There was a bug that meant that NPC cars were not receiving the correct information for the race length at the start of the race. At the pit stop the cars were then fuelling up for the number of laps they were expecting but this wasn't the number of laps remaining in the race. It was a simple fix but a bug that took a little time to track down.

Next month...

I hope to do some work on handling retirements for NPC cars.

Oversteer Racing: Dev blog #35 – The one where cars block the pit lane

It's been another busy month but I did manage to spend some time fixing a few bugs in Oversteer Racing.

One of the things I discovered was that the game settings were not being used in the race. So, if I set the damage setting on then the car damage wasn't affected in race. This was also the case with the other settings that players could change before the race. This was relatively easy to fix once I'd noticed it.

Another issue I discovered was that NPC cars would some times crash in the pit lane. These crashes would then block the pit lane and prevent other cars from pitting. These crashes were caused by the pit lane limiter not being set correctly for NPC cars. As a result these cars were entering the pits too fast, missing the turn in point for their pit box and blocking the pit lane.

Next month...

I hope to do some more play testing and bug fixing.

Oversteer Racing: Dev blog #34 – The one where we tie up a few loose ends

It's been a fairly busy month but I have managed to work on Oversteer Racing, so that's a significant step forward from previous months ;-)

As it's been a while since I could put a reasonable amount of time in on the game I've been getting back up to speed by fixing a few minor bugs and tying up some loose ends. Most of this work has still been focused on the end of the race and making sure the data is correct. I've made sure that the race summary uses the correct driver and team names (as set by the player) and also made sure that the code correctly determines the time gaps between the cars.

I've also fixed a few minor bugs where data was being misrecorded (incorrect pit stop numbers, DNFs etc) and also fixed a bug that meant that smoke wasn't being shown when an engine failure occurred. I've also been working my way through all the settings scenes and making sure those settings are reflected in the game (i.e. if you switch on advanced handling then that is toggled on in the game).

Next month...

I hope to finish off all the work on the code to handle the end of the race and correctly record the results and update player stats etc.

Oversteer Racing: Dev blog #33 – The one where we get the move done and fix things

As mentioned last month I had to spend some time moving my website over to a new host this month. As I was moving the site I took the opportunity to try and simplify things a bit. The old site used WordPress and that's great but it requires some effort to maintain (software updates, database backups etc). As I needed to move the website anyway I chose to stop using WordPress and use Jekyll (a static site builder instead). This should pay back in terms of time but offer similar functionality.

I have managed to do some work on Oversteer Racing over the last few weeks too. I'm still working on the code to handle the end of the race. I've made good progress and the code is handling most of the scenarios I'd previously outlined for the end of the race. It still needs a lot more polish but it's been good to make some progress again.

Next month...

Further work on the end-game code and I also want to make sure that, if users change the names of drivers and teams, these are reflected in the end-game scenes.