Darryl Long

Another busy week in the life of studio work, there was quite a bit of progress on the Creature Feature studio assignment this week. Additionally, work done on Crowd Control and the Trombone Game as I try to motivate myself to work more on the rhythm game after hitting a wall.

Crowd Control

With an actual deadline for this project, being the Indie Dev showcase at Netherworld, work for the project has resumed and is immediately underway. There were a number of things that were worked on this week and that includes:

• Implementing the phone collectible – Phone collectibles gives the game a form of currency this additionally gives the player a secondary objective to their primary objective of staying alive as long as possible.
• Jumping Bug – Fixing a bug that allowed the player to jump while they were in the air.
• Speed Up – This feature is still under speculation, we are still discussing the value that it adds to the game. However, one technique that I used to create an effect of speeding up is to zoom out on the camera, this gives a fairly good effect.
• Stagelight – The stage light adds another dimension and trap to the game, it cautions the player from jumping too often to avoid the traps below.
• Fixed Camera – To fix the Y-axis on the camera changed a number of things, initially, we thought that the player was jumping too high but this effect was caused by the fact that the camera followed the player’s movements.

After bringing these changes up and approved by my other team members we had a meeting to sort out a number of items that needed to be done to before exhibiting our game in 4 weeks time. Were aiming to implement these changes as soon as possible and attempt to refocus the project week to week as we get closer to the deadline, these features include:

• Collectible Patterns
• Beer glass obstacle
• Speeding up bugs and implementation
• SOLO Mode
• Game logo and Title

Trombone Rhythm Game

A large problem that I’ve had recently with the implementation of this game was the fact that I am currently stuck. I’m not quite sure as what to do to further the development of this project, tackling the music problem with creating notes with proper lengths and proper timing has been extremely difficult and with the lack of progress, my motivation to work on the game has lowered. However, I still love the idea and concept of the game and want to eventually finish it, so I decided to dedicate some time to creating assets for the game. I recently decided that the game should be 2D and that it should be a pixel style game, as it is simple to implement and fits the aesthetic of the game of not being an extremely serious concept. I was thinking that creating assets for the game would be visible progress towards the completion of the game and motivate me to put more work towards the project.

Potential Fields

Obstacle avoidance is a key aspect of pathfinding, this process is generally completed at the steering phase of pathfinding. I implemented potential fields by detecting whether the player had entered the trigger box of the obstacle and then continually calculating the distance between the obstacle and the player. Depending on the distance between the obstacle and the player determines the magnitude of the velocity added to the player away from the obstacle. This worked relatively well, however, there were still a number of bugs that allowed the player to become stuck, where their total velocity is zero.

These bugs were created when the obstacle was in the exact direction of the player’s pathed goal. This was fixed by detecting when a player’s velocity is equal to zero or close to zero and adding a perpendicular velocity from the player to the goal, this meant that the player would be moving around the obstacle if they were stuck. Another bug occurred when an obstacle was located on or too close to a node, the obstacle would continually repel the player away from the target node. The initial idea for a solution was to detect when an obstacle was on top of a node and ignore that node as a target node. However, that check and calculation would end up being quite expensive, especially when there was a much simpler solution in ensuring that obstacles don’t spawn on top of nodes in the first place.