Check it out


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!



The Witcher: Ties of Destiny was born as a student project but has become much more. Our passion and effort has made us really proud of our product. Developed with our own engine and created during this past 4 months. The game is 3D Hack and Slash with fast pacing mechanics which takes place in The Witcher universe.

Game Pillars

  • Co-op Multiplayer
  • Witcher Based
  • Fast Paced
  • Competitive
  • Hack and Slash


BrokenGem Studios is composed of 29 members including myself being the producer, and my colleagues from the art, code and design, each department with a team Lead.


During this 4 month we have used The scrum methodology in order to organize our team and production plan, following the main structure with weekly sprints, daily scrums and finally retrospectives in order to improve.

We have used the agile methodology in order to achieve the desired goal for each milestone, during the entire development we had six delivery builds with an elapse time of 2-3 weeks in between. Due to COVID-19 pandemic we had some difficulties on the development which affect overall the milestones already established before the outbreak.


  • Concept Discovery
  • Vertical Slice I
  • Vertical Slice II
  • Vertical Slice III
  • Alpha I
  • Alpha II
  • Beta
  • Gold


The Witcher Ties of Destiny and Broken Engine were Both developed at the same time, in the last 4 month.

All Art, Design and Programming is all developed and created by our team. Starting from the concept documents and iterating during the process, arriving at our final result that we are eager to show.


The Witcher : Ties Of Destiny

The Witcher: Ties Of Destiny is an action Hack and Slash Beat'em up game for PC, in which Geralt and Jaskier will fight hand to hand, killing all their enemies and overcoming the challenges and obstacles in their way, using their unique skills and cooperating in their way to victory.

The Witcher: Ties Of Destiny situates both characters after the end of the Netflix series. Follow Geralt and Jaskier who are linked by destiny to each other, in their new contracts! Do you have what it takes?




Broken Engine

  • Overview
  • About
  • Features
  • Technical Info
  • Documentation
  • License


Broken Engine is an Open-Source 3D Game Engine built from the ground with C++ and OpenGL by the programming team of Broken Gem Studio.



GameObjects and Components based Entity System, including prefabs implementation and allowing for static setting for objects in order to optimize space-partition (done with Octrees).

JSON/binary-based serialization system. All the assets must be stored in the “Assets/” folder, and a Build System exporting final builds into “Builds/” folder with the desired name.


Broken Engine audio runs fully on Wwise engine, supporting .OGG, .MP3 and .WAV format. The recommended sample rate is 44100 Hz at 160 Kbits/s rate.


Support for blending, interpolation and skinning. Creation of multiple animations via the editor’s animator.


Broken Engine runs on top of OpenGL 4.4, supporting GLSL shaders language for that version, with Vertex, Fragment and Geometry shaders support.

It has, by default, different shaders for the user to use them (and modify them if desired), like the Standard one or the Toon one. The materials and lighting systems have different features such as shadow mapping, some shadows settings, albedo, normal and specular mapping, rim lighting…

In addition (but sadly not included in The Witcher: Ties of Destiny), it has support for post-processing effects such as HDR, Bloom, Color Correction and MSAA.


A complete scripting system in Lua language, featuring scripts auto-complete, a debugger…

Artificial Intelligence

Implementation of Recast into Broken Engine, allowing for Map Navigation features.

Particles & Physics

Physics System based on NVIDIA’s PhysX in its version 3.4, with customizable gravity, collision-layers matrix, rigid bodies, character controllers and different collider types (including mesh colliders).

This version of PhysX allowed us to take profit of the embedded particles system, building on top our own (with plenty of features such as different billboarding types, color and scale over lifetime, rendering and blending settings, collision settings, animations and meshes…).


GUI System supporting creation of different UI elements to use for the game, such as canvas, image, text, button, progress & circular bars… With different features such as animations or anchors.

Technical Info


Broken Engine is to be run on Windows (PC) and supports FBX/OBJ models format (they are recommended to be exported in meters unit).

Profiling with Optick 1.3.


Engine Standard Minimum Requirements

  • OS: WINDOWS 7, 8/8.1, 10 (64-BIT Required)
  • Processor: Intel Core i5-3340, AMD FX-8350
  • Memory: 2 GB RAM
  • Graphics: NVIDIA GeForce GTX 660 or AMD Radeon R5 with up to 1.5GB Video RAM or better, with OpenGL 4.5 API Support
  • Storage: 10 GB available space

Engine Standard Recommended Requirements

  • OS: WINDOWS 7, 8.1, 10 (64-BIT Required)
  • Processor: Intel Core i7-9750H
  • Memory: 8 GB RAM
  • Graphics: NVIDIA GeForce GTX 1050 Ti with 4GB VRAM, AMD Radeon RX 480 with 8GB VRAM, or better, with OpenGL 4.5 API Support
  • Storage: 10 GB available space


Checkout Broken Engine documentation (splitted in some different documents according to each engine area, for simplicity and order sake) in this Google Drive Folder.


MIT License

Copyright (c) 2020 Broken Gem Studio Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Engine based on Central 3D based by Aitor Simona

Copyright (c) 2019 Aitor Simona Bouzas Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

PhysX License

Copyright (c) 2018-2019 NVIDIA Corporation. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  • Neither the name of NVIDIA CORPORATION nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission


Recast Navigation License

Copyright (c) 2009 Mikko Mononen

This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.

Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

  • The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.
  • Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
  • This notice may not be removed or altered from any source distribution.


Broken Gem Studio

We are Broken Gem Studio, a team composed by CITM students (Barcelona) in our 3rd year of Game Design and Development Bachelor's Degree for Project III subject.

  • All
  • Producer
  • Art
  • Programming
  • Design

Adrián Font

Lead Designer

Roger León

Lead Artist

Lucho Suaya

Tech Lead
Engine & Graphics Programmer

Jaume Avinyó

Designer & Gameplay Programmer

Joan Barduena

Environment Artist & Web Designer

Ferran Barnés

Character and VFX Artist

Genís Bayó

Level Designer

Pol Bosch

Game Designer & Gameplay Programmer

Rafel Brau

Character & UI Artist

Èric Canela

Physics Engine Programmer
Visual FX Lead

Pol Casaú


Víctor Chen

Engine & Gameplay Programmer

Pol Cortés


Òscar Faura

Physics Engine & Gameplay Programmer

Jacobo Galofre

Engine Programmer & Audio Designer

Carles Homs

Game Designer & Gameplay Programmer

Oscar Larios

Designer & UI Lead

Josep Lleal

Engine & Gameplay Programmer

Daniel Lorenzo

Engine & Gameplay Programmer

Joan Marín

Engine programmer

Xavi Marín

Environment Artist & Web Designer

Raul Morente


Sergi Parra

Engine Programmer & Engine QA

Oscar Pons

Engine Programmer

Dídac Romero

Programmer & Audio Lead

Aitor Simona

Engine programmer

David Tello


Designed by BootstrapMade