Development Log 1 – Liam McIntosh 16/07/18 – 1/08/18

Taking on a new role

Deus Vault’s team originally consisted of me (Liam McIntosh) and Tom Forwood. Our little team worked quite well, I did everything programming related while Tom did everything visual. However we both knew that if we truly wanted to realise this game that we needed help from others. Fortunately at the start of the second semester we enlisted two new talented members to the team; Rhys (Artist) and Rupert (Programmer). This meant that we could really step up our production quality and make the best game possible. However this blessing also came with its own new difficulties and even role that needed to be filled.

Our team had essentially double in size and complexity meaning that organisation, communication motivation and consistency would soon become a problem. Someone needed to keep everyone in line and ensure that everything was going on track. Now that Rupert was going to take on the brunt of the programming I decided to promote myself to producer/project manager and fill this new role.

Writing the Design Doc

Being assigned to this role meant that I first had to get Rhys and Rupert up to speed with the current state of the game and where we wanted it to go. Tom and I had been working on this project for a total of 4-5 weeks now so we understood it perfectly but Rhys and Rupert had only seen screenshots and videos. In order for our design vision to stay consistent between all members of the team my first task was to write a Game Design Document. This documents outlines every major system and design choice in the game like its vision, theme and feel, combat to sound design. Although this document is going to be continually worked it’s a good base to go back to if anyone is unsure about where to go next.

Project Management

In order to understand our goals and deadlines I also spent a small section of my time creating a gantt chart so that we could visualize progression, tasks and deadlines. I designed this chart around our various deadlines that were spread throughout the semester. This broke our fairly large and complex project into smaller digestible parts. Each millstone/due date will give us a small achievable goal to work towards .This will hopefully keep us motivated throughout the whole life of the project. With each due date that’s reached a small sense of reward is gained, which in turn will constantly push us towards the end goal.

This chart also served as a great way of prioritizing tasks because we could visualize the overall development progression of the project. As days go by we could update the progression of each task and visualize our development. If we ever saw that we were off track we could potentially reprioritize tasks or even re-design the game before it was too late.

A Small Bump in the Road

More people means more chances for thing to go wrong and for people to disagree. Were all so passionate about games and we all believe that our ideas are the best. However no matter how good your idea is disagreements and arguments are never beneficial for the project. They halt progress and they lead to fixations on a single problem and away from the project in a whole.

This means that all parties have to eventually come to a definite solution. This also means that sometimes one parties’ idea is neglected over the other. Although the project is back on track it’s important to acknowledge both ideas and not dismiss them entirely. You don’t want one member feeling ostracized, not listened to or neglected because they’ll lose motivation and interest in the project. When taking on the role of a producer/project manager you need to have empathy for both sides. All member need to stay happy, motivated and interested so that the project can stay on track.

In terms of our problem, mid-way through this period we had a disagreement between how combat could function. For a couple of days we got quite fixated on this disagreement but I managed to push everyone back on track. We managed to come back together by seeing both sides of the problem and suggesting a mutually beneficial middle ground. Our solution meant that we would make both systems and then let players decide in player testing. What better way to make a decision then by letting the players make it for you.  

Revision to Player Movement

Even though Rupert was taking on most of the programming tasks I knew I had to keep writing code because that’s where my passion and talent lay. However when I came back to my movement code I was shocked to see just how poorly written and optimized it was. In the previous semester I had spent so long working on it that I didn’t see the bigger picture. My break away from it proved to be beneficial because I now had a fresh new perspective. So my first task was cleaning up messy and nonsensical code. There were a lot of things that were happening in my code that were ‘working’ but not working in a way that was robust and logical. This meant that it could possibly cause problems later on in development so I had to do it.

 However this meant that it broke many of the elements that made the original movement system functional and fun. So I had to rethink how the system would work in order to get it back to the state it was at previously but with better code. Once I got it to a nice working state I went on by tweaking the system to make feel punchy and satisfying to play.

A major change I added that drastically improved movement was giving particular directional axises precedence over others. This made turning while running forward more responsive and suited the pace of the game.  Before it felt like you were turning through honey which was definitely not wanted.

I also drastically change the way in which jumping works. Originally I had jumping bound to endurance. If you jumped too much you would run out of endurance and become exhausted. Many players and other team members told me that this contradicted point of the game’s fluid movement. They wanted to keep jumping around and became frustrated once they run out of endurance. This was very true but their needed to be a way of limiting player’s jump so that they couldn’t indefinitely jump. We decided on giving the player three jumps that reset every time they landed. This proved to be the perfect medium between both. Players were limited in jumping but never frustrated because running out of jumps were their own fault and not endurance’s.

-Liam McIntosh -