Nice to get out again

Hello World,

I went to the Top-Deck Inn on Monday this week. It was the first time I’ve been anywhere with the tablet since before the UK went into lockdown back in March (I think anyway, feels like it was forever ago now).

It was really nice to sit and enjoy a reasonably priced cup of tea while I worked on Flappy-vaders.

I also managed to squash a bug relating to the explosion effect, despite only being there for an hour.

What’s coming next..

So, over the next couple of months I’m going to be talking about programming. On top of the rundown of the progress made on the game in the fortnightly updates, I’m going to share some thoughts on things which will help to make you a better developer.

We’ll be starting off later this week with comments, and how important it is to comment your code.

Outro..

And that’s all for now. I’m off to fire up the tablet and write some more Flappy-vaders (While I listen to Ernest Cline’s awesome second novel “Armada”)

GDD Update

Click the button above to see the revised GDD for Flappy-vaders.

The modifications this time round are mostly oversights which got missed off the first time round. One which I hadn’t thought of, and one which I simply forgot to include (D’oh!)

For those interested, the modified/addition sections are as follows.

3.5 Player Death

The game ends when the player dies.

The player will die if the player character collides with any of the obstacles or enemy or gets shot down.

The player will also die if the ships y position gets too low on the screen.

3.7 Daily Bonus

To encourage player retention the game should include a daily bonus system.  The more days played consecutively, the larger the reward. 

Rewards can be either in game currency or powerups.

Powerup rewards cost in the store determines there value here.

The actual type/style of the daily bonus will be determined later.

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.

Creating a game idea

The how/why of Flappy-vaders

The last thing I need to cover with regards to planning, is the how/why behind the idea of “Flappy-vaders”. Starting next week, the topic of conversation will be shifting to Programming.

In this post I’ll talk a little about the thought process behind the idea of Flappy-vaders.

Genre

The two biggest constraints for Flappy-vaders were time, and that I’d be writing it using a ridiculously low spec PC. Due to these factors I had already decided to create a simple casual style mobile game.

Again, for the sake of development time, I decided to take some already successful concepts from other games and combine them in a (fairly) unique way.

I decided to take the game mechanic from “Flappybird”, as it’s fairly simple, as well as being quite well known and fun/addictive to play.

I also decided to expand on this idea by adding elements from other games, such as the “zones” which you see in games like Jet Pack Joyride etc.

Now don’t get me wrong, I’m not simply copying Flappybird. This is going to be an original game in it’s own right, and I am 100% not encouraging people to create the utterly rubbish “asset flip” style games which are nothing more than a simple online tutorial which has been followed and the graphics replaced.

Visual Style

One of the things which makes games stand out at the store and in videos online is the visual style. I’d already decided to create a 2D game due to the hardware. I can’t imagine how the Linx tablet would run Blender, lol!

My initial inspiration for the graphical theme of Flappy-vaders was the menu screen for Fallout Shelter by Bethesda.

I loved the old style scan lines and the darkened edges of the screen, reminiscent of old CRT TVs. I imagined I could produce an effect similar to that of an 80’s era TV with a border and a scanlines overlay.

My next thought was about the type of games I’d have been playing on such a TV. Now in the 80s I had a ZX Spectrum, which had only 8 colours (well, 16 if you count brightness). I thought that palette would be a bit limiting, so I looked at other similar age devices before settling on the Sega Master System.

The Sega Master System has 256 available colours which should be more suitable for this project.

Monetisation

The last thing to do was decide on how the game will be monetised. Since it will be a casual mobile game, it will be free to download but include adverts. The player will be able to remove the ads by paying a small one off fee.

Another popular way of monetising mobile games is through the purchase of in game currency. This can be used to buy power-ups and upgrade the ship. Since I was planning on having power-ups and upgrades in the game, this seemed like a logical strategy to follow.

Conclusion

Overall it took me about a fortnight of thinking, researching and jotting down ideas. And then maybe as long again to refine them and be ready to create the GDD.

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.

A teensy change of plans

We’ve had a small hitch with the hardware. It seems the tiny travel mouse I was using has given up the ghost, so I’ve decided to switch to the mouse from the children’s computer. (Sorry kids if you’re reading this. If I forget to put it back when I’m finished with it just let me know 😉 )

This mouse is an old 5 button Microsoft intellimouse explorer. It’s my absolute favourite mouse design and one I’ve used on all my PCs for as long as I can remember. (I’d guess at around 20 years, lol)

The extra button on either side work as back/forward buttons for internet browsing, which is amazingly helpful.

These mice are as tough as old nails. Even after hundreds of thousands of clicks the buttons still click reassuringly when pressed.

Fingers crossed none of the other hardware packs up!