Overview
Embedded Files
- My Role(s) 3D Generalist
- My Role(s) 3D Generalist
- Genre Sokoban Puzzle Game
- Engine Unreal Engine 5
- Platform PC
- Team Size 4
- Duration of Project 8 Months
I've been a part of Worker #84 since its concept. I was the only 3D artist so I mainly worked as a 3D generalist, working on all the 3D aspects of the game.
For our 3rd year projects, we aimed at a product starting from the Market, starting from strong references and following creating some interesting tweaks that could make the game stand out. We also had the focus on making something that could be highly polished.
The Game results in a mix between Helltaker, where he gets the system of limited moves, and Soko base mechanics from, the idea of varied and variable mechanics of Portal and Inhabit for the structure of the narrative.
Prototype
Before The Prototype
Before The Prototype
Initially, in the prototype, we encountered some challenges when it came to creating the game itself. Since we were few in number and with only me handling the 3D aspect, we tried to optimize the game's creation from the very beginning by identifying the potential issues we might face during the process.
The initial challenges we focused on were:
-The camera
-Level creation tool
-Asset repetitiveness
Camera
The Camera was one of the hardest things to design and implement. We start the development with a solution in mind, having two cameras (like Unity), one for the player and one for the environment.
This is because we had a mix between a 3D environment and a 2D character, so the character was perfect on an Orthografic camera and the environment on a Prospective one.
This solution was optimal, but unfortunately Unreal doesn't permit this type of action, so we deleted everything and start rebuilding it from scratch. After varius research, I found a solution that will provide similar effects. This solution utilizes a "bug" in the Unreal camera.
Starting from the Perspective camera, we create a "Fake Orthografic" camera utilizing a really large FoV and a high Aspect Ratio.
Level Creation Tool
To create levels quickly and make them easily customizable and implementable, our programmer started developing a specific tool from the early stages of the prototype creation. This tool was designed to enable me to recreate levels rapidly, following the patterns set by our designer, to speed up the process.
Asset repetitiveness
To avoid asset repetitiveness, I made an effort from the beginning to create optimized models and textures. This approach allowed for easier modifications and a wide variety of assets within the game, without compromising performance.
Optimization
Given our goal of creating a game that's as optimized and lightweight as possible, as mentioned earlier, I started creating atlases and materials from the very beginning that could be used effectively while also being highly optimized.
Spreadsheet
Spreadsheet
With these textures, I utilized the option to combine multiple textures into a single image to diversify the terrain and its damages for each tile randomly within the levels. This was done to ensure that the terrain did not appear repetitive.
Atlas
Atlas
The atlas that I chose to keep slightly less "compressed" was the one for mechanics props, considering the continuous reuse that would be required later in development for mechanics.
Materials
For the material, I aimed to optimize by creating a single material that would result in fewer calls and could be used from the beginning to the end to lighten and smoothen-level transitions.
Page updated
Google Sites
Report abuse