Smol World

Smol World started out as a smaller scale Unity project, around Summer 2024, heavily influenced by the likes of A Short Hike: small open world, reduced scope, retro-inspired rendering. The idea seemed fun, interesting and manageable (A Short Hike had a short development period and was made by a single person afaik).

I started by getting a basic character controller + model and terrain in place, to get a better feel for what I was aiming towards. I quickly felt that I needed to settle on a bigger terrain early on so I could progressively refine the terrain settings to go along with the rendering.

The retro-like rendering was achieved by using a render texture and outputting it as a low resolution UI element over the whole screen.

Texture quality needed to be relatively low to suggest an older looking game, to go along with this kind of rendering technique.

Another key element I wanted to use for this project was the world-bending effect: make a flat terrain appear to be a sphere.

Both these aspects had to work properly in conjunction with terrain settings, more specifically terrain resolution.

The world-bending effect was achieved using a custom shader, made in Shader Graph, and works as follows: it is a vertex displacement shader, that makes it so that the further away from the camera, along any horizontal axis, a mesh's vertices are, the lower they'll visually appear along the vertical axis, meaning when the camera backs away from a vertex, that particular vertex will look like its going down behind the horizon. Conversely, when the camera gets closer to a vertex, it will look like it's coming up from behind the horizon. In effect, the terrain appears to be sphere shaped, just like a planet.

For the vertex displacement shader to work properly and for the terrain mesh to keep graphical consistency, the terrain resolution needs to be high enough (meaning it needs to be made of more triangles), so the bigger the terrain and the higher the terrain resolution, the bigger the needed resources, which sounds a bit counter-intuitive for a retro-looking project.

To better appreciate the terrain and its curvature, an airship controller was quickly developed and put in place, to be able to explore more easily. That's when the project took a bit more inspiration from 90's looking J-RPGs.

The terrain was reworked as a basic overworld-like scene, complete with a world map capable of tracking Player character and Airship precisely.

In 90's J-RPGs, it is expected that reaching the edge of the map makes the Player appear at the other end of the map (so that North & South edges, as well as East and West, are effectively connected). This makes the scene feel like it's an actual sphere. That's how it feels like, but the actual behaviour is that of a donut-shaped world, rather than a sphere shaped one. In this case, how things feel matters more than how they actually work.

From a technical standpoint, achieving a donut-shaped world seems simple enough: upon reaching the edge of the terrain, the Player is automatically warped to the opposite edge. To help sell the illusion, a couple tricks have to be put in place. From any edge of the terrain, the opposite edge has to be visible, so that the terrain bounds are not visible (since a sphere has no actual edge). This means that copies of the terrain have to be placed at each edge of the main terrain: North, South, East and West edges, which makes 4 copies. 4 additional copies then need to be placed at each corner of the terrain, for when the Player reaches said corner and the opposite corner needs to be visible (when the Player is in the North-East corner of the main terrain, the North copy, East copy but also the North-East copy need to be visible beyond the main terrain's edge). In total, 9 terrains are needed to sell the illusion of a sphere (4 edge copies, 4 corner copies and 1 main terrain). To help with optimisation, copies don't need to include the full terrain, but it is important that the player doesn't see where these copies start or end, as the terrain needs to appear to be seamless.

Another important aspect is the terrain material: it needs to appear seamless between main and copy, so that the Player can't see where main and copy touch. Texture and/or material have to be set-up accordingly. Same principle applied to the shader and material used to make the cloud layer: it had to appear to be seamless on its edges.

As the airship uses a variety of particle effects when interacting with the environment (oceans, cloud layer), and some of these effects using a World simulation space, these effects had to take the Player warp into account, so that particles don't seem to be disappearing when the Player warps.

But the most important technical aspect, and also the one I struggled with the most, was the camera. It has to follow the Player perfectly when the threshold from one edge of the map to the other is crossed, and with the Player instantly warping to the other side of the map, it wasn't as easy as it first appeared. The function OnTargetObjectWarped had to be used on a dedicated script (tells the camera its target was warped), but even then slight imperfections persisted that ruined the effect, sometimes by just a couple frames where it was still clearly visible that the camera was trying to catch-up on its target's location and/or rotation. Adjustments had to be made to the Cinemachine brain's settings (Update method and Blending Update method) so that the effect would be as seamless as possible. After a lot of testing and trial & error, the effect was achieved and perfected and the terrain appeared to behave like a sphere-shaped planet.

Regarding the terrain, its sheer scale called for a triplanar mapping shader (used with 2 terrain textures) to be easier to work on. It wouldn't have been very practical or productive to have to repaint the textures on the terrain everytime the terrain was modified. But the way triplanar mapping works was in conflict with the world bending part of the terrain shader. In Shader Graph, vertex position is defined only after vertex displacement takes place. Triplanar mapping using vertex position, that meant that the vertex displacement used for the world bending was messing things up for the triplanar mapping. In practice, this meant that since vertices appeared to be moving up and down as the camera moved closer or further away from an element of the terrain, the vertex coordinates appeared to change, which in turn gave the wrong coordinates to the triplanar mapping: the terrain textures seemed to be moving up and down as the camera moved. Particularly jarring unwanted behaviour.

As I was still discovering how shaders and Shader Graph work through the use of tutorials, it took me quite a while and a lot of trial and error to find the solution to the problem. In the end, I had to reverse the world bending part of the shader node by node to only then feed it into the triplanar mapping part.

With all these elements in place, I still needed to keep the texture painting function of the Unity terrain tools working, so the terrain shader had to be adjusted further to accomodate for the splatmap. In the end, the shader looks at the splatmap and displays the element with the highest value on top, be it the terrain texture or one that was painted over it.

Then, the project moved further away from its smaller scope inspirations and closer to its 90's J-RPGs ones, which as a whole wasn't for the best.

As the map started to feel more like an RPG map, and with the inclusion of an airship, additional, "lower rank" vehicles seemed like a logical inclusion, so I decided to include some land based ones, starting with a bike.

After improving my Blender modelling skills with my previous project, I felt confident enough to model an original bike. This allowed me to design and animate it however I saw fit, in a way that would fit the project's intended aesthetics. This one was inspired by what I'd seen in works like Gunnm and Final Fantasy VII, putting my own spin to it.
Working with multiple controllers was definitely an interesting challeng and I was able to let the Player swap between character controller, bike controller and airship controller.

As most of the gameplay would be taking place on this terrain, it felt necessary to have the vehicles be fun to use and pleasing to look at. I wanted this futuristic monobike to have cool looking animations, depending on the Player's actions. The bike folds and unfolds when the Player mounts/unmounts. The arm and its hinges are angled in a way that is dependant on the throttle input via the controller analog input. It feels reactive and satisfying.



I ended up giving the bike, and the character that's riding it, multiple animations for accelerating, going in reverse, turning and taking sharp turns... all dependant on speed, with corresponding particle effects.


After the bike, I decided to iterate on the ship and give it a better design, some animations and better effects, making it a more enjoyable experience for the Player.


That's when the project took one too many steps towards its J-RPG inspirations. With such a big world map, and with the use of multiple vehicles, I decided to include towns. At this point, the project was going to be an adventure game with a 90's J-RPG presentation: classic adventure game gameplay within the towns and other world map points of interest (inspired by Syberia, Broken Sword, Monkey Island etc...), J-RPG presentation and travel on the world map, complete with mini-games.

I had to decide between 2 directions to take regarding the towns: fully embrace the 90's aesthetic and use pre-rendered backgrounds, or make things slightly easier for myself and use low-poly 3D environments with a camera that would mimic camera movement that usually accompanies pre-rendered backgrounds. As I'd already been researching and using pre-rendered backgrounds for a previous project, that's what I settled on. I then moved onto Blender to try and make a prototype scene for a small town, learning how to best mimic a 90's CGI aesthetic.



To achieve this result, I used pre-made models and materials. The materials and rendering settings were tweaked according to dedicated tutorials to give them an older CGI look. The scene never reached a perfectly satisfying state, though it was on its way. The issue was that getting there took a ridiculous amount of time for a project that was supposed to be small scale, even though I used pre-made assets. I'm not experienced enough with Blender, I'm definitely not a modelling expert, and it is a LOT of work regardless. In-game, the view would have been closer/zoomed-in, with the camera following the character around.
Implementing pre-rendered backgrounds in Unity sure is a process, but this wasn't the issue here. As I said, I've used pre-rendered backgrounds on a previous project so I already know the workflow. The real problem was the amount of complex 3D modelling work this project was starting to call for.

That's when I realised what this project had become: far too ambitious for its own good, too directionless. Setting it aside was the best call for me at this point.

I learned valuable lessons working on this one. I learned what the limits of my modelling skills were. Even though I used a lot of tutorials, and a lot of trial and error, I learned a bit about shaders and Shader Graph. Using multiple controllers was an interesting experience. Some of these elements were to heavily influence, and be used on, the following project. But mostly, I realised that scoping and game-design are areas where I still have much to learn.

Hope to get back to this one, when the right conditions are met... someday.