Our Expectatives & Speculations

It was a cold morning in February 2020, and we entered expectantly and impatiently in the not-very-architectural Barcelona building of the Center for Image and Multimedia Technology (of the Universitat Politècnica de Catalunya), some of us just after warming up in the bar next door, breathing the sea air, air that was also tense when passing through our noses, but a kind, friendly tension, in which we all imagined, expectantly, possible structuring of the group, possible topics on which to develop, themes, mechanics... We all dreamed and yearned, happy for our colleagues, what we could get at their side. And it was no less when, all of us, in the class, as if we were fans watching Iniesta's goal against Chelsea in the 92nd minute, we fell into a shout of celebration knowing that we were going to work based on the Netflix The Witcher series, a series that was very recent and with which we all, in some way, felt related either by the same series or by the game, that despite its many possible reproaches and praises, we all knew that, for better or for wrong, it was a success story from which top depart was overwhelming and exciting.

Since that morning, with the confidence and admiration that we had among ourselves as a team, and with the capacity that we believed we had, expectations were already set and speculations flew high over Poblenou, expectations and speculations that were reflected in detail and structured, under the dedicated and meticulous design direction, in the proper documents in the first concept phase, documents that easily exceeded 100 pages or more, and we were clear: fast-paced beat’em up, become stronger the more you play, replayable, cooperative and conserving The Witcher series’ magic. With that in mind, we all sat down immediately on the sofa, in front of the TV (if we had not already done so, or for the second time) to watch the series, scrutinizing it and seeing what we could get out, seeing what had to be exploited, and we had it in front of us: 4 players, and massacre. Despite the advice of previous students, and even knowing it, we expected a lot, perhaps too much, perhaps we even exceeded our own reality as a team (also encouraged by the teachers/product owners themselves, which asked features without shame or fear), although despite that, we cut properly and without fear (and we knew that it would have to be done) many of the things that had been designed (such as the skill tree), since excitement does not make a game (although it can help), the hours of work does. However, in this sense we found a good balance: we did not aim low, on the contrary, we aimed very high, but we knew how to cut enough, so that in the end we did not crash terribly against the ground by going too low or too high to fail.

What went wrong or what we could do better

Communication, Initial Work Methodology and Organization

The challenge we faced was clear: to build from scratch our own engine, and, on top (and meanwhile), build the game. At the very beginning, the fear that gave us, made us to work very carefully in the Engine, while at the same time, the time constraint made us work under a inhuman pressure to have all what we were asked as soon and as complete as possible, so the code reviews were not much demanding, converting the engine with which the designers had to make the game into a bugs and crashes nest. This also make the engine programmers no to work very close to the designers and artists, effectively separating ourselves in departments instead of scrum groups and practically make us fall in what everyone wants to avoid in videogames industry: waterfall methodology. And that was insane, waiting for people to end their work to make a new build is the worst thing that can be done. With this, the team organization in class (since we tried to fake this “scrum methodology” instead of making a practical waterfall), was perceived a bit as something done because of facade, and mixed with the little chaos we had organizing the Google Drive (main tool used for team files sharing), the first failure of this project was served and shown before us as a big ugly monster that we, somehow, manage to fix - partially - in the end.

As anyone could imagine, this situation lead to a lot of communication problems that we sadly dragged until the end, and affected everyone, and we have lots of examples to draw this, from a more general view, in which the art team didn’t knew some feature was in the Engine or some designers didn’t knew how to use it and didn’t asked for help, until more specific examples; for instance, the audio programmer didn’t knew that the credits scene was going to be an interactive-action screen and made the audio for a quiet and chill screen, so he had to re-do the audio of that screen. Also, the designer in charge of coding the Lumberjack enemy rode in anger when he discovered someone had touched the size of the enemy, making some bugs to appear. And situations like this happened more than once. This examples are a clear sample of communication problems and lack of caring, which actually got worse due to the COVID situation of confinement, which made the team personal interactions to decrease (and to be difficult to reach to everyone at a 100%, which in itself is difficult physically) and to introduce a sensation of dispersion, and one of the main problems here, a part of all the previous stated, were the meetings: they were long, slow, very specific for the quantity of people who attended, sometimes redundant and difficult to keep the attention.

For other projects, it is critical to find a way to have a clear, fast and effective communication channel, like a game changelog, little and short meetings with different people working in different areas and departments, forcing people to meet, to be in discord working, to have a common place in which (physically) to work together (if there is not confinement), effectively apply Scrum Methodology from day 1...

Features Testing, QA and The Spaghetti Game

“It works on my machine, it should nicely work” - said once someone, just before pressing the button which triggered the whole engine or the whole game to crash. Yes, that happened to us. More than once. And it is something that you don’t accept until you crash your head against the wall more than once, which we did. The fact is that something is not done until until it is added into a game build, aside all the other features (and in a branch, away from the main one) and works perfectly, with no crashes. Otherwise, you can consider it will crash, that’s as it is, since if there is a single, only one, just a little minor bug, is your job to test it, find it and fix it, with no punish, is just normal in videogames development to have bugs, the problem is when they pass, without being tested, into the main branch, with all the features and from which the final product is being built.

Now all this becomes much, much worse when there is no practical Quality Assurance for the product being built. One of the things we failed in, was to have almost no QA, specially until the final 2 or 3 game builds, and that can kill you, since stress is one potential factor for a heart attack, and this will cause you a lot of stress. And it does, because even with lots of tests to each branch with a feature or something, is unavoidable to have some bugs, and those can be tracked and fixed with QA sessions (since they are not normally hard to fix if the things are correctly tested in the branches before passing to the main one), so, if there are no QA sessions, there is no bug fixing of details that can make you pass through a hell when presenting the delivery, and worse, they can make you feel frustrated, disappointed and depressed.

And to end with this section, we would like to mention the Spaghetti Game or Marshmallow Challenge, a team building game made to understand the team dynamics (and the behaviour of different people in teams), but also, and very important too, to understand that the best way to deliver anything, is to keep doing small builds, with few features, and keep going adding things on top of the previous build (checkout this TedTalk to know more, thanks Ricard Pillosu for teaching us this), this way is much easier to make QA, to avoid crashes and bugs, and to actually make the development process easier and more fluid.
Well, that’s one of the things we undoubtedly crashed and exploded. We didn’t made build with short time periods or with a high frequency, we waited until having, all the features, all the things we wanted to add, all the fixes we wanted to do, and then, we did builds (as we said before: a waterfall process). Well, that’s completely wrong, the most important thing is to do little builds with little improvements and have a progressive final-product construction, this way everything feels more “healthy”, less stressful (better QA, less bugs…), and furthermore: a feature doesn’t has to be absolutely finished at its 100% to be added, we could have allowed ourselves to introduce features that were not completely finished having in mind that we would have progressively finished them (and even more, something doesn’t has to be at a 100% to be felt completed!).

The Project’s Rollercoaster

The last thing we would like to mention in “What Went Wrong” section, is the roller coaster sensation we had during the project’s development, and this is extrapolable to all kind of areas. We think that there were many things that were unequal that could go better if they had been more equal, if there had been a better distribution.

Beginning with the amount of hours spent, is freezing to see that there are some people who dedicated more than 80 or even more than 100 or 150 hours to the project while there has been people who dedicated from 10 to 30 hours. And it’s even more freezing, unfair and violent when these people laughs about this situation or, even worse, complains that their work is much and undervalued, specially if they work is something that make other people (normally those who spend more time) to crash their head against the wall to fix it because it’s failing. Yes, that happens, probably in lots of projects, and there is no equation to solve it, specially in this case in which we are students, there is a decision to make in which you whether face the people, honestly expose this problem and maybe take some decisions that might not be comfortable for yourself (like making someone fail in its mark), but, particularly at the end, this is a problem that might bring some people (mainly the ones that work the most) more than one head burn, so there should be some secured balance in load and time as soon as possible, it feels bad to see always the same people eating the crunch, fixing the problems introduced by the ones who didn’t work much.
Then, there might also be some problems regarding people relationships, some personality crashes, ego problems, insecurities and risks that mark some decisions… The more effective way to solve them, is to talk about it, as much as possible, and to find a healthy and secure environment in which everyone can express their thoughts and their feelings with respect to whatever they want, this way the feedback is constant and the people is less nervous and tensioned. At the end, if something goes too far, the leads and producers have the last words on anything, and they will have to make it value and make it respect, explaining always why inside certain limits, they are in their position for some reason, and we think everyone should accept that.

Finally, about the title of the section, as you may guess, it’s due to the project’s context: it always fell as a rollercoaster because all what is stated here, build that they work then they don’t, unexpected non-tested crashes, builds that came out very well… The project fell as a constant up and down, and with that, our feelings and morale, highly marked by the results of each deadline. Luckily for us, we never gave up, which is the most important no matter what, and at the end we could find some ways to improve the communication, the QA sessions (heavily increased for Gold)... And everything went right (we know not every project is the same, though!).

What went right or what we did well

The Team

This is a very important element, the team. A team without cohesion, without good vibes, is bound to fail. And ours, despite the problems we might had, it was a team with a strong cohesion (in part for the three years we have been together, working close), a good compenetration and understandability between each others, but specially, we trusted each other, and that’s a very important thing when working with some other people.
This gave rise to a natural environment of fellowship and a comfortable atmosphere. This in itself, alone, is not enough to make it all work, in addition, we had the right people in each department, good people in the technical level (in all the departments, despite the low experience), always disposed to help, and in general, there was a lot of people with a good sense of responsibility and very professional with which you could also be partying at night with no problems, so we had a very nice chemistry between us. All that, aside with the desire and care we got (not all the people, of course) of doing the project, and despite the problems we had, make the team to work.

This is doesn’t mean to say “we are the perfect team”, we are just saying that we have been a good team, and why do we worked well. In the end, there is always people more attached to the project and working more than others (as we said in The Project’s Rollercoaster section), and others that will complain more than they work, that should be avoided as much as possible, but from our perspective, is not 100% avoidable. However, in the end, the vast majority of the team was at their maximums.

To not to highlight only all our good things about the team, we might lack a bit of team construction in the beginning of the project, and some statements of common objectives, which might have solve some problems of the ones we state in the Communication, Initial Work Methodology and Organization section.

Balance on Engine Features and Tools

That’s something to take into account in a team developing an engine in which a game of the same team is being developed, the balance between engine features and engine tools. In our case, we gave more importance to the game’s final quality, so we developed some features even in the last weeks of the project. However, there were some tools that we considered necessary in terms of engine usability so the people working with the engine didn’t killed themselves, like the multi selection tool. However, as it can be understood, developing this tools makes you spend the time in them and not in other useful features, such as post-production effects, and you cannot be developing the engine until the last day, because you need to mainly focus on the game, so you need to talk with other teams to reach a balance, and that was one of our strong points.

Adaptation to our Limits

And we mean it, literally, we adapted ourselves to our limits, if the limits were a wall, and we were a sticky fluid, we would be literally a decal on that wall. And that felt nice, our art team were pushing hard against the limits, they demanded very high standards for our programming knowledge context, and we could make it to reach them (although not all of them exactly, but most of them), which not only had a direct impact on the game’s final quality, but also make us all learn a lot (specially to the engine team).

Team Management, Production and Leading

This section is a bit a part since we considered that it has been a very important pillar in our trip and had both good and bad things.

Starting by the bad things, there were mainly related to communication and organization (which has been already explained in Communication, Initial Work Methodology and Organization section). We weren’t a bad organized team, but we got some holes to cover. In addition, we sometimes were a bit disappeared, due to the amount of work, we didn’t give the maximum time to organization and leading, and that’s something we should have covered. In addition, in order to solve the problems related to time spending (see The Project’s Rollercoaster section), we implemented a strikes system of punishments for people who worked very few, and that had different reception (negative from some people, positive for others) and was a bit controversial, but in general, we think it went well, it worked, but there were some comments saying that it arrived late (over the Alpha 2), mainly because of the fact that we were companions, and not teachers, and very strong.

Finally, as a minor detail, the nerves are easily passed between the teammates, specially if they come from management team, and that’s something that any manager should know how to control: the nerves, particularly in difficult and critical situations.

Then, about the positive things, the management and leading of the team was, overall, good. People’s general thoughts were those, that we did a good job, and the problems we got were normal, having into account that was our first try in a team as big as it was, having no idea at the beginning on how to move forward, and with the only experience of the other university projects, with teams of 6-7 people at much (and most of them in couples). The general feeling is that, naturally due to experience, it progressively improved a lot, and in the middle of the project, when we begun to work properly with the Scrum Methodology, it was noticed: the meetings got shortened and with less people, before the final builds we made lots of QA sessions, we grouped ourselves in little groups…We knew perfectly the whole theory about the scrum methodology, and that was the first time in the degree, in the career, in which we successfully applied it (and we could have done it before, but we had lots of difficulties with the COVID situation and the fact that the engine was built from 0).
But most important: we knew where and when to cut, and where and when to risk, and that’s the most important thing of this section. The time we took was the correct, to think about features to throw away, things to add, things to delete, things to move forward with… And the decisions we took on respect to that, were good. And we just heard people and if we had to cut, we cutted, with no more discussion, and that’s a very important thing to know in a project like this.

Finally, the general sensation, talking to the team, was that the management team knew to have patience, and overall, managed well the team in a difficult moment like it was the confinement. People expected a decrease in the work of the time, and we managed to avoid that, and we can conclude that we had a nice general vision and a well deposited trust, as well as a good accompaniment along the project, at the end of the day, we were also part of the team and we shared desires!

Conclusion: Feelings, Sensations and The Product

Once reaching the final weeks of the development, with the load we were carrying from the different problems we had, as stated above, but with the morale increasing (since the Beta build worked pretty well), we approached towards the Gold delivery with a bit of fear, expectancy, tension (specially because of the people who were coming to see us the delivery day), and desire.
In a part, we wanted the project to finish, we were tired of the much crunch we did in the last months under a very high pressure, but in the other way, we were happy with what we did in the Beta, and that was traduced to a very hard work towards the Gold delivery and to the general happiness that was breathed in the team.

To conclude this Post-Mortem of The Witcher: Ties of Destiny, we would like to talk about feelings. The general feelings, during the development, were mainly two: pressure and stress, and with the COVID confinement situation, anguish. However, also during the development there are times of fun, times of different feelings, times in which we are low and then high, times in which we are just high or in which we cannot progress anymore and we are just low and sleepy, under high pressure, and on top of that, tired, in difficult moments. With the Gold finished, everyone just talks about pride for the result, contentment… The fact that this is the most important academic work of this degree, and the fact that we made it the most cooler of our own until now, and specially, the fact that it’s finished, gives the people a feeling of mental peace and happiness, happiness for the team, for the game and for the project.

In the end, we had built a finished project to be proud of, we strengthen our trust among ourselves and yes, there are things that we could have done better, but still, we are completely proud of the final product in its totality, and there is people which are even happy of repeating the subject to work in this project, so in general, we did a very great job. At the end, people worked a lot by inertia because of their love to the project, to give it their personal touch and the final polish so it could be perfect for everyone.

With more perspective, we think that, with the time we had, addressing the problems we had and doing the game (and the engine) we did and with the team size (30 people), is an exhaustive and outstanding work. In the team, we talk about how we have exceeded our own expectations (needed to make sure you can exceed other people’s expectations), and how was to see the game finished with the feeling of thinking that, if somebody had told us a while ago that we would, we wouldn’t have believed it, we would thought that it was too big and, ourselves, we were going big. And finally, no, we did it!

Finally, the most important: we learned. And that’s the important thing of all this, specially in the University (in other areas too, but specially here), to have a sandbox in which to play, swallow some sand, and fail. Fail a lot. And from that failure, a success like this borns. Many of us are surprised of how much, both personally and technically, we have learned, how much we improved, and we are also happy with the new people we have met, and with the ones we have met deeply during the hours of work for this project.

Thanks to all this, we have a sensation that at the beginning didn’t have, all the contrary, it gave us fear, the sensation that we are ready to enter to the videogames industry with our heads held high, and walking safely and secure. This project, for us, it was worth it, and it has been a success.

Thanks to all for reading, thanks to all the teammates in Broken Gem Studio, to Marc Garrigó Invers, Marc Ripoll Tarré, Joan Josep Pons López and everyone who made this possible!