Team Managment

Communication

 

A large part of my role was communication, making sure that all elements of the project are talking to each other and making sure we can have a smooth pipeline, This involves weekly/daily conversations with team members about progress and future forecasts for tasks undertaken and work done. As the project scope was quite large I wanted to ensure there was as little downtime on any of the team members as possible and organising an early pipeline between Ella’s turnaround model sheets and feeding those into Bernie’s workflow and my own was crucial for getting early visual content finished. I made sure that my discussions with Ella were always a week ahead at least so that concepts could be drawn up ahead of time and then fed back to the rest of the team. I made sure that we prioritized mechanics design in the early stages of semester 1 so that we would get prototypes working as quickly as possible, I believed this to be an integral part of our desired ‘feeling’ for the game and I set this high on my priority list. I designed the systems with the Programmer to ensure the programmer had a good idea of the systems and there would be no communication issues conveying anything mechanics related. I also made sure our programmer had anything he needed to test, for example, a 3D test world, any 3D assets, music or users to test with. This meant there was little downtime on the development of mechanical systems (Aside from waiting for sound) throughout the durations.

discord channel.jpg

Above discord server for communication with team members and outsources, below Git Kraken for join work on the Unity project

version control.jpg

Outsources

 

Outsourcing was a large part of the project, we quickly understood that taking on a game about music would possibly require us to work with outsources. We wanted a musician that was interested in making music for games and we happened to find one through a games event at our campus, he was a sound engineering student from the Highfield campus and was interested in working with us to make sound and music for our games. Although we had a discord server for uploading files for presentations and test assets, our server now needed to act far more as a communication platform than anything else, we invited him to the discord and I made sure we had constant contact. As the project progressed we pulled on more outsources, We picked up another sound artist to work exclusively on the final track, (By Sam’s request, Sam being our musical outsource) and we also picked up a VFX artist for some more complicated Visual elements such as particle effects. This brought our core team count to 4 and our outsource count to 3, this had moved from a small-ish team to a large team.

 

Using Discord as a communication platform was very helpful for discussing game related topics remotely as our music artists are based in highfield. Fortunately Sam (Sound artist) came by our studios and myself and our Programmer (Dean) was able to brief him on the game and the game feeling we desired. It was crucial that we were on the same page with him as the music would be one of the main elements that give of the lighthearted friendly vibes of building friendships. We never met our other music artist before the end of the game and so, the description of the final piece of the music had to be described to him via Discord and Sam briefing him on our project outline. Sid (VFX artist) was located on our campus and so conversing with him was straight forward allowing us to test visual ideas quickly and effectively.

 

With outsourcing, My primary role was to drop in frequently with everyone individually and make sure everyone is clear about what they’re working on and that there aren’t any issues. I knew that Sam wanted to attempt an implementation using software called Wwise, a middleware for Unity that implements sound more accurately than Unity’s unbuilt system. I understood and implementation and design of music was far better discussed with out programmer as it was essential that they had a direct line of communication with each other rather than going through me, I suggested they stay in contact and keep me updated with anything if changes were to occur. I made sure to be available to answer questions by any outsources by making sure I have a overall understanding of the entire project, I made sure to have regular conversations with Ella in regards to vision and understanding her ideas for how the game should be, this allows me to communicate this to the rest of the team so we can build towards a more consistent game.

Planning

 

Planning team was somewhat tricky, Initially I worked with the idea of a more linear approach to the project having monthly deadlines for tasks to be achieved by, I wanted assets to be created sequentially, for example, create the worlds, then the characters and finish with animations. It wasn’t long before I realised this wasn’t going to work due to the unpredictable nature of the project, I began utilising elements of the Agile methodology over several smaller tasks and although retrospectively I would have preferred a more iterative process, (Starting on small version of the game and building on it) Our approach was somewhat linear, however the iterative approach just didn’t work with the team, it wasn’t easy to pick and a team of perfectionists won’t leave a part of the project unpolished before moving on. Unfortunately this is a hard habit to break and although we managed to gain some leeway for testing, this could have been improved on generally by all of us. In response to the new work flow I created Trello boards to visualise all of the work ahead and all the work completed, although I found this more useful that the rest of the team, the boards allowed me to prioritize tasks and figure out what wasn’t being done, combining this with regular meetings with the team to make sure I’m fully in the loop of the progress being made, this allowed me to plan ahead before events happened. If I spoke to the programmer about a system he wasn’t confidant was going to work, this allowed me to make a plan B before hand so we could seamlessly change direction if we ran into issues, for example the movement system didn’t work how we wanted it to, so we were able to drop the idea completely and move over to a more basic movement that we could promptly get into the game rather that waste time trying to fix it.

Trello.jpg

Gloria trello board, visualising progress for the team

Decisions

 

I made several key decisions throughout the duration of the final semester. I tried to act more as a guide to the team and project that a boss, I didn’t want to be telling people how to do things or what do do but I wanted to guide the team to making good decisions and try and represent the vision and echo this as best I could. I made calls based on logistical reasoning and the vision of the game and I used these elements to make clear decisions throughout the semester. Decisions primarily involved prioritizing tasks and steering the team away from poor choices, I also make sure we try not to invest too much time into unnecessary ventures, I constantly looked for flaws and faults with the pipelines and workflows and patched these issues if any arose, for example mechanics design was lagging behind the developmental stages, so I moved the team around to have Bernie moving from mechanics to 3D modelling from Ella’s concept art while Dean and I worked on the mechanics, this sped the process up and allowed him to get working on the systems. I moved around from tasks to tasks based on what I thought would be most useful for project, for example, I would design whitebox levels of the world so we can begin testing world space and setting up our narrative events to see how they feel. General game decisions almost always passed through me.

Project Concerns

Milestones

 

One of the major setbacks for the project was quite literally setbacks, I’d have regular sit downs with teammates about timelines and how long it’s take to achieve goals, With Models for characters, they took almost 3 times as long we we’d initially thought, this is obviously a significant missed milestone and meant we had to rethink how we’d work the pipeline towards the end of the project. I also underestimated how long it’s take me to create environments from start to finish, initially I thought it’s take around 4 days to get a level, it took almost a full week including weekends to get an almost finished level that still needed colliding. On the other side, certain outside unforeseen circumstances meant that some of our mechanical system arrived late, this put a lot of pressure on late testing, this meant we struggled to adjust for unforeseen design issues and make according changes however fortunately, the team pulled together and managed a fantastic output towards the end of the project and we managed to pull everything together.We also encountered some small issues with sound that put pressure on our programmer, as sound was meant to be send over a week or two before it was, this meant we struggled to test the implementation as much as we’d like.

 

We did also hit a lot of deadlines that we wanted to, this helped us progress at a nice pace, our media,site and documentary was created with time to spare that allowed us to create a social presence. I tested all of our visual shaders and maps before hand to speed up the pipeline later on and the world whitebox allowed us to test the levels and the pacing of the game. We hit all of our print deadlines and two of our testing session deadlines.

Testing

 

Although we devised several testing session over the period of development, I did not feel that these were often enough and I did not feel that it was a priority for the rest of the team, I stressed how important I felt testing was both from a game bugs/errors perspective but also from a feel/true to vision standpoint. I spoke at length with our programmer about third party testing outside of the team and how this needed to be regular in order to inform the iterations of the project but nothing ever came of this, I offered putting together a team of testers to help out with an outside perspective but I was almost never given builds that users could test with. I feel this will negatively impact the game overall and internal testing, our programmer testing is not an effective way to iron out issues.

Art style

 

The art style caused some of the larger issues within the team and caused disagreements. At the end of the first semester I began experimenting with visual styles, writing shaders and testing different model styles, this ran well over into the second semester and I developed several variations of style that I thought could work. I proposed these to the team but although initially they liked them they ultimately didn’t want any of the as the game style, it was proposed to me to try and unlit style, some of the team had seen this style used in games such as detective frog and they were fans of the style. I agreed to test the style. I spend some time developing environmental tests and although somewhat aesthetically pleasing I didn’t think it was the best style for the game from a personal perspective, a logistical perspective and an accessibility perspective, I didn’t find the style to be that appealing for the type of game we were trying to make, in regards to accessibility the style took a lot of detail away from the environment, upwards of 70% of visual data such as beziers, inclines and corners, I felt that there was too little visual information and it would even be difficult to play a game with that style especially when our game uses the environment and visual styles to help the player as there is no text or dialogue to guide them unlike other games with a unlit style, I felt that new players may struggle and this would go against our accessibility vision, the logistical concern involved a mass retexturing of the environments and additional details having to be added through texture detail that would require the environment design to take almost twice as long to get from design to playable level, although our programmer did find a way to speed this up in the final week of development. This issue was resolved by adam and the style was changed back to a lit style.

Scope

 

The scope of the project became an issue within the second half of the second semester, we knew we had a large game and it only kept getting bigger. Although I felt a fair few elements were quite achievable I was concerned at the amount of content we wanted to get into the game primarily the amount of levels and detail and system that each one would require to be functional. I addressed this problem by making sure no new ideas for additional content made it into the game without cutting something else as it would be logistically impractical to add anything without taking anything away. Roughly 6-5 weeks before the deadline I suggested we cut one of the levels, Triangle Town and all related content. I didn’t feel that this level was necessary for staying true to vision and I didn’t feel it was essential to the pacing of the experience. This was also at a point that the levels hadn’t been created, turnaround sheets for the character hadn’t been started and the mechanical systems were far from even a finished design. I believed that it would take roughly 2 weeks at a minimum from a majority team effort to realise triangle town all the related content and I’d rather have used this time for testing and iterating on existing content. I brought this to the team but it was vetoed, I expressed that as project manager I was concerned for time and that as this is the least developed area of the game it would be seamless to cut, the team consensus was that they were too attached to the character and didn’t want to cut any original content. I understand this perspective and somewhat agree with it and it would have been a different game had we decided to cut the level. We originally worked with the idea of a dynamic movement system that would allow players to walk, run, jump and glide around the world, I assigned this early on to our programmer as I wanted to get a testable walkaround version of the game as early as possible, As he worked on the idea over a period of weeks he realised the system wasn’t working how we wanted it to and although we both liked the idea of the dynamic movement, I decided to cut it from the game.

©2019 by Epticx - George Rickard.