What went right
1. Level Design
Upon taking on the project amongst us, our first team and first game. We had no ambitions as to any level design apart from setting up our basic levels to teach the required core mechanics within the game, from movement to using our token pickups which change your Agents ‘mode’.
With the base tutorial levels, they were set up in a very efficient and simple manner, utilising core elements such as player direction and structured in a way where the players had learnt everything the mechanics could do after tutorial level, and build upon those skills while learning the other mechanics in the next levels. This was efficient, given the deadlines we had to meet and so efficient that we ended up having time to do an extra five levels all while polishing off the game at the end of development.
With our extra levels, we had each member of the team design a level each to give us all an opportunity to show of our skills and add our own flavour to the game itself. This proved to go very well, with an equal amount of work being spread out to the team and giving the game itself, more of a variety of gameplay. We have a fast paced level, a level focusing on memory, a level focused on exploration and levels more situated around specific mechanics. All in all, our level design was more than I could have ever hoped for, even if I myself would have chosen to do things differently.
2. Testing
The testing phase of our project using our prototype was done perfectly. We had a form set up on Google forms in which our team members could edit from their own devices and it was structured in a way which was not boring.
We recorded gameplay relatively easily using Camtasia Recorder (would have used OBS but, time and hardware admin privilege restraints in University facilities prevented this) and were able to go over how each player attempted to play the games or any bugs they encountered during the testing. The form and videos sometimes went against each other and having both was key to figuring out what exactly needed to be changed, added and removed.
Our testing phase dramatically changed the way we did a lot of things from some level design to asset changes.
What went wrong
1. Communication
What happened
At the start of the project, the team was more than happy to meet up once a week, sometimes on a Discord and sometimes in time after class around a table, to discuss, debate and plan out what our goals, expectations, ideas and overall what the game would turn into in the end. Our Project Manager would arrange with all of us individually/as a group and find a time available.
During our first meetings it was largely debate and hearing the different opinions on why an idea would/wouldn’t work but unfortunately, not long after it quickly moved away to a more confined area within the team.
Many of us were absent during the period near study week and around this time, we weren’t having any meetings or structure set in place. The only thing we had was a “to-do list” made by our Project Manager. It got to the point where team members were getting demotivated due to having less influence and input on the project itself and this is largely due to the lack of meetings and direction given.
Me personally, I stated near the start of the project that although I was the only experienced Artist on the team, I didn’t want to do it all it. This quickly devolved later on into some team members making sub-par quality artwork which I felt wasn’t even up to the standards of what a teenager could do in Microsoft Paint and in turn, I became upset about the direction of the art style. Expressing this was met with neutrality yet nothing was done about it.
This could have been solved if team members who wanted to do art came to discuss and maybe ask for help from myself, being the artist on the team but team members decided to just go and get work done so it is out of the way, rather than communicate and work with each other.
Suggestions of using tools such as Google Calendar were largely ignored by management.
What could have been done?
I feel like a better approach to our communication could have been taken by working out a mandatory time for all team members to meet in the next week in advance. Using a tool like Google Calendar could have let us all individually slot in the times we were available and using this, the project manager would choose a time for us.
This small addition to our cycle would not only have increased our general motivation to the project but maybe lessened our other problems with the development cycle.
A google form could have also been made by the project manager for each team member to fill out after a meeting, to give the manager an idea of people’s individual feelings they might not have had the courage to express in a group environment. This would enable the project manager to understand everyone’s perspective and adjust accordingly, to realise everyone’s potential and motivate each team member differently.
2. Team Structure
What happened?
Upon the beginning of It’s a Blob, we all decided we were going to work on multiple aspects of the games’ development as to not confine some team members to not being able to work on something they wish to learn more about, like level design or programming for instance.
Quickly, along with lack of communication, our lack of defined structure had some team members completing work which could have been more appropriate to other team members and also, left out some team members from being able to complete certain aspects of development.
Ben was a valued member of the team, who did most of the code and construction of the experience itself and Robert our manager, completed a lot of that code as well. I myself, was not interested in the coding aspect for this particular project as it is going to be something I will be able to learn from scratch during the start of my Bachelors and I ended up creating the base structure of our UI state machine, something which could have been done by another team member. It was my fault in that at the time, I said I could do it though it could have been out of the way more quickly and maybe even in a better state than it came out, if it was done by someone was wanted to do it.
The lack of structure in this case made some jobs more prolonged than they should have been.
What could have been done?
With a more set structure of what we originally decided our main roles were going to be, the project not only would have went more smoothly but had less clashes and in turn, provided more knowledge and skills to each team member.
If each team member was given a main role and if they wished, selected one or two ‘learning roles’ they wished to do, not only would each team member focused on their individual skill set they were most talented at but they could have also helped the other team members who wanted to learn more about their roles.
With this structure in mind, if someone runs out of work that week to do and wishes to do more, they can sit in with the other learner roles for other pieces of work and learn more skills while collaborating more.
This approach would be more beneficial to smaller less experienced teams though in ways, it would benefit any development team. Having these learner roles set up in bigger companies could be done once a week and could potentially decrease huge aspects of crunch time for positions which might still have a lot of work to do while other positions who have done everything required, if passionate enough to increase their skillset, have the opportunity to from experienced industry members in their own work environment.
Conclusion
Overall, our successes came from our unique perspectives being applied though our problems came from management and a lack of experience of that management. We’re all in education and not a work environment so while some of us try to do everything, some of us lose sight of what they need or want to do and that showed through the team.
Many lessons have been learnt from this project, lessons which can be used to not only better handle a smaller indie development team but to give motivation and structure to a team full of multi talented individuals. I have no doubt that twice the amount of levels achieved of ten could have been created to better explore the mechanics we created and come up with more unique game design itself within this project if our problems didn’t exist but alas, this has definitely been a learning experience for all involved and we’ve come out of this project with more experience and an idea of how to work with other people.
Development Information
Developer: Infinity Games
Release date: Dec 2017, PC & Mac
Link to game: https://lazareth13.itch.io/its-a-blob
Development time: 12 weeks
Number of developers: 5, (4 at a later point)
Development tools: Unity, photoshop, visual studio, monodevelop,
Budget: $0
↧