Archives

All posts for the month February, 2014

Once again I’m expecting to have only limited time to work on Bubblision during this sprint as I’ll be launching my fantasy F1 game for 2014. That said I’m going to try and complete the following…

Sprint stories

  1. Finish the ‘Game Over’ screen
  2. Stop restored bubbles from overlapping existing bubbles when they first appear
  3. Consider adding high scores and best colour streak to the game screen
  4. Decide on an Ad network

Expected duration

Two weeks (ending 10/03/2014)

As expected, I didn’t have a huge amount of time to spend on Bubblision during this sprint.

Tasks completed this sprint:

  1. Sorted out the scaling for different screen resolutions
  2. Removed the old code for adjusting camera size on the menu screens
  3. Created/improved GUIs and screens
    • Home screen
    • Help screen
    • Credits screen
    • Game screen – addition of logo and score etc
  4. Added functionality to toggle the sound on and off

SunUp #14-08

  • Spent most of my time updating my fantasy F1 game for the coming season, deciding on prices, updating code and testing etc.
  • Read a tiny bit more of Level Up! The Guide to Great Video Design
  • Did some minor tweaking of the EC2 setup for my backups.

This has been a pretty hectic week and I’ve not got much done on Bubblision. The two tasks I’ve completed are:

  • Upgraded GameAnalytics to 0.5.9
  • Installed Unity Test Tools

The main reason I’ve not got much done is that I’ve been working hard on RF1. The new F1 season is rapidly approaching and it’s the second pre-season test this coming week. I hope to launch the competition after that test and there are a number of things I’ve got to do before then. So, this last week, I:

  • Upgraded to Django 1.6.2 on the live site
  • Started work on functionality changes for the coming season
  • Started looking at component prices within the game

I’ve also carried on looking at Amazon EC2 for my off site backups. So far the setup is costing me about $0.64 (or about 38p) a day. I’m currently backing up just one of my web sites but that appears reliable, I’m encrypting any sensitive data before transfer to EC2  and the cronned tasks on the EC2 box are working correctly. I’ve also set it up to alert me by email if the box shuts down or is rebooted as I need to re-mount the encrypted EBS volume by hand if it does (so I have an encrypted EBS volume and that contains the files I back up, of which some sensitive ones, such as database dump files, are encrypted individually). I also finally managed to set things up so I get an email with the output of my cron commands.

I’m expecting to have to spend some time on my fantasy F1 project in the next couple of weeks so I can launch it well ahead of the coming season. This means I’ll only be able to put in a limited amount of time on Bubblision and just have a few stories to focus on (albeit important ones).

Sprint stories

  1. Create the GUI for all remaining screens
  2. Sort out the correct scaling for various screen dimensions
  3. Start creating some tests

Expected duration

Two weeks (ending 23/02/2014)

Yay for testing!

I’m also excited about the release of official testing tools by Unity itself. Given that the impression I got from various gaming events I’ve been to is that few game devs do any TDD (test driven development) or TSD (test supported development) I’m really pleased that Unity themselves are making it easier for devs to test their own code.

That said, I still fully expect to hear comments such as “We’re too busy coding to do any testing” and “I can’t see how I’d test my code” whenever I bring up the subject for some time to come. 🙁

This has been a bit of a mixed up sprint as I’ve had a lot of other things to do at the same time so I’ve not been able to put in as much time as I’d have liked. Over the next few weeks I’ll launch my fantasy F1 game so that will impinge on the time available for Bubblision too.

Tasks completed this sprint:

  1. Increased the speed of the restored NPC bubbles an increased speed
  2. Fixed duplicate player bubble bug
  3. Tidied up my code
  4. Added functionality to pause the game
  5. Installed NGUI (a third-party library to help create GUIs
  6. Created a new main menu using NGUI

SunUp #14-06

  • Read a tiny bit more of Level Up! The Guide to Great Video Design
  • Decided to move my web site backups to Amazon EC2 so spent a lot of time researching that and then provisioning a server etc. I’ll blog about this process separately.

If you’re a regular reader then you might’ve noticed that I’ve been struggling to fix an annoying bug in Bubblision for a couple of sprints.

Initially the bug manifested itself as a graphical glitch where the two particle systems that are used when the player bubble hits an NPC bubble were played at the same time. Collisions would occasionally produce particles of two different colours. Later on I realised that occasionally I’d also get collisions that produced far more particles than should be emitted (even though these were the same colour).

When I added score text to the collisions I started to get some corrupted text at the same time as the particle problem. The trouble was that the problem happened only very rarely. Once it had started happening though, it would persist for the rest of the current game.

Eventually, by pausing the game in the editor and inspecting each game object when we had the problem, I found that the issue was a duplicated player bubble. The two player bubbles overlapped precisely. The text corruption was actually two score messages being printed on top of each other. The particle problem arose from collision detection running on both player bubbles colliding with the same NPC bubble. Since the two player bubbles were often different colours then one might match the NPC bubble and the other didn’t. This led to the two different particle systems playing at the same time or more particles of one colour being emitted than you’d expect.

In the game, when the player bubble collides with an NPC (Non-Player Character) bubble (or the spikes) I destroy the player bubble and instantiate a new one. When creating a new player bubble the Start() function sets the position and colour of the player bubble. The method for creating the player bubble is attached to the MainCamera object. When the player bubble and NPC bubbles collide the collision code on the NPC bubble destroys the player bubble and calls the creation method on the MainCamera.

The problem seems to be that if the player bubble happens to collide with two NPC bubbles at the same time then the create method is called by each NPC bubble. This results in two player bubbles.

This turned out to be quite frustrating to fix. I tried a number of things that didn’t work:

  1. Only calling the create method if no player bubble could be found.
  2. Testing for a property on the player bubble showing it had been created and was in the cup ready to launch.
  3. Explicitly naming the player bubble so that only one instance could exist at any one time. Unity just created a clone…
  4. Testing for more than one player bubble and deleting one.
  5. Using FixedUpdate()

As far as I can tell, within a frame (single Update) of the game, if the same piece of code is triggered it’s as if he two bits of code are called at precisely the same time. This means that tests to see if the code has already run will fail and you can get multiple executions of the same code.

Solution

In the end I rewrote the code so that rather that destroy and recreate the player bubble it’s just reset. From a positioning perspective this is straightforward but it makes the randomisation of the player bubble colour harder.

Originally I set the colour by adding the four different colour materials to the materials array on the player bubble prefab. The colour taken by the object is the material in the highest position in the array. I could then just change the colour when the player bubble was created by re-ordering the materials in the array. Since I knew the starting index of the selected material, and it was always reset to the same order when the bubble was created afresh, I could record this before re-ordering the array and use the index to see if the player bubble colour and NPC bubble colours match during collisions.

When I decided to rewrite the code this caused a problem with the colours as the materials array was already shuffled and I couldn’t use the starting index position to test for colour matches. In the end I decided to stop using the materials array and link the materials to the player bubble game object instead. This allows me to pick a colour for the bubble (at random), record what it will be and then set the material to match:

I got a few things done this week. Most importantly I think I’ve now resolved the annoying duplicate player bubble bug that I’ve been trying to solve for a few weeks now (further details).

This week I’ve finished:

  • Give restored NPC bubbles an increased speed
  • Fix duplicate player bubble bug
  • Code tidy up
  • Investigated how to pause the game