We’ve come to the point where InnerSpace is starting to look like something, so naturally it’s time for a little retrospective discussion of our somewhat formative production-level steps in engine.
Winding back to January, we had just come to grips with the success of our Kickstarter. Great! We had our proof-of-concept demo, some great art, and a pile of money. We also had a pile of challenges:
- Limited development time
- The puzzle of level design (more on this in a bit)
- Limited resources
For the Kickstarter demo, we were able to custom-concept and model the large stone towers that formed the gameplay environment. For the larger, detailed worlds of the actual game, this solution didn’t seem workable. Because the game world needs to function in interesting and curious ways, we needed to find a world-construction method that enabled, rather than delayed, our level designer. In this regard, our aesthetic started to feel like an obstacle: how could we manage to build these mysterious monuments efficiently without going through an extensive concepting process for each one? We needed a way to build the towers as levels while sticking to our aesthetic and remaining flexible, should any kind of change need to be made.
The solution was the modular system expounded upon by Jeff in a previous blog post. From a functional perspective, these pieces allow him to bring his level designs from proof-of-concept to production mode with relative ease, without requiring a lengthy art process between conception and integration into the game scene. Because each tower or scenario is a piece in the larger “level” of the hub world, this ease of integration allows us to evaluate the game as a whole, as we construct its pieces. Though we don’t dwell continuously on every detail, overall this methodology gives us an iterative process well fit to the semi-experimental nature of our current development stages.
Artistically, these pieces capitalize upon early effort, encoding our aesthetic into the foundations of the game’s levels with a minimum of continuous artistic attention. While some visual sensibilities certainly help keep each tower-of-blocks looking cohesive and interesting, giving the level designer an aesthetically-vetted set of tools in the early stages allows the artists to focus instead on parallel tasks like structural details, flora, fauna, mechanisms, and the other Bubbles. This way, we optimize our efforts to develop several areas of the game at once.
It’s also fun, and allows for experimentation. Though the set of pieces was made with some sense of possible designs, it’s so far been used to create new and unexpected permutations when brought into the game world. Though these are checked against the original design ideas, these manifestations push and expand our expectations for what structures might be possible in both the world and the styling of InnerSpace.
Of course, that’s where we landed. Initially, the path to a flexible, interesting, and useful system wasn’t so clear. We knew it had to translate our aesthetic and free some of everybody’s time. But, in trying to accommodate every expected need, it’s easy to overshoot.
For the first iteration of our modular pieces, I wanted to give the team ultimate flexibility in-engine while retaining the general shape dynamics hinted at in early concept art.
Naturally, I looked at the towers in the concept art, isolated common shapes, then broke those down further into their primary elements.
These could, potentially, be formed into towers, but not in any reliable, replicable way. These supported a granular, highly-detailed construction system, but proved close to useless for level design. They weren’t suggestive, so they still required specific concept work for each tower to actually be made into structures.
Next, I tried to re-pre-assemble the common shapes I had outlined in the art, hoping that these would easily form walls, bridges, or other structural features. This solved some issues, but lacked standardization and thus didn’t really qualify as a system. Using these pieces effectively still required some idea of a specific tower, whereas the aim was for a more impressionistic, foolproof tool.
Stepping back, again, to the original concepts, we decided to expand- rather than break down- the shapes, and to do so in an organized, consistent manner. We emerged with a “frame-shell” system, in which stone chunks (shells) are fit, more or less, into the silhouette of a metal frame (…frames). Frames of various shapes all have faces intended to connect, and these all fit a standard size. The shells, meanwhile, can be used either as solid chunks, or can be hollowed-out to create interesting, connected interiors.
For each frame, we designed several shells, allowing us to give variety to towers of the same general shape or to use similar shapes in different ways, depending on context.After the initial forms were created, each shell received additional surface detail. This breaks up the flat, untextured surface, providing visual detail from afar as well as up close.
This is, in the end, only a solution to medium-scale world design in InnerSpace. Though we can use the modular blocks to create suggestive forms and hint at the function of structures, these broad forms don’t communicate anything specific. This is due, in part, to the aesthetic, but it also relates to the fact that these larger forms read much differently up close than from afar. As a result, the frame-shell modules are a useful system for bringing level designs into our game scene while laying the foundations for our world-based narrative. To turn the functional space into a storytelling tool still requires specific attention and, eventually, unique assets and staging of scenarios.
For a small indie studio crafting an open-world game without procedural generation, modular level design tools have proven a valuable resource, especially when it comes to bringing image and mechanism together with a minimum of debate. It’s worth keeping in mind the potential roadblocks presented by designing a system around several requirements, some of which are unknown. It’s easy to get bogged down in specifics, get too granular, or perhaps not granular enough. The system must hit on a balance of functional flexibility and aesthetic expression.
Inherently, a modular system loses some degree of specificity, and the artist has to give up ego and agency to whoever gets their hands on the modules. Yet, once they’re set in the game scene, the modules become concrete expressions of ideas that had only been floating in concept art. In exchange, then, these tools allow a world, and an architecture, to take shape of its own accord.
A little (just a *tiny* bit) of this flew over my head, but it makes sense :) Its quite nice to get updates (however long between them) that are a length. Feels nice to read something thats more than a simple paragraph.
I'm glad you enjoy reading them. Hopefully, they provide some insight into how we view games and design, in general.