top of page
During my year of study at Rubika France (2016) I joined a team of 5 to participate in the Imagine Cup game development competition. For its first phase we had to submit a PowerPoint presentation for a concept we wished to build from in the next phases. We called ours "Beasts". The team was composed of two designers, two game artists and one game programmer. My main responsibility was the level design.
During the year of study at Rubika France I took part in a 15 days assignment which consisted in creating a prototype with a team of 20 people using Unity.
The challenge was important on the organizational side. We had to handle various difficulties that came with having as many people working on the same project :
-
With limited time, brainstorming and selecting a concept rapidly in a way that would include and motivate everyone (presentations, votes, etc).
-
Allocating roles accordingly to the varying skill level (especially with the way teams were made).
-
Find workflows that allowed us to have multiple people work on the same project simultaneously (use of source control, keeping track of the different tasks, regular meetings to stay coordinated).
-
Handling conflicts.
In the end my team produced a prototype we called Kundalini. In the game, the Ouroboros (the world serpent or the snake that bites its own tail in some mythologies) has awaken and its anger threaten the consistency of the world itself. It rises from the continents and the oceans, with fragments of the Earth on its back while creating catastrophies on the surface. The player incarnates "The Messenger", a divine being with the form of a Stingray, climbing up the Ouroboros to soothe him before it is too late.
Mechanically speaking, Kundalini is a Runner in which the player controls the character to avoid obstacles around the circular body of the Ouroboros. The Stingray can move smoothly left or right, it can dash in these directions once every few seconds or dive in the water around the serpent for a short while.
Creating a satisfying game feel was an important objective since we wanted to achieve a sort of dreamy, contemplative tone for the experience.
(Moving the character around the Ouroboros)
(Moving the character around the Ouroboros)
Personally as part of the design team, I was initially among the people that defined the mechanics of the character.
Later on, I joined the team that was mostly in charge of conceptualizing, documenting and integrating level design elements. In order to create a sort of interesting symbiosis between challenge and aesthetic, we worked closely with the art team to define the characteristics of the assets we needed.
I also worked on design elements that existed on a more "macro" scale, eventually we were not able to implement them because of time constraints.
(Example of asset combination in order to create interesting challenges and points of view)
(The circular nature of the levels had us thinking progression in a singular way)
What was a success :
-
The integration of the core mechanics felt very satisfying, the 3C's especially.
-
We came up with enough complementary level design elements to generate diversity in both challenge and look.
-
Early project management was really smooth.
What went wrong :
-
As we were adding things to the game and especially the levels, the performances got worst. It reached a point when it became hardly playable, even on high end PCs. This problem slowed down everything else in the middle of the final rush. Some people were mobilized to find solutions and had to stop what they were working on. Levels could barely be tested. The art team stopped adding and tried optimizing. This crisis could have been probably avoided if the different teams communicated on the matter early on and came up with standards, rules for assets and levels (LOD system?). We could have probably put someone on this issue from the beginning.
(Short clip of the final prototype. In the end, as an urgency solution, we had to sacrifice much of the art quality in favor of gamefeel)
bottom of page