Game Progress Update #14

Update #14

Hello world! Well, here we are at the 14th Dev with Dave Game Progress Update.

I know last update I said I had written enough of the UI systems to complete the powerups and boosts, but I had completely overlooked the fact that I hadn’t yet created the Missiles zone, so creating the missile jammer boost effect was unfortunately not possible.

I did however get the Head start and Self destruct boosts working, although neither is as polished as I’d like them to be.

The unlocking boosts works the same way as the unlocking the other powerups, but I had to write some extra code to handle the purchasing of boosts, managing the stock level and updating the text on the Boost store page buttons.

Head Start

The Head Start boost gives the player an initial burst of speed and a shield to protect them for a few seconds.

Code wise, the pre-game section checks to see if the player has a head start boost, and sets the headstart.isActive flag to true.

The main game section checks this flag, and if it’s true then it initialises a head start by setting the variables for the speed# etc. The game then runs at the boosted speed until the duration is up where it slows back down to the normal speed and the shield ends.

It has shown a bug in the way the score is incremented though. The score is supposed to increase faster when the boost is active due to the increased speed of travel. I’ve added this to the Trello and will look into it next time I’m fixing bugs.

Self Destruct

The self destruct boost gives the player an extra burst of speed at the end of a game by exploding and propelling the ship back up into the air.

The force of the explosion and the number of times the players ship bounces is determined by how upgraded the boost is.

Again, implementing the functionality of this boost was a fairly simple case of adding to the existing systems.

I added a check to the PlayerCollision() function to see if the player had a self destruct in stock when they crashed, and if so then move to the self destruct section instead of the usual game over section.

The new self destruct section initialises the self destruct by giving the player a massive boost of yVelocity# which is directly related to the level the self destruct boost is upgraded to.

It uses the same gravity calculation as the other game sections, but instead of triggering the game over when the player hits the floor, it gives the player another boost of yVelocity# as long as the maximum number of bounces hasn’t been exceeded.

The maximum number of bounces is also dependant on the level of the upgrade. Higher levels give more bounces, and therefore more distance and more score.

This will probably have an explosion sound effect, as well as a similar flash effect to the Smart bomb power up, and possibly some extra particle effects as well.

Next time

And that’s that. I’m still kicking myself that I’d forgotten I hadn’t written the missile zone handling system. I also have one other game zone system to write before I have finished all the planned zones and can move on to a bit of level design, creating some more zone sub sets to make the game less repetitive.

On the next update I hope to have not only added the system to handle missile zones to the game, but also have completed the last two boosts!

As always don’t forget to follow @devwithdave on social media if you haven’t already, and I’ll be back in another fortnight with the next exciting game progress update!

See you then


Six months in

Six months in

It’s been six months since Dev with Dave launched. I really can’t believe how quickly the time has passed!

This landmark does feel like the ideal time to just recap on the project, and to go over some of the highs and lows.

What we’ve learned so far

During the first few months, the main focus was on planning, writing your own Game Design Document, a few example GDDs from games, an introduction to Trello, and access to the Flappy-vaders trello board so you can see for yourselves how it works.

After planning, came programming. Now I deliberately didn’t want to go to deeply into coding on the blog, so instead it was mostly theory based stuff which would be applicable to any language you’re using.


Flappy-vaders has come on a long way in the last six months. From developing the basic systems with place holder art, to adding some of the visual effects, and adding powerups and upgrades. It’s starting to look like a halfway finished game, although there is still a way to go yet.

The bad bits

Now when I originally planned Dev with Dave, one of the things I was hoping to do was to spend time in various coffee shops and cafes (and McDonalds.. 🙄) but unfortunately the global pandemic happened and for large chunks of this year we have been in lockdown and all these places have been closed.

Because I am only working on Dev with Dave in my free time, I have struggled occasionally to keep up. This has shown in delays to the weekly progress update videos, and quiet periods on the social media. I’ve also found keeping the Trello board up to date to be tricky at times.

The good bits

I really enjoyed reading through the old game GDDs in the planning stage, and I have to say that Flappy-vaders has reached the stage where testing something quickly can turn into playing the game for 20 minutes! lol.

I’ve enjoyed the few times I managed to get out with the tablet and get some of the game written whilst having a nice cup of tea.

What’s coming next

I’ll be wrapping up the Programming theme soon, and moving onto promotion, where I’ll be talking about using social media and paid adverts to promote your game.

I’ll also be finishing off the last of the Flappy-vaders systems required for things like powerups and the store before moving on to level design.

I’m also hoping that the lockdown will end soon, and I’ll be able to go out and not only return to the cafes to write the game, but also get my hair cut! 😂


Game Progress Update #13

Update #13

Hello world! Welcome to the thirteenth Dev with Dave Game Progress Update. Since the last update I have managed to get three more of the powerups working, those being the magnet, smart bombs and the score multiplier.

Score Multiplier

Implementing the score multiplier was fairly straight forward.

When the player collects the Score Multiplier power up, a flag is set which indicates that the powerup is active.

When the game gets to the “increase score” part, it simply checks this flag and if it’s active then the score is multiplied by the multiplier level x 2. This gives the player the following multiplier options, x2, x4, x6, x8 and x10.

Smart Bombs

The next powerup is the Smart bombs, collecting one of these will destroy any enemy object on screen. It is intended to not work against structures, so it will leave the pipes intact.

When the player collects the smart bomb powerup, the game calls the SmartBomb() function.

This checks through all the sprites being used to display the current zone, and if they are in range and of the correct type then the sprites are disabled and moved off screen.

Because simply making the meteors disappear looked a little boring, I added a blinding white flash of light effect.

This was achieved by positioning a screen sized white sprite over the game sprites but beneath the CRT overlay effect sprites, and then decreasing the alpha value of it.

Simple but effective 🙂


The last powerup I’ve done is the Magnet. Once collected this powerup makes coins within range fly towards the players ship.

In a similar way to the smart bomb, to create this powerup the game checks through all the current zone sprites to see if any of them are coins. Although it does it every update until the duration has expired.

If a coin is found in range, then the game calculates the angle the coin needs to move in, which is a simple bit of trigonometry. It then moves the coin towards the player.

I say a “simple bit of trigonometry”, but this is what happened the first time I ran the game after coding the magnet systems.

I’m pretty sure that’s not how physics is supposed to work! 😂😂😂

I would like to add a visual effect to this as well, to give the player more indication that this powerup is active. It will probably have an active sound effect as well.

Next time

And that’s all I’ve had chance to do this time round. I’ll try and get the Trello updated this evening to reflect the changes made. In the next update, I’ll endeavour to get the boosts working.

As always, don’t forget to like, follow and subscribe to @devwithdave on social media to keep up to date with the project.

And if you have any questions, feel free to ask them on the >forum<.

See you in another two weeks.

Mobile User Interface Design

Mobile User Interface Design

The User Interface, or UI, is a really important part of game design. Whether you are planning a game for a Console, a PC or a Mobile game. Obviously it varies depending on which platform you are developing for, but because the game I’m developing for this project is a mobile game, here are a few thoughts, hints and tips on Mobile user interface design to guide you in creating your own.


It’s quite important that the UI does not break the players immersion into the game. It’s no good creating a dark gory horror game and then creating a UI for it which consisted of default grey panels and Arial font.

This kind of jarring of attention can lead to a poor user experience, which in turn leads to uninstallations and poor reviews, and nobody wants that.

During the game play itself, any UI on screen should not obscure the game area, so ideally should be around the edges (virtual joysticks and buttons) and across the top of the screen (non interactable UI elements, for example scores and health bars etc.)

When your designing the layout, consider where feels natural for your thumbs to press when your holding a device. The more frequently used controls should be larger and in easier locations to reach.

With the UI for Flappy vaders, I decided to keep the first page of the UI the player sees fairly simple and unobtrusive. The large logo fills the top of the screen, and the lower half contains only the two buttons.

The player needs only tap the play button from this point to immediately start the game.

The menu and subsequent pages are only accessible before a game, so the elements are more centrally placed on the screen.

During the gameplay itself, the UI will again be minimal and unobtrusive, currently there is only the score and coins collected displayed, but there is also going to be a pause button as well.

All UI elements match the graphical style of the rest of the game, and the sky and scrolling background are visible throughout.


One way of describing an intuitive user interface is that “It works the way users expect it to”. In other words, it must be clear and simple to use, so the user doesn’t have to think about using it.

Each platform has it’s own standard and expected way of doing things, so be sure to consider what is “normal” for your target platform when designing your games UI.

Icon design is another factor to consider. An icon’s meaning should be immediately obvious to the user. >Here< is a link to a post I made about the time I used AI to help me develop ideas and then concept art for icons.

Also the different UI sections should be logical in their design, so the user can easily go from one section to the next without having to think too much about it.

I have found creating icons which are both easy to recognise, and fit with Flappy vaders graphical standards to be one of the hardest parts of creating this game so far. I’m sure I’ll feel differently once I’ve started on the music and sound effects though, lol!


There can be quite a range of screen sizes for mobile devices, so it’s important that your UI is clear to see on smaller screens.

Try to avoid using small text sizes, and consider how the font looks when displayed.

Try not to pack all your UI elements too close together. And again, make sure that the icons or text are just as clearly visible on a 5″ phone screen as on a 12″ tablet.

Other things to remember!

Here are some other quick tips to remember when making User Interfaces for mobile platforms..

  • Although Google Play is OK with having a Quit button, Apple will reject your app out right if they find one.
  • If you’re using banner adverts, be sure never to put buttons or controls close to or overlapping the advert.

And that’s all

That’s everything for this topic I think. If you have any questions regarding anything mentioned in this post, then feel free to ask on the >Forum<