We are two weeks into major production for Baroviet, and at this stage we working steadily towards an Alpha build. We are in communication with our sound designer to make sure these goals align as well.
Currently, the designer (myself) has completed grey boxes for six levels. The remaining levels will be more difficult levels and are currently on the back burner. They have yet to be designed.
The artists have almost completed all character animations and are working on the terrain building/environmental assets for each level.
The programmer is working on the character controller and updating all scripts from the prototype so they are at a higher level of polish.
As a team we have decided it would be valuable to write blog posts outlining our approach to each of our disciplines. I’ll be covering my approach to Baroviet’s design, and also will go over our approach to production.
Baroviet has greatly evolved from its initial roots. We initially had a much more complex vision for the game involving isometric perspectives and four lenses. It was wildly over scoped, but I believe these early iterations really helped us nail the vision for the game we have today. We went through approximately four or five versions of what the game would be before we settled. I wrote up several small pitches, with gameplay concept sketches, to pitch to the team. We got consistent feedback from Jennifer Scheurle on these pitches and all were ultimately rejected.
As it stands now, we define Baroviet as a 3D minimalist puzzle sidescroller built for the PC where a lost girl harnesses the powers of a spirit to visually and physically change the world around her, all in her attempt to escape her fate at the hands of her hunters.
In terms of design, the most significant factors for this game are in the design of the lenses and puzzles. Obviously, everything ranging from movement, to camera, and feedback are all important. However, these two seem to be the ones that evolve the most.
The first and most important step was, of course, defining the parameters for each of the lenses. What they could and could not do was essential as the base mechanic for the game. The entire gameplay revolves around the ability to toggle these lenses, and thus it was important to define these. Once I knew what they were and how they would be used (i.e. spirit would be used to find platforms across gorges, shadow might kill a spike plant in your way etc.) I set about sketching out levels.
Below is an example of these sketches:
These sketches were essential and often went through several iterations. I have a book full of them already.
There’s nothing too pretty about puzzle design. It involves a lot of iteration and thinking about how a player will approach a puzzle. These sketches are only the base line, too. There’s no surefire way of knowing how players will react or play these levels without conducting play sessions. These puzzles will go through a lot more iterations once we get play testers and feedback.
Moreover, another useful design method was creating a skill chain. A skill chain outlines player progression in skill, and how they will learn each new mechanic and method in the game.
The skill chain outlines what is assumed knowledge from the player, what will be learnt, and how the player can apply this new knowledge in game. An example of part of the skill chain for Baroviet is below.
Now, I will detail our current approach to production so far.
The production method the team is following involves translating designer sketches to finished levels.
For example, the following was a level design sketch made by the designer outlining the progression of the player through a level. It outlines what each element is and how the player would interact with it based on the mechanics set.
This was then translated into a greybox by the designer. This involves using all currently implemented mechanics, such as spirit platforms and shadow death, to make a playable greybox level. This also outlines how far the player can jump and plots out the placement for all platforms.
This was then taken and a paintover was conducted. The paintover was both an artistic vision of what it would look like and also an important reference for how terrain would be modelled. The artist would use the paintover as a reference and modelled the terrain in Maya over the greybox. This meant that the jump heights and distance for each object was already set, allowing the artists to model directly over the greybox knowing that the player could make each jump.
After that, the terrain could be exported into engine. The environment assets were separate and could be altered. However, the terrain was a set piece. It can be modified in Maya if necessary.
Ultimately, Baroviet’s design is one that will consistently evolve as development continues. Once all mechanics are implemented, play testing will be a significant component to improving the design and polishing the game.
Keep an eye out for more updates!