We are a small team of 5 people working on BitUp at the moment (at least for now during pre-production) We are based in the city of Guadalajara, Mexico. We’ve known each other for a few years: we were classmates at the university and also worked at some of the first video game studios in the country together. Most of the team members studied animation and digital arts and others are system engineers, but all of us share a passion for game development. The studio was founded at the end of 2013 with the goal of creating BitUp, thanks to the invitation to be part of the now-closed PlayStation Latin America Incubation Program and with the objective to create our own ideas.
BitUp has been changing since the beginning when we conceptualized it the first time. You could say that is a living thing and has a soul on its own. It started as a game in which we wanted to make a homage to the different video game generations and the original idea was to have the game evolve through those graphics, starting as a text adventure and moving to a full 3d game.
As we started developing the idea, that was scraped and the narrative started to give form to the game and the world around it. Here is when we came up with the idea that gave the actual visual style to the game which was “How a character of the 16-bit era would see the world around him, inside the game”. Then we started building the art style from there, hence the “Pixelated 3D” direction. Someone even called it a “cubist impressionist art style”.
We’ve been in the project on and off for the past 5 years. As a company, we do a lot of work for other indie studios. Thanks to that we have saved enough, and with the help of some government funding too, we are now able to finally focus on our own project or at least to make the pre-production and a full demo (vertical slice) of it.
During this on/off time we made 2 prototypes. The first one was in Unity 4 which was running on a PSVITA, this was made to be pitched to publishers during Sony Dev Summit in Los Cabos, an event made for Latin America developers who were in the Incubation Program from Sony. We made this prototype in 3 weeks.
The second prototype was made with a small private investment, with the promise of full funding if the prototype did well. That one was made in UE4 and running on the PS4 Dev Kit. The prototype did really well, we made a devblog during the process of creation of that build and caught the eye of some publishers, but since it was a prototype, publishers didn’t want to get on board until we had at least 70% of the game already done. Adding to this, the private investor could not fulfill the promise of getting the funding for the entire game, so we had to again focus on clients’ projects.
The gameplay also evolved, it started as a 2D platformer focused in combat and then we moved to a metroidvania game style with a focus in exploration. This change was a pretty organic move during the planning and designing of the game.
Following the premise of “How a character of the 16-bit era would see the world around him, inside the game”, we started envisioning how the world would be composed, how it’d behave, how it was made.
In order to achieve the art style, all the world was custom-built for the UE4 prototype. Everything was composed of cubes, but since it’s not a voxelated game, everything was made by hand for best optimization possible. It ran “well” on the PS4 Dev Kit, but the amount of geometry rendered was too much. Now we are experimenting with Substance Designer in order to create a flexible customizable texture that gives us the same look like the geometry.
The new version of the game is being made in Unity. The main argument behind this is that the actual team has more experience in Unity and the newer versions can achieve really great visuals. We are using the Lightweight render pipeline which has proven to be really powerful and optimized.
The main goal of the art style is to create a world that feels alive. Even with our premise of a 16-bit game, we want to make it look like a living world that we cannot see through our screens, but the character inside it can.
All the levels were first done using ProBuilder, the modeling tool inside Unity. ProBuilder has really helped us to speed up the Level Design and testing process. We did a lot of tests in order to find the best pipeline to assemble all the game world. While someone works in the level design, another person can work with the set-dressing and lighting of the same area, and then those 2 parts are assembled together to be tested.
Though ProBuilder is a really good tool for early testing, despite what Unity says, it’s not production-ready and as soon as you start working in a more streamlined pipeline, everything crashes and breaks. Now, we are migrating everything to be used with the amazing asset of UModeler.
What we actually did was a “Map Editor”. Due to the complexity of the map, an editor was created in order to manipulate and assemble a map that players can use and understand perfectly. This editor is made inside Unity, so everything works together.
*The part below is explained by Manuel, the programmer in charge of doing this editor.
Manuel: The need for this map editor arose after an absurdly long discussion about the usability and design of the map. What should we show? How? How the player will interact with it? These were some of the questions during that discussion.
Once we had this basic description of the map pinned down, my job as a programmer started. To achieve the features that we wanted, it was going to be necessary to take all the information of the map, which is divided into areas, sections, and modules, and put it in a data structure that could be constantly updated and saved. The structure I settled on was an adjacency list where each entry is a node with connections. In this case, the node is a section which contains its respective module data inside an array (a module is the smallest piece which you can divide the map with). The question was how to construct this structure. The level was modeled freehand and the only rule to it was that it had to be divisible by a module’s lengths, so, beside that, anything was possible.
At first, I had the idea of creating an algorithm that could read the level’s mesh data and figure out its structure, logically dividing it into the “imaginary” modules that composed it, but I quickly discarded the thought. Then I realized that I could try to write the data structure myself. I wrote a small JSON file with a section and its modules, then created a simple script that could read the file to deserialize the data structure and it worked! I had what I needed to create a map, the representation of the actual level. Was the job done? Not yet.
The problem was that it wasn’t a single section that had to be written, but dozens and dozens, each of them with their module data and connections to other sections. Doing it all by hand would be an interminable task and good luck with updating the file when the changes to the level would inevitably come. What’s more, the final file could not be in JSON format or any other format that is readable to the naked eye because of security concerns. What to do then? Here’s where I introduce you to the map editor!
This is a node-based editor. Like I mentioned above, each node represents a section and its information. Sections can be interconnected. With the dimension field of the node, you define a grid of modules, and in the module inspector, you can quickly “paint” the modules that compose the section.
I had prior experience with node editors in Unity but I always used the old IMGUI API. This editor was developed using Unity’s newest API for drawing and extending the editor, UIElements, publicly introduced in version 2019.1. This new API completely changes the paradigm of drawing in the editor. IMGUI uses an immediate draw mode, where the code you draw with is, basically, inside a loop that executes every frame. UIElements, on the other hand, is more similar to a web page since you can define a hierarchy of objects (a DOM) and then the engine draws them for you.
Once this editor was completed, creating the map file was a piece of cake. Adding nodes, filling them with the necessary information, a couple of clicks to export the file and done. We have a game map.
The game world is pretty big, with above 80 different sections This vertical slice part sums up to around 7% of the whole game world.
You might have also noticed the multi-layered structure of our levels – this is one of the things that we want to show with a gameplay trailer. It’s a unique feature of the game that we are still working on and want it to be in the best shape before showing it. Stay tuned for more soon!
The first assets were made traditionally by “hand” and now we are doing tests in Houdini because we can achieve more interesting results faster with the procedural pipeline. At the moment, we are doing the production design of the assets, so most of the ones being used right now are the placeholders.
Modularity is in the core of the game, so all of the assets (and some characters) are being made with respect to that. This way, we can assemble a lot of variations using the same parts and combining them with the GPU instancing function of Unity, we can boost the performance of the game.
We are defining the VFX part right now, but in order to keep everything under the same art style, the visual effects maintain the same “pixelated” look. This can be seen in our VFX exploration sheets.
The particle system of Unity has proven to be really flexible for the creation of the FX. Since the design is so simple, we can create a lot of effects in a short amount of time.
We are landing the narrative, characters, environments, and level design and are about to close the pre-production stage of the game. After this, we plan a year of production. We will be doing more devblog about the new stuff that we create and once we finish pre-production (which includes a vertical slice of the game) we will release a gameplay video showing what BitUp goes about.
Also, if you need more press information, go to www.bitupgame.com.
Interview conducted by Kirill Tokarev