Designing a game from inception involves a team coming together around the same vision. Whether it’s a large studio with hundreds of staff or a small indie operation with just a handful of individuals, iteration time is key. A game’s vision will usually morph and evolve as the team starts testing ideas to see what works and what doesn’t. The fate of these ideas are often at the mercy of the time it takes to implement each iteration, whether it’s a new gameplay feature, a change in level design, tweaks to the animation system, and so on. In this series, we’ll guide you through the entire production process of creating a working prototype for a side-scrolling platformer game. We’ll also cover all integration workflows for importing and testing 3D assets from Autodesk Maya LT into the game environment. The storyline for this game centers around our hero Sven, an intergalactic satellite repairman, who is endlessly trying to escape the evil Killamari and reach his spaceship. This game is built with the Unity game engine and is designed for mobile platforms, such as tablets and smart phones. What you see here represents the end goal of the first phase of this series. As we move further in this project, we’ll iterate on these foundations and add new features and enhancements to the game, such as refined shaders, additional characters, particle effects, polished art, user interface elements, and much more. Let’s start by discussing the early concept design and artistic vision for this game, as well as the gameplay features to be implemented in the next set of movies. The original vision was to create a spin-off adventure for Sven set in the same Hyperspace Madness universe as the 3rd person action adventure game. Using a side-scrolling perspective give us new ways to frame Sven and the world he inhabits. One key objective is to optimize the game for mobile platforms, which means being mindful of polygon count, texture resolution, and so on. Although most of the assets will be in 3D, the gameplay will be restricted to a 2D plane and viewed from a constant camera angle. This helps performance at runtime by allowing us greater control over what the player sees, as opposed to having to plan ahead for every possible type of camera rotation. Another concern we have is in regards to recreating an entire 3D world in the background. This level of detail probably would not pay off for the additional computation it would require. Instead, we’ll use multiple 2D plates as foreground and background layers to convey the illusion of depth in the world. We’ll still use 3D buildings and accessories in the midground layer to fill the gaps in between. The platform sections in the gameplay layer are designed to easily mix & match. This modular design allows us to create various combinations and scale our level at will, whether we do it by hand or by script. This modular design will also be applied to the platform section extensions, which are part of the mid-ground layer. The purpose of these extensions is not to affect the gameplay layer, but to bring life and depth to the scene. Think of them as mini-stages where non-playable characters can walk by or interact in the background while Sven is busy making his escape. As for Sven, his movements consist of traveling forward in the level automatically, and flying up and down based on the user’s touch input in order to avoid obstacles and enemies in his way. If Sven touches a barrier or an angry Killamari, the level automatically starts over. On the other hand, if he reaches the end, the level is won. Now you have a sense of the story and the initial design considerations that went into this game prototype. So stay with us and follow along as we progressively build and tweak gameplay features. In the next movie of this series, we’ll set up our Unity project and start assembling the platform sections.