Category Archives: Development Log

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.

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.

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.

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.

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.

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.

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

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.

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.