Reflection

As a whole, I am happy with the end outcome of the game project as we banded together to create a solid experience. The game experience is satisfying and feels complete as the game idea was designed to be modular so not every level was necessary. This project also allowed me to further develop my blueprinting skills further cementing my predilection for game programming.

One of the issues we had was that some assets weren’t created by the specific team member that they were assigned to. To stop this from happening in the future members of the team could be assigned secondary roles in which they will create assets if the primary individual is unable to for whatever reason. This was already the case with our 3D modellers so it is a proven solution and it saves us having to delegate work on the fly.

We could further develop our communication channels to allow all of our members to be able to effectively communicate. One member had difficulties communicating with the whole team for a lot of the development period so we could have spent some time earlier making sure everyone was comfortable and able to use our communication channel.

The main point in my reflection is that we should have had a more rigid schedule to ensure that relevant work was completed weekly so that all the individual work correlates so that aspects of the project can be completed earlier. Our fairly relaxed schedule meant that some of our important work was done later than would have been ideal. If we had a more rigid schedule than we could have probably had at least one more level completed and had some of the less important aspects of our project completed to make the overall project more interesting and enjoyable.

Leadership & Teamwork

As a group we mostly functioned pretty cohesively and could rely on each other to get work done on time. There were a couple of instances where assets was unable to be created but we adapted to the problem and delegated the work to another team member so that it could get done sooner.

Our group leader did a fine job in making sure there was work for everyone to be doing and that it wasn’t too much for each member. His scheduling and management work helped to keep the team members on track so that a constant stream of work was added to the project weekly.

An example of when our team helped one another was when of the other 3D modellers had to assist the main 3D modeller when an asset they had created wasn’t able to be animated so the other 3D modeller edited it so that this could be done. Another example is when our 2D artist hadn’t yet completed our project logo which was needed so another member of the team created a logo asset while the 2D artist worked on other assets.

We decided on our roles based off of what we each were strongest in and most inclined to do so that there wouldn’t be much issue when creating the work. This also meant the skillsets of each member were used effectively making each aspect of the project the best it could be with our members.

To communicate we used a Discord group chat in which we regularly communicated mainly through voice. We sometimes used text if team members were unable to join or if we needed to show something. This was an effective method of communication for us as it was informal and allowed to discuss what we needed to at our own pace.

Example of our Discord channel which we used to assist each other
Design Process

Instead of waiting for the levels to be designed and implemented before I could create the gameplay experiences and other functionality I made a test level to add this before the respective levels were done. This meant I was able to efficiently implement the gameplay experiences when the levels were ready and I could be productive throughout development. Early on, I used a dancing mannequin as a placeholder for objectives being completed.

Player blueprint including item interaction and shooting functionality
Test version of shooting mechanic with placeholder assets
First Level Gameplay Mechanics

An Unreal Engine plugin was used called Apex Destruction to add the destruction effects to multiple assets within the project as it allowed the gun to have realistic interaction with these assets.

First Level Blueprint
Implementation of a system used for the second level which only allowed an action to be performed when an item has been obtained
Second Level Gameplay Mechanics
Second Level Blueprint
Implementation of the gameplay mechanics of a platforming level that wasn’t implemented due to time constraints
Example of the ending sequence and the UI that I programmed to appear after it has concluded
Ending Blueprint

I was responsible for the UI size, content and implementation but the visuals were made by another team member. The wording used in the UI is intended to match “cowboy-speak” to match the setting of the game.

Example showing the illusion of the train moving to make the environment make sense
Environment Blueprint

To create asset animations I used a feature in Unreal Engine known as level sequences. This allowed me to keyframe properties of the assets and control the timings of when these changed. The level sequences are activated from within the blueprints but I also used blueprinting methods to change the properties of some assets if the level sequence wouldn’t work for them.

Example showing the level sequencer interface animating the camera for the ending
Example of the safe animation using mathematical values
Organisational Skills, Schedules & Planning

During the planning stage Max, Jack and I created an overall plan for our project idea which showed the whole scope of our project. The other team members joined later but they agreed with the plan. We put ideas down on a piece of paper for the different aspects of our game. It wasn’t thoroughly detailed but it allowed us to determine a baseline for what we would need to do to make a solid project and give a taster for what the game idea could be if taken further.

Overall project plan showcasing our entire game idea before cutting elements for our final version

The overall idea was to have seven different levels set within a moving train that had different gameplay mechanics to give the player a different experience in each carriage. The level elements and order of these levels was intended to be randomised to make the game more replayable as it would be a unique experience each time.

Our group was organised using a Google Drive document that included tables of work that needed to be done with colour coding used to display the priority and completion state of each aspect. The 3D modellers could choose what assets they would prefer to do and they would add a date when they completed each model. Other members had similar lists for their specific work.

Green = Completed

Orange = Partially Done

Red = Not Started

Example of table displaying the models needed for the game and the completion states with dates
Example of table displaying the levels in priority order and what had been completed for each level

We didn’t set a rigid schedule for our project but we strived to always have an improvement each week of the project as long as we had a functioning game at the end of our development time. Having some of the levels playable with a beginning and end sequence was the end goal.

Individual Role

My main role within the team was programming but I also developed some of the UI and did some basic animation using tools inside Unreal Engine. Being the programmer meant I was responsible for making the features of our project function as a whole as well as fixing any issues that cropped up with these features and how they interact. I only did a bit of UI development as well as making animated sequences within Unreal Engine when it was necessary for the parts of the project I was working on.

Psychometric Test used to figure out what role I should have within the team

I decided that I would rather take on a role that was in more of a secondary position of leadership rather than in direct control as I would rather not be directly responsible for organising the team but will happily assist in doing so. This is reflected in the psychometric test with the role of the Whistler as they are quite important within the orchestra but aren’t the one leading it. The Chorus was another role that I would be comfortable with as I would be content with just having the responsibility of providing my part of the project.

I also stated some of the strengths I have within game development as well as aspects of our project I would rather not or struggle to do. I brought up programming as my primary skill as it is something I truly enjoy. Although it can be a bit stressful at times the catharsis from solving problems is worth it. I mentioned that 3D asset creation is something I don’t really have passion for and that I aren’t experienced with animation which is why these are things that I would rather not do within the project.

Production and Development

For our first lecture of Professional Practice, we were given a small taster of what the module will be like using a task that mimics the processes we will go through for our assignment work. We started by separating a piece of paper into four squares labelled: Design, Presentation, Revision and Presentation. As a class we were then separated into small groups and tasked with making a paper airplane individually within our groups using one piece of paper to make it. This didn’t go very well for me as I couldn’t remember how to make a paper airplane that functioned. I started some sketches to try and show the process of making a paper airplane, but they weren’t helpful.

The first paper airplane design that failed spectacularly.

I folded the paper to try and make it look like some kind of airplane which was kind of successful as it did somewhat resemble a paper airplane. Everyone was tasked with throwing their finished planes from the same point in the room to the other side of the room to see how successful each person’s attempts were. My attempt was a failure as the plane spun around and went backwards. After everyone threw their planes, we were then tasked with improving a plane using the knowledge of our whole teams. However, my team didn’t have much success with the first airplane either so I decided that we should do some research on the internet.

The second paper airplane design based on an internet guide that flew further but wasn’t much more successful.

The webpage I found was a WikiHow article titled ‘How to Make a Paper Airplane’ which gave a step by step guide of how to make a paper airplane. I used this but I made some minor mistakes and then my teammates made some adjustments to the plane to try and improve its efficiency. This airplane was more successful as it actually made progress towards where it intended to go but it wasn’t that much of an improvement. Upon reflection, if I followed the guide a little more effectively our plane might have been able to make it much further.

Rising, H. (2022) How to Make a Paper Airplane. Available online: https://www.wikihow.com/Make-a-Paper-Airplane [Accessed 03/02/2022].