Game Progress Update #7

Update #7

Hello world, welcome to the seventh Dev with Dave Game Progress Update. I’m happy to say that I have at least managed to get the button handling system working this time round, even if there is only one button so far!

Buttons

The button handling system is a simple set of functions which can add a button to a UI page in a single command, check for button presses every frame, and also handle the response to each button press.

The system uses variables to track whether the mouse has been pressed, is being held down, or has been released. This will allow the buttons to animate eventually.

The button properties are all stored in an array the same as the other two UI element types I’ve created.

Problems I’ve faced

The biggest issue I have had whilst creating the button handling system, was the fact that the scanlines overlay was interfering with the button sprite detection. Any checks were simply returning the overlay sprite ID instead of the button below it which was the intended target.

I fixed this by simply moving the sprite offscreen which I check for button presses, then move it back before the screen updates. It’s not an elegant fix, but It will do for now.

The second problem is that I have found it very difficult to make recognisable icons using the low resolution that the game is based on.

In the next update

Over the next two weeks I’m going to spend some time creating graphics for the various UI screens, so hopefully lots more buttons and stuff for you to see (even if it’s not entirely working by the time the next update is here)

I also need to add a system to allow pickups to the gameplay, to allow the player to use powerups. Although I doubt this will make it in until the update after the next one.

See you next time 🙂

Game Progress Update #6

Update #6

Hello world, welcome to the sixth Dev with Dave Game Progress Update. This time round I have a whole new zone to show off, as well as having fixed a couple of niggling issues with restarting the game and some work on the UI handling system with the buttons.

Asteroid Zone

The first addition in this update is the new Asteroid Zone (Section 3.3.4. in the GDD). I’m currently using an asteroid asset which I found on Open Game Art, I like the style, but it’s not using the correct colour palette.

Because of the Zone systems I’ve already set up, spawning the asteroids was fairly straight forward. I did however have to make a small modification to the UpdateZones() function. It now checks to see if the current sprite is an asteroid or not, and if it is it adds a y velocity to the movement as well.

I expanded on the zone description a little on the Trello as well, which I need to update on the GDD, but that will probably wait till Monday now.

Game Restart

The changes here are mostly just bug fixes. The particles now no longer remain on screen when the game restarts, most (if not all) game related variables now reset when you restart the game.

The last thing I changed here was adding a function to remove any of the existing zone sprites ready for a new game.

UI Handling System

The one thing currently missing from the UI Handling System is buttons. I’ve added some variables and some empty functions ready for this, and created some place holder graphics which you can see below.

I had a real issue trying to create the settings icon in such a low resolution and sticking to the design principles.

In the next update

Next time I hope to have the buttons working, and have made a start on creating some of the other UI screens.

See you again in two weeks 🙂

Game Progress Update #5

Update #5

Hello world. Welcome to the fifth Dev with Dave Game Progress Update. The biggest change in this update is the work done to the UI Handling system.

UI Framework

This is where the bulk of the work has been done for this update. Continuing off from where I left it last update, I have added functions to load in the UI data as well as to change the current UI Page.

I’ve got the Text and Images working 100% but I still need to add the functionality for the UI Buttons.

I’ve created three UI pages so far. One for the pre-game, in game, and the Game over screens. UI pages are stored in an Array, and contain data relating to all the elements on that page. This allows a simple function to change the page when required, by simply hiding all the old elements and showing the new ones.

Unfortunately a bug in the UI handling code caused a big delay in development this update.

Restarting the game

I also made a start on being able to restart the game. I’ve not managed to completely finish this yet so it’s not demonstrated in the video.

Basically this bit simply resets whichever variables and sprites are necessary for the game.

Refactoring

Now that the code has been developed a little more, I have also been busy tidying up some of the less neat code and refactoring where necessary.

This has mostly just been moving code to the correct scripts and making sure that the comments are still accurate.

In the next update

I’m hoping to get another zone type working for the next update, and perhaps the beginning of the powerup collection system. I’ll also get restart game bit working properly.

See you next fortnight 🙂

Game Progress Update #4

Update #4

Hello and welcome to the fourth Dev with Dave Game Progress Update. This update sees a little bit of refinement in the graphics, as well as the introduction of a couple of new systems.

UI Framework

First, I’ve started fleshing out a UI Manager script to help make setting up and updating the UI elements of the game a little easier. Although this is currently only behind the scenes stuff at the minute.

I’ve created a typed array to store data for all three element types (Text, Image and Button) which I’ll be using for the UI, as well as an array to manage which elements are shown on each page.

Coins

The next new addition is coins! The player can now collect coins when they appear on screen. They are spawned by the existing zone handling system, and the only changes I made were adding a couple of variables to the player type to store the total coins collected, as well as the coins collected from the current game, and adding a quick check in the collision handling function to see if the sprite hit is collectable or not.

Graphics

The eagle eyed among you will have noticed that the game looks a lot more like the concept pictures now. I’ve spent a good few hours using paint.net to create some graphics which are a little closer to what I intend the game to look like, rather than those awful placeholders it was using previously.

I’ve also added the scanlines and CRT overlays for the authentic retro look.

In the next update

The next job will be to replace the current Game over screen, and create a pre-game UI screen with a play button as well. I think it would be a good idea to add a UI card or two to the Trello to help keep track of progress.

I’ll also be doing more graphics work, creating sprites for the forthcoming zones, and perhaps adding further tweaks to the existing stuff.

See you next fortnight.

Game Progress Update #3

Update #3

Hello and welcome to the third Dev with Dave Game Progress Update. I’ve been busy building on the prototype systems which had been developed previously.

Zones

I have added a second subset of zone data to better demonstrate the random selection of zone subsets. I also included a length value into the zone data so that zones can vary in length and still flow seamlessly from one to the next.

Player Death

Adding the hitboxes to the sprites was fairly simple in AGK, as was checking the collisions. I opted for the more complex polygon shape (Polygon will create a close fitting convex polygon around the visible pixels of a sprite) as I am only checking for collisions with a handful of sprites and it will mean more exact collision detection.

I also added a simple particle based explosion to the player ship which plays when there is a collision. The image used for the particles is one taken from an asset pack I purchased years ago and is simply a placeholder again for the time being.

Game States

Another system I’ve added as a prototype in this update is a system for handling game states which was necessary to allow the transition from Playing the game to the player crashing and the game over message being shown.

This system works by having two variables to track the GameMode (Things like Initialisation, Showing Menu, Playing Game, etc) and Loop Mode (Which breaks the game mode down into sections, e.g. Pre-Game, Game, Post-Game stuff). This way I simply have to update a variable to switch from running one bit of code, to the next.

User Interface

I have added a script for the UI stuff, and added a simple text only Game over message to display when the player has crashed.

I’ll be developing the UI further at a later point in development.

GDD Updates

There are a few changes which need making to the GDD this week.

I had omitted the fact the the player dies if they crash into the bottom of the screen (in section 3.5 Player Death), and there are a couple of new additions as well.

I’ll try and make these changes over the weekend and get the revised Flappy-vaders GDD uploaded on Monday.

In the next update

And thats all for this time. Over the next two weeks I will be carrying on with getting some more prototype systems in place for the other zones.

I will also spend some time creating graphics to replace the placeholders that I am using currently.

Game Progress Update #2

Apologies

Ok, so it’s fair to say that as I am publishing this today (Tuesday) instead of Friday that I have bitten off more than I can chew with this fortnights targets.

The fact that the temperature has been in excess of 30 degrees C for the last week hasn’t helped much. I don’t fair well in hot weather, and AC is not common in houses in the UK.

Zones

The goal was simple, to get the basics of the zones working, but I had greatly underestimated how many “behind the scenes” systems I would need to implement before I could get this finished.

The theory is simple enough. There is a pool of sprites created at run time which are used to display the current zone on screen.

These are assigned and positioned when the SpawnZone() function is called.

The SpawnZone() function is responsible for taking the zone data (stored in a csv string currently) and breaking it down and using the data to set the sprite properties (position, rotation, and image ID)

The zone sprite positions are updated by the UpdateZone() function, which simply moves all the sprites along to the left at the correct speed. It also measures the distance the sprites have travelled so it knows when to spawn a new zone.

The zone sprites are removed once they pass a set position (currently -192 px off the left hand edge of the screen) and placed back into the pool ready to be used again/

I have written a function specifically to get the next unused sprite from the pool. This allows the zones to transition from one to the other seamlessly without sprites disappearing, which would happen if the sprite was still on screen when it was re-assigned.

I also have created a couple of images, the zone marker and a pipe, to make demonstrating the zones stuff easier. Once again, these are only placeholders and are likely to change significantly as the development progresses.

In the next update

And that’s where we are now. I will carry on with the same task list again for the next two weeks, and hopefully have a lot more to share when the progress report day comes around next, which should be Friday the 21st.

Game Progress Update #1

Welcome to the first Dev with Dave Game Progress Update!

So, the development of Flappy-vaders has begun, The first phase of which is prototyping.

Prototyping

I consider prototyping to be an important stage of development as it gives you chance to test ideas and adjust them where necessary. Start by coding the bare minimum necessary to test the idea with, play around with it and then once it feels right, you can expand on it. After all, you don’t want to spend 3 months creating a game only to discover that it’s not actually fun to play.

With Flappy-vaders the prototyping gave a quick and convenient method to determine the ideal values to use for the gravity, thrust upward, scroll speed, etc.

Parallax Background

The first system I built was the parallax background system.

First I created the two ground sprites using Paint .Net, and copied them into the project media folder. Both images are 192px wide, the nearer image is 32px tall, and the back image is 42px tall.

Next I created a backgrounds script in AGK Studio to put all the variables, constants and functions relating to the parallax background.

Originally I was planning to use two sprites for each layer, with the sprites jumping back to position to replace the other as the scroll by.

However, because we are using 16:9 as the aspect for the background area, if you played the game on a device with a wider display then a gap appears on the right hand edge of the screen as the sprite doesn’t wrap round in time.

Instead, I decided to use 3 sprites, as shown below, which gives a comfortable buffer for playing the game on phones with really wide screens.

The idea is simple, the sprites move towards the left, and as soon as the first sprite passes the left hand screen edge, it jumps to the third tiles starting position. This repeats indefinitely.

I used a technique called “Timer Based Movement” or “Delta-Time” to ensure that the background scrolls at the specified speed regardless of how fast the device is that is running it. This is basically calculating how far the sprite should have moved in the time it takes to update the display.

I then repeated the process for a second layer and added a variable to store the difference in speed between the layers.

Player Movement

The next script I added to the project was the Player Movement script.

Player movement in this game is quite simple. The ship will accelerate downwards at a constant acceleration until the player taps the screen. This gives the ship a sudden upward velocity. This is then acted on by the constant downward acceleration.

This isn’t necessarily the way actual physics works, but it’s how Flappy bird did it, lol 🙂

As with the parallax background sprites, the player sprite uses timer based movement.

In the next update

That’s all for this progress update.

I’ll be prototyping the zones next, as well as adding collision to the players ship.

You’ll be able to see how I get on in the next progress update!

See you then 🙂