#lead programmer

As Lead Programmer, I have contributed most of the code base and Unity engine implementation of imported assets. This has been without a doubt the most challenging programming task I have been assigned or taken up myself, and I was eager to take it up. So how well do I think I did in this role?

Looking back on the original design documentation for this project during it’s prototyping phase, I can safely say that not only is there not a single essential mechanic that was not implemented into the game, almost all of the non-essential mechanics eventually made their way in as well. I can say without any doubt that I feel I succeeded in my role as lead programmer.

This is especially true given the circumstances as well: Mod DD was expended a majority of the time on preparing the art assets, though they were able to contribute a bulk of the menu and ui functionality, and the small amounts of programming that Mod DPH contributed were either in the wrong location, inefficient or just broken, and had to be re-written by me after the task had been delegated in the first place. As a result of this, I was left with the responsibility of nearly all of the programming without the ability to delegate tasks and expect them to be completed.

The downside to this is that the heavy workload I was under on the programming side forced me to have to put my secondary role, Lead Audio, on the backshelf, and there is much more that I would have liked to have contributed on that end had the time been available.

There are also a number of things that as a team we would have liked to have implemented by the end of this module: One of the biggest ones being building the game for mobile platforms, where the genre finds it’s biggest market. Other planned features that never made it in included the ability to regain a chance should the player beat their previous distance, multiplayer connectivity through Play Games and the Game Center on Android and iOS, a greater number of artefacts implemented and further refinements to the chunk system.

With the Player model received from Mod DD and animations provided from https://www.mixamo.com, I set to work putting together an Animator component to bind all of the animations together. At this point in development, time was limited and though I dedicated what time I could towards learning how to get the Animator to work, I do not know at this point a lot about it’s functionality and as a result the results are unfortunately slightly choppy.

One of the USPs of the game from conception was the use of Artefacts. These collectables would be selected before play and would give the player additional mechanics to allow more variety in how to approach avoiding obstacles, inevitably leading to improved player performance and greater distance achieved.

The Artefact class attached to each Artefact inherits from Reward and shares much of it’s functionality, but the key to it’s use is the UseArtefact method. Able to be called externally due to public accessibility, the exact effects vary due to the use of the switch statement on the ArtefactType enumerator. 

To be loaded into the game to allow the player to use them in the first place, an ArtefactInitialiser script was written, the job of which to be to determine which Artefact prefabs had been selected through PlayerPrefs, attach them to the GameManager and then destroy itself to save memory. The player is then able to trigger the UseArtefact method through the InputManager, giving them the additional functonality.

(GIF: https://68.media.tumblr.com/6bab19658fd16d515c666633cd237225/tumblr_inline_opgwcbaFyG1sorqsh_540.gif)

Once the player has finished a game session, the Death Screen is a UI Object that appears and runs it’s attached script to get the accumulated distance, profit and final score to roll up. Rather than just printing this to the screen when the player dies, me and Mod DD decided between us to allow the score to count up, similar to games such as Sonic the Hedgehog. This also enforces an Open Feedback Loop design so that the player can reflect upon their performance during this gameplay session and compare it to previous runs.

Our Project Lead provided a method of loading new scenes asynchronously, which our Lead Tester implemented in-game inside multiple scene-loading scripts, which also enabled canvas objects to act as loading screens. However, multiple scripts for loading individual scenes was inefficient, and as such I have refined the script into a versatile LoadSceneManager script that takes an int as a parameter and loads the scene with a build index corresponding to that int. In this way, any scene in the game can be loaded into without the unnecessary amount of scripts that comes from loading one scene per script.

In Part 1 of this post (), I discussed the new system implemented for generating obstacles into the scene based on the row data provided. However, this class here needs some explaining to fully illustrate how this system operates.

The ObstacleLibrary is a class that functions similar to the ChunkLibrary. It holds a number of Serialized Obstacles, loads them into a dictionary on Awake and allows a specified or random one to be returned. The Obstacles that are loaded are attached to Prefabs, which also hold a Collider and Mesh Renderer unique to the specific obstacle. 

In this project, there are generic obstacles, that take up space on one lane and can be jumped over or moved around, as well as a special group of obstacles called Totems. Totems are obstacles with considerably more character that differ from generic obstacles as they vary in height, width and Collider location. This changes or limits the number of options the player has in out-manoeuvring the obstacle and adds variety and depth to gameplay.

The LookUpObstacle method in Obstacle Library that returns a random obstacle contained in it’s dictionary. There currently exists functionality to pass in a string to return a specified obstacle, but this has yet to be iterated upon. During the obstacle generation process, this method is called to check if a randomly rolled Obstacle is equal to the height specified and smaller than or equal to the width specified. This augments the chunk-based design pattern by changing the specific obstacles on each chunk as instantiated into the game, providing further variety in gameplay.

During development testing, it was noticed that a cause of player frustration was the player character responding to input. Because of the core mechanics being written so as to not allow any action in-between actions, unless a player timed their input precisely after an action concluded, it was difficult to get concurrent actions to flow into each other promptly.

To combat this, a Queued Action System has been implemented. From now, when the methods running to activate mechanics fail because an action is already on-going, an enum variable, queuedAction of ActionType (Jump, Slide, Move) is set, and when the mechanics methods end, immediately trigger another action method providing that the queuedAction does not equal null. This culminates in the player not needing to be as precise with their timing, rewarding successfully understanding how to resolve the "problem” of how to avoid the obstacles in front of them and making this the core challenge of the game.

thar's a noo artikle ha dunben wrote uhn www.giterdonegossip.com calt

Game Changer: Lead Programmer Brie Code Talks Exciting New Diversity Initiative at Ubisoft Montreal And Making Games More Accessible