What Went Right
Tools & engine development
One of the most remarkable parts of this project has been the development of one own engine in parallel with the development of the game, providing technical knowledge to all project participants.
The development of the systems of this has been governed mainly by the necessities procured from the different members of the team. As well as the development of different tools such as the map maker which speed up the production of maps.
Fractionate the team into small teams and objectives
First, we started working as a team by departments, although this caused high communication problems. Then we divided these departments and formed Scrum teams so the communication between the members of that teams increased considerably.
Although this didn’t end up being a state of art, since the communication between scrums, with dependencies between them, decreased considerably causing high delay problems at the time of internal deliveries.
As a countermeasure, we formed a Scrum of Scrums where there was a scrum master for scrum and a scrum master that included both scrums. In this way the scrum master of scrums was responsible of making sure of the communication, if necessary, of the subjects that belonged to both groups.
After doing this we achieved a high level of communication, although the Stage of Art wasn’t achieved at any time.
It should be noted that communication was a problem throughout the development, so we looked to optimize the way of sharing information of what was being done. An example would be a google sheet with a list of scenes, the availability of being able to work in each of them and who was working in that scene. This doc was one of the most useful when working, so as not to overwrite the work.
Artistic and design level
Due to the lack of a pre-production focused on the design, there were several problems, although in spite of that, a very high level of design was achieved and adequate for the final product that we had as objective.
On the part of Art, it is only necessary to keep an eye on the final result of the game, without doubt we reach the desired artistic level, taking into account the technical capacity with which it was counted.
Contingencies
One of the most critical points of the project has been the lack of time in practically all the versions, either due to the short time of the milestones or the other subjects with which we had. As we have seen several times forced to cut content in order to properly complete the release. And for that reason we ended up making a contingency plan for almost every scrum, where the critical parts were focused first and blocks of possible content were made that had to be removed.
A very remarkable example was in Alpha 1 where the second phase of the boss was eliminated for that delivery, this was implemented in the Alpha2
Team involvement
After two and a half years in the degree, and after having made several small games made by small groups, we all wanted to get to make a game that would be close to the result of a game made by a large group of developers.
This caused an implication of a large part of the team, resulting in the team's record of work being very high, being able to reach the proposed objective.
In addition, the moral of the team, despite the typical discussions due to the pressure exerted by the deliveries and the coexistence, has remained very constant in the 4 months of development.
Well, despite having a very good moral and involvement, 3 people left the project. In general for personal reasons.
Learning
We must also talk about all the knowledge acquired during development, mainly the ability to work in a team and the way we treat our partners.
As stated in the introduction, all team members have been at least once a scrum master, taking responsibility for a small team of 4-9 people, responsible for collecting the different small objectives, breaking it in tasks and assigning everything the group the different tasks.
In addition, the ability to adapt to a technology still in development and possible unpredictable circumstances during development has been encouraged.
What Went Wrong
Communication
As in any video game development team, one of the most important parts to reach the goal, as well as to speed up the work is communication. Being a team of 35 people we have observed that communication is very complex when you exceed teams of 8-9 people.
With the scrums, which were applied as well as the theory says, between 4 and 9 people, communication improved considerably. This does not mean that the communication will improve 100%, it could be seen that the communication between scrums in the beginning was practically null. Perhaps the fault came as a result of the communication between scrum masters, producer and leads with the teams. Perhaps the fault came as a result of the communication between scrum masters, producer and leads with the teams.
Internally and at the personal level of the scrums even in the end there are communication gaps in different aspects, or that some of the members of the team act like lone wolves and do not relate to the other members. Forcing to have to mediate between several people on the team.
Lack of software and adequate hardware
Another failure to highlight was the lack of texturing software in the university, and therefore the work of textures production was slowed down, as well as the lack of knowledge in this field.
On the other hand, the lack of hardware adequate for production led to several times we were forced to go to work at home, since in the right classes for development with certain software were occupied and as the production progressed and the requirements were greater
Audio
The main problem of the audio in this project was the lack of adaptation to which one of the team members will leave the course. In this case he was in charge of all the audio and music.
After the production of the first 2 versions of the soundtrack, the expectations of having a good final audio result increased considerably, making the audio manager take on importance.After a while the boy disappeared due to family problems, this caused a void around this part of the development. This lack we thought was going to be temporary so the production effort in audio was left aside, which caused us a significant decline of the quality of the final product.
At the same time, the audio system was integrated without any problem, adding the audio component and some audio effects such as reverberation areas, attenuations, etc
To the practically 2 weeks later we realized that this lack could suppose a disaster as far as the result as much artistic as playable of the game. So we resume a line of development in terms of audio.This time and after having seen that the required level of recordings & sounds did not reach the required standards, it was decided to extract audios from the game of thrones series, as well as the search of libraries provided by the university.
Breaches of the scheduled calendar & task estimation
After each presentation of each release, the leaders and the producer got together to analyze the presentation, and administer the requirements provided by the teachers for the next delivery.During this meeting, the objectives to be followed were initially set, and then all team members were distributed in scrums.Then, among the members of the scrum, they subdivided the objectives into tasks and assigned them to the most appropriate person to perform that task.
The first failure during the beginning of production was the lack of an estimate of the tasks as such, which made the distribution of work very unequal and inefficient.
After seeing this we apply the estimate of time it would take to complete the task, as well as calculate through Google sheets the daily available time per person and we calculate the commitment of each one of the members of the scrums, being able to see thus the amount of tasks that each one of the members could do
The unreliability of the calculation that could be assigned to the project came partly from the little experience of the whole team in doing so, and the inability we had to predict the level of work that the other subjects were going to provide us.
On the other hand, no experience whatsoever in estimating the time of completion of the tasks, so that only served for the distribution of tasks in a more or less equitable.
Conclusions
Unthrone is the first game we do in a joint 3D way and the first time we work together all class members, with a single objective. Therefore, we have taken a long time to find a workflow with which to feel comfortable when producing.
In the middle of the project we achieved this workflow more or less ideal, with some problem in the communication between scrums, even so the constant level of work and the dedication of each and every one of the members of the group have really achieved a product that meets expectations, despite the audio, the overall result has been quite remarkable. As for the engine, the final result has been well above our expectations.
Communication is one of the most crucial points of development, avoiding a lot of problems, and delays in the development, in our case the communication has been increasing as time passed, even so we have a lot of room for improvement.
As a final conclusion of the project, we can appreciate a level of learning in teamwork as well as in all areas of work in which we have participated each and every one of the members of this team.
You can visit the releases' postmortem there: