Game Progress Update #73

Game Progress Update #73

Hello world, and welcome to the seventy third Dev with Dave game progress update!

It’s been a busy couple of weeks, fortunately, not in the catastrophic disaster filled way that the previous month or two seemed to have been. Although both the oven and my kettle broke, which are pretty disaster like from where I sit. I was boiling water in a saucepan to make tea with for more days than I care to think.

However, I have a new kettle now and hopefully, we will be getting a new oven in the next few days 🤞.

This week I have spent my time at the keyboard working on the In progress list on the Trello board. And the time AFK I used to work on the pre-launch marketing drive.

What’s on the cards today?

There are two cards still waiting to be done in the list on the Trello, these are..

  • Increase difficulty & rewards of daily missions
  • Level difficulty

Increase difficulty & rewards of daily missions

Carrying on from last weeks update >here<, I have been playing and checking the game most days and have made the following discoveries.

At first glance, everything seems to be working correctly. But a little more digging soon revealed that the first time the game is run in a day, it works fine. But every subsequent time it’s run, for some reason the reward isn’t being calculated correctly and displays as 10 when it should say 20.

The target calculation seems to be working properly. I had shortened the number of times a player had to complete a mission type in order to speed up testing. I managed to get 3 of the mission types levelled up to at least the second level.

When I was getting ready to mark it off as done, I noticed it wasn’t working properly (Typical). It took a few days to even verify that it was happening, as the issue only occurs on the first run of each day.

Unfortunately it proved to be a somewhat troublesome bug to locate. I ran out of time before I managed to resolve it. But I will resume again next week.

Pre-launch marketing plan

The other thing I spend most of my away from my desk time doing, was working on the pre-launch marketing plan. I will of course be following my own advice from the blogs I posted on promotion earlier. You can read the first one >here<.

The plan is to start building hype for the game as soon as possible. I will be using organic social media and paid adverts to try and grow an audience. Although as the launch grows closer, I am concerned about what kind of budget I will end up having for that.

I have found a few target-demographic type groups to join on Facebook. These will be investigated once they have accepted my requests, and if they are suitable for my needs, then I will see about posting regularly and becoming part of the community.

I have also decided on a few suitable hashtags to use for other social media. Although I haven’t yet decided exactly what platforms I will be using for promotion as yet.

Quite a large part of the planning, will be deciding what media assets I will need for the various posts and ads over the duration of the prelaunch.

I also am planning on using a landing page with a form to capture email addresses.

I will share more details on this in the next update, but I am aware that the time is getting on and I am already late publishing this post.

That’s all for now

I think that’s all I have time for this update. I will as always be back in two weeks, on the 8th of December. But then I will be taking some time off from sitting behind the computer to spend some time with the family over Christmas.

Normal service will resume in the New Year, and the first Update of 2024 will be on the 5th January.

So until then, I will see you all in a fortnight.

Bad Game Dev Habits

Man using a laptop to code with the text "Bad game dev habits & how to beat them" overlaid.

Bad Game Dev Habits & how to beat them

I was talking with some friends the other day about bad game dev habits when it comes to making games. Since I seem to have more than my fair share of them, I decided to write a blog about them and how I am working to prevent them.

For those of you who don’t know, I have been coding for at least 35 years.  I learned my craft back in the days of 8 bit computers and BASIC.  I am also entirely self-taught, so I have no doubt picked up a few bad habits along the way.

Let me tell you about some of the worst habits I have with regards to game development. As well as what steps I am taking to avoid repeating them in the future.

Not commenting clearly

This is a big one for me, as I am a champion for clear and concise commenting in projects.  I’ve even written about it previously >here< on the blog.

Comments which make sense six months down the line can save hours of reading through the code when you return to the project.  Especially if you have been working on other, completely different things in the meantime.

I try and leave single line comments which describe what a variable is or does, above the line where the variable is defined.

//	Sets the players initial velocity

I also leave blocks of code at the top of a function definition.  These contain the usage parameters of the function, as well as a couple of lines of code with a usage example or any information which may be helpful.

//	null = UpdateZones( speed# as float)
//	This function updates the positions of the zone sprites and maintains the 
//	distance variable

Lastly, I also leave the occasional comment on blocks of code to explain what it does where necessary.  Some code is so simple that it doesn’t need a comment.  Sometimes a single comment will suffice for four or five lines of code.

//	Creates the sprite and sets the properties
SetSpritePosition(bgLayers[layerID].spriteID[0] , 0 , 0)
SetSpriteSize(bgLayers[layerID].spriteID[0] , width# , height#)

Even with Flappy-vaders, I recently found myself trying to find out what a variable did because I had not commented it, or indeed given it a sensible name.  This leads us nicely onto the next section…

Poorly named variables

When I first learned to code on the ZX Spectrum, all some variables* had to have single character names.

Nowadays there are few limitations on variable naming outside of coding conventions.  The trick with variable naming is to use as few words as possible to accurately describe what the variable is or what it does.

So when I was working on Flappy-vaders the other day, and found a variable called missionTotals which itself is quite an ambiguous name, I was understandably miffed.  But to add insult to injury, I hadn’t left a comment explaining what the variable did either.

I eventually found comments in another function which explained what the variable was intended for, but again, that was time wasted looking through the code which could have been better used for writing it.

* I had mis-remembered this, It was only some variables, like strings or for/next loops which required a single character name.  For regular variables, you were much freer and could even use spaces (although the compiler ignored these)

Overwriting graphical projects with single layer images

It’s not just the programing side of things where bad habits can cause hours of extra work down the line.  Graphical assets are just as susceptible.

One of the most frustrating things I have found myself doing inside Paint .net (my favourite free paint tool) is removing the layers of a project file so I can copy/paste the image into another image, and then accidentally overwriting the original project file with the single layer one.

This could easily be avoided by copying the existing project file into the new project folder, leaving the original existing project file untouched.

Not saving the ttf file or even writing the font name down

Sometimes you need a specific font style to base a logo around or the like.  You know what it’s like.  Hunting around font sites looking for the perfect font.

It doesn’t usually take too long to find a few suitable candidates, and before you know it you have the logo created, and saved and forgotten about.

Until the next year, when you need to reproduce the logo in a higher resolution for some promotional material.  But you’re on a different PC now, this new one doesn’t seem to have the font you used installed.

Thanks to the time which has passed, and the fact that the project you worked on needed a dozen fonts, you have absolutely no idea what the font you used for the logo was.

I have lost count of the number of times I have done this.

These days when I am doing this, I not only write down the font name and URL, but also the sizes and whether or not I used Bold or Italics.  I also ensure the font .ttf file is stored in the project folder with its license file.

Leaving (often rude) debug stuff in production

As I said at the beginning of this post, I learned to code in the 80s on a ZX Spectrum, using BASIC.  There was no fancy IDE with auto code complete and intellisense.  And there definitely wasn’t any debuggers or tools like code stepping or break points.

I learned early on that if I needed visual confirmation of a section of code was being executed, I could simply drop a print statement into the code to display on screen that the code had been executed ok.

This is how I prefer to debug now.  It comes as second nature to me.

Now somewhere along the journey through the years, I started using random words to make it easier to track down debug statements.  I could simply use the search function to look for the specific word I had typed in the print statement.  The more unique and less likely to appear in other comments, the better.

Because I have the mind of a 14 year old boy at times (we never truly grow up), a lot of these unique debug phrases were erm, rude.  Often they were several words strung together, any one of which would have your granny clutching at her pearls.

Now, sometimes, these debug lines hide in the depths of the code, and only show themselves on very very rare occasions.

So occasionally that they have gone unnoticed when we are cleaning up a project ready for release to production.

On at least one occasion, they have made it onto the store!

These days I use a simple search of the entire project for every Print or Debug.Log command in the entire project and make sure that they are commented out.


That’s I think all I can think of for this post.  I’ll leave you with some general advice which will hopefully save you from wasting hours of your time in the future.

  • Make sure you save often, and back up your project.  Use a source repository like GIT, especially if you are working as a team.
  • Ensure you have a copy of every asset used in the creation of all the assets you make.  Put them all in a folder, and never use the original file to work with, always copy it and work with the copy.
  • Keep a written log of what you have done/changed and what you are planning to do next. I find OneNote is ideal for this.

I hope this post is of some help to you all. Feel free to get in touch with me to let me know about your bad game dev habits.

Game Progress Update #72

Game Progress Update #72

Hello world! And welcome to the seventy second Dev with Dave Game Progress Update! I feel like this last couple of weeks has been a little better than the last one.

There has still been plenty of unwanted drama keeping me away from the keyboard, but I have managed to get a bit done to the game. I’m starting to think I should give up my career as a developer to instead write for the soap operas.

I even had to contend with Trello going down while I was trying to finish this blog post! Which is most unusual. Anyway, lets have a look at what I did manage to get done this week..

Plan for this update

Carrying on from the last progress update, there are the following things to do in the In progress column of the Trello board this update.

  • Review phase 1 cards
  • Increase difficulty and rewards of daily missions
  • Level difficulty

There are only a handful of the review phase 1 cards left. These are ones which needed boosts to be unlocked and purchased first, which I didn’t have the coin for. This time round I will edit the game to award me several thousand coins. I couldn’t do this last update as I was away from the PC, playing the compiled version on my phone.

Review phase 1 cards

Once I had added the line which awarded the player 250,000 coins, it was straight forward to test the remaining phase 1 cards.

It only took an hour or so to play the game enough to have completed the last few cards. Well, to be honest, I probably could have done it in half the time, but the game is quite addictive, lol.

The cards were fairly straight forward to check. They were things like the head start not playing the shield sound effect, or purchasing or using boosts not changing the UI values accordingly.

I also made sure that I removed the line of code which award the extra coins for testing purposes, when I finished testing.

Increase difficulty and rewards of daily missions

Reading back over the code..

At first glance, it didn’t seem as though I had added much in the way of code to handle the progression of the daily missions.

There was a missionTotals[] variable, but there was nothing in the comments or the like describing what it’s purpose was. I had actually commented it’s definition, but nothing helpful about what I was intending to use it for.

A little digging later, and I found that in both the load and save daily mission data functions, I had referred to the variable in the comments as “the mission totals count”. It’s my belief that I had intended this array to store the number of times each daily mission had been completed.

No matter how many times I say about HOW VERY IMPORTANT commenting your code is, for exactly this reason; I still find myself causing extra work by not doing it.

Making some changes

Going from here, I added a second variable to the type which is to track the current level of each daily mission. The plan is that once the specific mission types Total has exceeded a set value, then the total is reset to zero and the level value is increased. The level value is used to determine the difficulty and reward of the mission.

added a line to the calculate the reward function for missions, which just times the level value by ten to get the reward value.

Changing the target value however, was a lot trickier. Each mission type has its own initial target value ranging from 1 to 50. Ideally, I need to write a function like the one which calculates the reward value. This would allow me to As I felt on a bit pressured for time, I am kludging it for now, by simply multiplying the initial value by the mission type level value. I can always revisit it in the future if the values need changing.

I need to get the test build uploaded so I can test this. In order to check the code works, I need to play the game for five days consecutively. (Unless I cheekily change the value, so I can check it later this evening once the roll-over has happened 🙂 )

I still need to verify that this all works, but that will take a few days unfortunately. So I won’t know the results until next week.

Level difficulty

I didn’t manage to get any coding related to this last card done this time round. I did however get some thinking done about how this will work.

The issue is that as the game speed increases, it makes some of the zones very tricky to get through. It can leave the game feeling as though the difficulty suddenly ramps up, disproportionately so at times. So the plan for this card is to devise something to lessen this effect.

I’m unsure if I want to implement any of the following methods to try and add a bit more playability to the game.,

  • create a system which adapts the levels by increasing the distance between obstacles slightly.
  • Create several new levels, and develop a system to separate slow and faster levels.
  • Tweak the existing levels so they work better with a wider range of speeds

Ideally I would like to create at least twice as many zones as there are already, to prevent the game from becoming too repetitive, too quickly.

GDD Update

As well as all of the above stuff, I took the opportunity of updating the GDD with all the changes which were marked in the completed cards I reviewed from phase 1.

There aren’t many changes. The biggest ones were relating to the daily prizes and missions. There are a few minor changes however as well.

Click the link below to download it.

Click here to view the GDD as a pdf

That’s all for now

Once again I’ll be back in another fortnight with more news about the game.

I’m aware that I need to be working on the marketing strategy, especially considering how near to completion the game is. Aside from one video trailer I made, I’ve not really done anything on this apart from a few pages of notes. I’m not sure if I should include this in the progress update, or perhaps write a separate blog post about it. (Or maybe both, lol, who knows)

Anyway, I hope you’ve enjoyed reading this post. I’ll see you again in two weeks.