Loading...
We embarked in this three month journey somewhat insecure about our own abilities and knowledge. It was complicated to find common ground between those who envisioned big things for our game and those who had more negative expectations towards our own performance. Even though we had been through this twice, on a smaller level, we found ourselves a little lost.
We began with some guidelines and three pillars to design our game around them: Fast Paced, Cyberpunk, Infinite Replayable. The gameplay had to be based off Torchlight II and the theme had to be Battle Angel Alita. We knew that before our winter break and therefore got our hands on Torchlight and the Alita manga, once we began our classes we went to see Battle Angel Alita together on its release date so we could all get ideas on what parts of the story would be more appealing to cover.
We also had to work around the fact that we needed to use our own engine, therefore we were limited to what we could put together in those months. We had been preparing for that during Christmas with our coders mixing their specialized subsystems, as each member had previously built their own engine with a particular specialization. It still had a long way to be stable and practical but we could begin working on both our game and improving the engine.
Our initial vision was to create an ARPG similar to Diablo, with (M)Alita battling against hordes of enemies sent by her enemies as she chases down Grewishka (Macaco). As we progressed and the game began shifting, with added dialogue and a skill tree system. We debated taking a step back and focusing on a fast-paced combat but we actually were enjoying what the game was becoming.
We worked in weekly sprints, meeting twice a week for a common stand-up and one afternoon a week for lunch and to work together in the same space for around 3-4 hours. This helped in creating conversations between scrum teams, share frustrations and issues people were encountering. Many game changing decisions were taken during our lunches together.
While sprints in the beginning were enough to check on people’s work, it soon became necessary to add more levels to check-in regularly with people’s work, so we could have time to react and make changes when something wasn’t working or someone wasn’t working. We’re a group of students afterall, some people were inconsistent or dropped off. We used an excel for the leads and I to keep track of the status of each task and who it was assigned to, the rest of the team relied on hacknplan to record their progress. During certain sprints and in some critical tasks, we set deadlines to add a bit more of pressure to the team and to stay more on top of the task’s progress.
As I’m writing this we’re finishing up our latest build (hopefully), part of the team is chatting on Discord to make sure all finishing touches are ready and any expected and unexpected issues can be solved timely. I think it is a good time to go over what we did right, what we did wrong both things we learned from this experience.
What went right:
Adapting to our resources
We knew from the very beginning we were set back by our own engine and capabilities. Therefore we took some choices and had coders dedicated to creating new tools for our engine from the very beginning, before we even needed those capabilities (shadows and skinning, for example, were in the works for several weeks just as texture encryption). This at the start seemed to slow us down but it made a huge change in our game once it was ready, improving our quality greatly.
On the other hand, our team had only two dedicated artists, therefore we decided early on to rely on asset packs for most of our environment and enemies’ models and focused on creating our own model for Malita with its own original animations.
Scheduling holidays and work days, excel to plan tasks
We were told to crunch and dedicate all our time to the game during our breaks such as holy week, while we had already gone through a weekend crunch we knew people would not be able to stay 100% committed during those days. This project was our priority but we also had other subjects to work on and many had family to see during those breaks.
With this in mind we made a schedule with everyone’s available days so we could organize tasks during those days and keep the project in progress every day while everyone could have some days off for themselves and their other duties. This proved very helpful and helped us in keeping track of progress and knowing who could work better on what.
When we had a consistency issue and switch from pure sprints, we created and excel with deadlines for every single task and checked on the assignees before the task was due so we had time to react, this proved so helpful we sticked to the excel for our own organization until today.
Work in Communication
Midway through the project it was made obvious that people were not communicating effectively between themselves. There was a lot of frustration between the team and everybody was becoming a little passive aggressive in their comment at times. We had an anonymous 360 evaluation of each team member adding positives and negatives to everyone's attitude and work.
We also began a Top Team Member of the week vote that was voted on each sprint and the winners got a little snack and the acknowledgement of the team.
This situations created more dialogue between members and the anonymous evaluation changed some people’s attitude to a more committed one after seeing their team’s opinion and frustrations.
While conflicts still arose, we tried to deal with them calmly from the leads and my part and transfer that attitude to the rest of the team.
Finding the right people for each department
As we progressed we switched people from their initial roles even having designers dedicated to code. We had people that showed special interest and care for a specific element of the game dedicate all their work on that. Some areas that had a dedicated team member by the end of the project were gameplay, particles, graphics, UI and audio. This, in some cases, like in particles and audio, meant changing the responsible member a couple of times until we found the perfect fit for it.
What went wrong:
Underestimate audio and UI
For a very long time during our builds UI, especially UI art, and audio were our last thought. This brought us a lot of problems last minute when trying to add sounds and creating adequate art for the UI. As time went on and we began realizing the importance of those areas we assigned dedicated members to each area, but it took us a while and we could’ve probably gotten a better result in those if we had realized it and had taken action sooner.
Greed
We had big ideas when we began and did not set our foot down soon enough. Therefore a lot of our time was wasted in thinking and creating elements that went to waste, creating frustration between the team members that worked and iterated them for several weeks.
We initially had three levels and a more intricate story, with three boss battles with two separate bosses. We ended up spreading our resources and time too thin and had to cut one level and the boss fights entirely at alpha. The third level had already been added to our engine as a placeholder and a model for one of the bosses was already in the works, this wasted time that could’ve been better used in other areas.
Assume only coders can code, etc
One of the things that slowed our work the most was lack of initiative and decision-making by coders in areas of art and design, designers in areas of code and art and artists in areas of code and design.
When a coder was programming gameplay they waited on the instructions of the designer to follow them word by word, and when it turned out that it didn’t work as expected or it wasn’t as good of an idea as they thought they everyone shifted the blame to one another.
At the end of the day, all of us, regardless of our forte, have taken the same classes for the past three years, therefore we encouraged everyone to take their own decisions even if they were labeled “Coder” or “Artist” and had to take a design decision, the important part was iteration and testing. Getting designers and artists to help each other and touch the code, or scripts was just as game changing.
Late builds
We worked in different spaces as everyone was developing different elements of the game, and we relied too much on the thought that everything would work once put together. As we now know it is the worst decision we could make and the worst issues appeared once everything was put to work at the same time.
Even though we tried merging elements during the week, we still relied on the last couple of days to work on new elements and merge then last minute. Not as many issues surfaced, as some elements had already been put to test together, but there was still room for improvement.