It's Game Dev time

Before deciding to study and ARU, I remember looking at the course details and the expected modules, and being excited for this module in particular. The chance to rapidly prototype and develop games alongside the ability to work with artists was something I could not wait for.

With that said, let’s reflect on the module overall, breaking it down phase by phase.

Prototype 1: Jungle Tumble - Lead Designer / Lead Audio

Prototype 1, despite conceiving the idea that would eventually become our final project, was undoubtedly our weakest overall. Due to a lack of leadership caused by the absence of Mod DPH over this period, a large number of vital elements of teamwork, such as communication, assigning tasks, conflict resolution and direction, went out the window. Mod DD and myself were forced to bounce off of each other, which did not lead to enough productivity to prototype the concept and we ended the phase without a deliverable that was up to standard.

As designer, my contributions included UI diagrams and concepts and a gameplay flowchart. I feel as though I let myself down in this role, as design is a passion area for me and I feel like I could have done and explored more if I had understood the pressures of time more.

Prototype 2: Highway Hightail - Project Lead / Lead Tester

Prototype 2 was an improvement over Prototype 1, but was still largely unfinished, unpolished and ultimately unpresentable. I stuck to my responsibilities as Project Lead as best as I thought how; Running Waterfall development methodology, assigning team members tasks and giving expected but flexible deadlines for completing them, keeping group communication frequent and strong, providing the master checklist and deliverable expectations. I regrettably had to take a weekend out over this time, but throughout I kept in good contact with the rest of the team and continued my obligations to the best of my abilities.

Unfortunately, the project was delayed on multiple occasions by Mod DPH, then Lead Programmer, first with delivering the pitch days after expected and beginning programming as far as halfway into the phase. In addition, Mod DPH struggled on multiple occasions to understand and act on task priority, and days before the deadline halted any further programming before the game could be considered as much as in alpha. This caused scheduling to be shifted around and the game never made it to a clear testing phase.

Mod DD over this time provided as much as could be expected given their role/s and time constraints put upon by the other team member. and contributed UI diagrams, gameplay flowcharts and a variety of rudimentary 3D models that never made it into the final build.

I feel like ultimately I may have been too controlling and overseeing of my team members over this prototype, but in doing so I believed I was pushing structure and clear, fair expectations on my team members. While not the role I performed best at, I feel like I performed adequately in my responsibilities, and if given the chance I would enjoy learning how to better myself in a leadership role.

Prototype 3: Jungle Tumble Revisited - Lead Programmer / Art Co-Ordinator

During our last module, I was assigned the role of Lead Programmer, and coming back into things I wanted to avoid the role for as long as possible. By the time it came around during Phase 3, I relished the opportunity to jump back into programming. After we had advised us at the start of this phase that given our previous performance we would be best suited to revising a previous concept as opposed to beginning a fresh one that I had provided. By the end of this phase, we had our first fully-functional deliverable presented.

During this phase, Mod DPH as Lead Designer contributed mood boards and a similar UI design to the one for Prototype 1, but failed to contribute design documentation that would have aided greatly in development and made programming more time efficient. Mod DD was a strong Project Lead running the Scrum method of development and keeping communications strong. By far, this prototype was our best delivered of the three and reaffirmed some confidence in the team’s ability.

Vertical Slice: Jungle Tumble - Lead Programmer / Lead Audio

My previous posts cover how I have evaluated my own performance in these two roles.

Programming: https://endlesslyrunning.tumblr.com/post/160328331262/mod-j-vertical-slice-programmer-evaluation

Audio: https://endlesslyrunning.tumblr.com/post/160327931087/mod-j-vertical-slice-audio-evaluation

Vertical Slice development, while a rewarding experience in terms of experience and productivity, was exhausting above all else for both me and Mod DD, in large part due to the attitude and lack of meaningful contribution of Mod DPH. They consistently demonstrated a pattern of being unable to meet deadlines for tasks (either assigned by Project Lead or themselves), providing code and other documentation of poor quality that it had to be re-worked by one of the other team members, and refusing to take initiative in regards to assigning themselves tasks. Between the two of us, Mod DD and myself have effectively had to contribute an extra person’s worth of workload in order to have the final deliverable for this module in the state that it currently is in, and if we hadn't needed to extend ourselves so far, we could have gone even further with implementing additional features into the project.

This module has been a rollercoaster experience for myself, and I come away from it with a new perspective and motivation to work in the field of game development. It has broadened my horizons in where I might want to take myself in the future and I have learned so much more about programming and the Unity Engine than I thought I could have in the span of 12 weeks. If nothing else, it has left me with a semi-polished vertical slice of a game that I hope to refine, rebuild and eventually see published later on down the line.

But for now, time to sleep. See you next semester.

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.

Coming into Vertical Slice, I had big intentions of taking the audio to a level unreached by any of the prototyping phases, and followed up with research into the appropriate inspirations and having had some ideas about composition. Unfortunately, due to the tremendous workload as Lead Programmer, composition took to the backburner and as time went on the likelihood of being able to compose a unique BGM for the game became slim.

Early on, I added placeholder audio to the system, intending to replace the current clips with revised clips that were either more appropriate to the game world or immersion otherwise. In the end, these audio clips have become our final audio clips. The background music tracks contained in the game are the Boulders music from Crash Bandicoot (PS) in the main menu and a remix of the Bone Yard music from Crash Bandicoot 3: Warped (PS) for the main game. Most of the sound effects, with the noticable exception of the losing horn from the game show The Price Is Right, were generated at http://www.bfxr.net.

It’s disappointing to not have achieved my goals in this role. However, I have learned a great deal from the experience and am confident in my now ability to implement an effective audio system for any future projects later on down the line. In addition, I believe I have gone in my role beyond beyond what was previously established by other team members and myself during the prototyping phases. I feel I have performed adequately in this role, despite not having reached my own personal goals, and will be interested to working with audio inside game development in the future.

Prototype 1: Roles - Lead programmer and tester

Honestly quite a rocky start, without any proper leadership in place, coordination between myself and other team mates was confusing for those involved.

Some communication between the then Project designer, Mod J was achieved but confirmation of decisions was non-existent as the then project lead, Mod DPH was ill making progress sluggish, although I would argue more on their part could have been done over a messenger rather than any of the physical meetings or calls.

I would have overall liked to have more time to develop the prototype build further and delegate programming task, as by the time the programming phase had begun, purely due to looming module deadlines and by no initiation of the then project lead, it was too late to have any real features implemented much to my disappointment.

Prototype 2: Roles - Lead designer and art coordinator

While some leadership was in place as Mod J took up the role of Project lead, there was a somewhat larger focus on organising the Lead programmer, Mod DPH, leaving my roles to an effective free for all; 

While I was happy to contribute and plan what I deemed necessary to the design process there potentially could have been something I had missed which would aid the design process further.

Overall while prototype 2 looked a slight step up on the first prototype I personally felt it was not up to the standards set by our project lead, despite all the modelled art assets I had provided;

I did have some contributions to programming after admittedly heavy prompting, mainly a death state canvas and aiding in some elements in the main menu.

Prototype 3: Roles - Project lead and audio

As my first time as project lead I took some of the previous experiences into account and set up a scrum method of management, during this time I would be checking up of team mates on a daily basis.

Each team mate would be asked to describe what they feel they could do each day based off the vital tasks set on the team trello and I would ask about its progress the day after.

However I did find that little communication in terms of finalising design concepts came from the then Lead designer, Mod DPH and ultimately the mood boards provided held little meaning to the final build, the same could be said for the models they provided little over a week after the prototype deadline and was given to me not the programmer to implement.

In conjunction a large majority of self-given tasks from the Lead designer were never completed.

Some social commitments did crop up however on the then Lead programmers side, Mod J, though I would likely say that considering a majority of the programming of prototype 3 was refining the procedural generation this did not have a huge effect on the last iteration of that build.

Overall I would have liked to had some rough art assets implemented for this version to make it look slightly more appealing and perhaps I should have pushed the coding focus on elements other than procedural generation, mainly some basic artefact functionality to diversify player interaction past left, right slide and jump as the artefacts are the unique draw to the game concept.

Vertical slice: Roles - Project lead and art coordinator

With the previous experience under my belt I made alterations to the scrum meetings from daily to weekly and the focus topics I tried to be more critical of, and encouraged more task delegation as opposed to prototype 3 where I initially trusted teammates to delegate when required.

This meant I could also contribute to the code on top of all the art assets I was contributing. During this phase a few of the other modules tended to interfere with progress due to their multiple hand in dates meaning I was missing 2 team mates, and as such progress was slow.

Unfortunately a common theme throughout the slice development, the then Lead designer, Mod DPH, failed to meet expectations when tasks were delegated, either by myself, the then Lead programmer, Mod J, or themselves.

Meaning both myself and the Lead programmer had to coordinate to fill the more vital parts of the design role.

In conjunction to the absence of a role, any programming tasks the Lead designer set out to do was immediately followed by the request to help them complete it, rendering the point of assigning them said tasks redundant, and potentially hindered progress by having to assign time to troubleshoot issues or rewrite scripts completely, as is the case with the loading screen.

And a final note on testing phase from the then lead tester, Mod DPH;

Testing and player feedback documentation was uninformative and influenced very little during the bug fixing phase as a majority of bugs raised were already known or on an old build at the time. 

Overall I am pleased with the final vertical slice the art assets, audio and mechanics meld quite well for the time span we were assigned.

I will certainly look forward in the future to continue working with Mod J.

_________

- Mod DD

Originally in the black market menu if the player selected any of the artefacts, either owned or not a section of text would give a brief description of what the artefact does as well as some character flavour text;

For example:

‘The Money magnet artefact, used to draw in coins, and coin bags adjacent to the user.

I shan’t be running out of pennies for the arcades any time soon.’

_________

- Mod DD

Main menu:

Black market menu:

Options menu:

Quit game sub menu:

Highscore menu:

Game session:

Pause menu:

Quit to main menu sub menu:

These are the final art assets tied to the UI functionality.

_________

- Mod DD

Totems:

Player: 

Environment:

Boulder phases:

Artefacts:

Rewards:

These are all the finalised models for the vertical slice.

_________

- Mod DD

To add to the charm of the game I sought out to create a shader where a black outline would be present around the edges of an object in game, however due to time restraints I was unable to refine a custom version of a shader.

Instead a free unity store asset shader was implemented.

While not too refined it still meshed with the theme concept well enough to remain in the project.

_________

- Mod DD

Alternate models/retextured models of the player or the boulder were ultimately cut due to time restraints.

_________

- Mod DD

While a single high score screen is present in the final build, originally it was planned to have more than one highscore, acting more akin to a leader board.

On top of this there were going to be differing tabs for the player to alter between showing the high scores for;

- Total score

- Profit score

- Distance score

Each of which along with showing the top 10 scores in the tab would also display what artefacts were used in conjunction.

_________

- Mod DD

Once the idea of a lighting system to alter the time of day was proposed I set about creating a lighting director which connected to the three point lights set up in scene. 

After a set time these lights would lerp to an appropriate colour to reflect the time of day.

I.e early morning having a light yellow tinge, mid day having a bright slightly orange tinge and finally night which would have a cool blue tinge.

Which in practice the director might have worked but the lead programmer was unable to test it’s functionality, and as did I due to the amount of art still required at the time.

_________

- Mod DD

It was agreed that at this point onwards a further sprint was unnecessary and any final tweaks or polish should be communicated to other team members as and when they were found and sorted out as soon as possible before the final presentation on [02/05/2017]

_________

Previous sprint goals:

- Lighting system (Day/Night cycle) = FINISHED

- Player prefs = FINISHED

- Chunk refinement = FINISHED

- Player animations = WORKING

- Model refinement = FINISHED

[Key] PL - Project lead, LP - Lead programer, LD - Lead designer

_________

- Mod DD

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.

I have handed out questionnaires when people have played the game for them to fill out giving us information on  what the game did well, what the game did bad and what the game could improve on.

Here is an example of the results from the questionnaires

And here is the feedback synopsis that I have written laying out clearly the results of the testing.