Projects

Implemented Features

• Camera system

  • Reversed-Z infinite projection matrix (good for depth precision)

  • Perspective and Orthographic project.

• Ponctual Lights

• Forward renderer with PBR materials

  • ORM Textures.

  • Ambient Occlusion.

  • Metallic Map.

  • Normal Map.

• Tone-Mapping

• Skydome

• Pre-recording of commands

  • As an early optimization to avoid being CPU-bound. This would rarely be the case if using Draw Indirect/Batches, but it makes sense from the hardware perspective and doesn't hurt the API.

• Multithreaded texture loading

• glTF/glb models with the gltf2 parser

  • Really similar to RayLib's implementation, but with early support for multi-windows

• Tangent generation for models missing tangents

  • I settled for an implementation based on https://terathon.com/blog/tangent-space.html, by Eric Lengyel. The MikkTSpace's tangent generation is probably a better algorithm, but the current Odin binding for it was quite a mess, so I opted for something a little bit more sane.

• Multi-window system

• Wrapper around image transitions and pipeline barriers, to improve synchronization consistency and API usability.

• Descriptor Indexing / Bindless

• Entity Component System (ECS)

  • Excelent CPU performance on entity processing and cache friendlyness, but also giving a huge flexbility for entity creation.

• Multi-Sampling Anti-Aliasing (MSAA)

• Mipmapping

• Custom Vulkan Allocator and custom CPU Allocators, for general tracking of memory usage/peaks with Tracy

• GLFW input system.

• Easy-to-use graphics pipeline creation via shader reflection with spirv-cross.

  • Personally, I think this is really handy to have. The API would just be really annoying to deal with without this. I'm happy I went with it.

• Depth Prepass

  • As a way to prepare for a Clustered Forward Shading technique.

• HDR composite pass

  • The user is to be able to chain composite passes one after the other in a trivial way.

• Jolt Physics

  • Jolt is an awesome physics engine, used now by Godot.

  • I made the bindings for it here: caioraphael1/jolt-odin.

  • The engine makes a wrapper around the binding. Dealing with the wrapper should be *much* easier to deal then with raw jolt, but the main goal is re-writing Jolt in Odin.

• Custom Multiplayer library

  • Completely focused on server-side authority.

  • Custom RPC system with raw TCP packages

  • Supports authentication systems with a gateway and tokenizers, user databases and world databases.

  • I got good performance for a server-side prediction, reconciliation, interpolation/extrapolation, and a soft-rollback system. To make that work, I use it side by side with the fixed cycle system and some multithread + jobfication

  • Support for UDP packets and CPU drifting corrections will be implemented in the future.

• Custom Job system

• Cached transforms system

• Cycle and Fixed Cycle system

  • Crucial for multiplayer, and a way to manage input processing, draw times, etc. Used in conjunction with a sleep scheduler system to avoid using too much CPU time.

• Tween System

  • For animations and general interpolation.

• Event System

• Extensive support for Tracy and Spall profiler.

• 3D level editor using a parser for Blender

  • This is excelent for artists, as they don't have to leave their modeling tool for creating maps and logic

• UI

  • UI Text Box / UI Input Text Box

  • Buttons

  • 2D Editor for UI placement

Future plans

• Clustered Forward Shading

  • I plan to have lots of lights for great creative expression, and Clustered Forward Shading sounds the best options for performance and flexibility when comparing to modern techiques. I also considered Deferred Shading, but I decided for something that doesn't weight so much on the bandwidth.

  • Perspective and Orthographic project.

• Radiance Cascades

  • An excellent technique for Global Illumination used in Path of Exile 2. I plan to implement this techique on a 2D game first and then translate it to a 3D game to see how it behaves.

• VBAO/SSILVB.

• Directional Lights, Spot Lights, Area Lights (without soft shadows for now).

• Clustered Forward Shading

  • I plan to have lots of lights for great creative expression, and Clustered Forward Shading sounds the best options for performance and flexibility when comparing to modern techiques. I also considered Deferred Shading, but I decided for something that doesn't weight so much on the bandwidth.

• HDRI Skies with .exr files

• Emission / Bloom shader

  • I love the effect to create neon lights

• Frustum Culling on GPU other 'Approach Zero Driver Overhead' techniques

  • I want to explore more with GPU Compute and extract the maximum of GPU parallelization

• Investigate a bit more into Buffer Device Address techniques.

• Custom Font Rendering.

• New UI layer with Clay

• Remove GLFW and replace it with a new OS layer.

• Shadows.

• Fog.

• Volumetric Fog.

• Particle System

• Mesh Skinning.

• Support for VR with Variable Refresh Rate techniques (VRS).

• Mobile support.

Multiplayer - Netcode

• Multiplayer was the foundation for everything in this game, being the first thing to be implemented and always something to come back to. I wanted to make sure to treat netcode as a priority and have the multiplayer scale well with time.

• For this engine I went with JoltPhysics, which gives excellent physics simulation; for that I made this jolt-odin binding, bringing Jolt to the Odin programming language.

  • It's worth noticing that Jolt is a 3D physics engine, but this game is 2D, so changes had to be made so the simulation runs correctly and objects don't slip into a unseen dimension.

  • I opted for Jolt instead of something more usual, such as Box2D, as I was pretty sure I would use this binding later for a 3D game, and wanted to streamline the physics process. If necessary, I would later simplify the physics engine by making a full rewrite in Odin.

• Even though this engine had a pretty robust physics engine, that wouldn't matter if the client felt laggy or if the client and server couldn't agree on the current physics state, leaving the client to be rolledback constantly. This was one of the first big challenges I had with netcode. To fix this issue, I decided to completely separate the updates inside the server and client via well-defined "cycles" and "fixed cycles", in a way that a single clock-sync when the client logs in would be enough to keep latency to a minimum. This, of course, only works in a vacuum, as CPU drift can occur and latency is not constant in time. For that reason, a series of measurements is taken at a fixed rate to identify delta spikes in latency, so the client can process faster or slower to properly have the physics update synchronized. The result is shown in the graph above: a much smaller delta ratio comparing gray entries (old) vs colorful entries (new), indicating a big improvement in synchronization. Not all was solved, as there was still a "minimum ms delta" due to restrictions around the server update frequency, as well as problems of "over-compensation" if the client has a delta-ms too large due to high RTT, but I believe that both could be solved with improved temporal metrics.

• Beyond the solutions I talked about, I worked on creating my own encoding/decoding through a specialized serialization system, using CBOR for something more complex, such as the custom RPC system I created, or using something as compact as a single byte to identify instructions. This could also be improved even further by better utilization of UDP packets for non-crucial tasks, as well as better utilization of the TCP payload when considering the size of the header.

• With that, the multiplayer was much better than before, while also requiring much less from the the server, as now not only the bandwidth is improved, but the server can process a lot slower as the client has now the tools to compensate for the increased latency without losing input/action precision.

Multiplayer - Login

• .

Visuals

• For the visuals, I decided to completely avoid an internal level editor. I'm of the belief that external editors are much better choices when it comes to customization and artistic choice. For the external editor in question, instead of creating something of my own, I decided to go for LDtk, from one of the creators of Dead Cells. For that, I made a custom parser that would translate the .ldtk files into custom logic inside the engine. Unfortunately, I had a very bad experience working with LDtk, which led me to edit its source code constantly in order to solve a lot of the bugs and missing features it was lacking; coding in Haxe/OOP/JS was not fun.

Rendering

• For rendering, I decided to keep using RayLib for this game, as it has a very easy-to-use API that allowed me to focus on other parts of the engine. Though, when it comes to customization, I felt quite stuck without being able to evolve past what OpenGL gives me and what RayLib exposes.

Procedural Animation

• A library was created for handling all 2D procedural animations, using Inverse Kinematics with the FABRIK algorithm as the solver. As shown in the videos, it's possible to represent "grab motions" and "fish-like" motions. I was also implementing constraints so a new variety of motions could be represented, such as arachnoids, drones, lizards, snakes, etc. As the game is 2D top-down, there's a limited amount of motion it can represent, but for 2D platformer the options change, being more resonable to represent mammals. My goal was to create a library with concepts easy enough to understand so it could later be implemented for a 3D game.

Key Takeaways

• I was really proud of what I've accomplished with the Multiplayer, but after not being quite satisfied with Raylib and LDtk I decided to try something different and learn Vulkan in 3D, so I could finally answer my questions about the world of rendering, and in the mean time I could think of a better solution to improve the workflow of 2D or 3D tools to keep making games with less friction.

Fly like in creative Minecraft

• From 'WASD Control plugin': Use WASD to move around, E to go up, Q to go down (keybinds are configurable).

• Use Shift to fly faster or Alt to fly slower (keybinds are configurable).

• You can change the sensitivity of the camera, speed of flight, speed modifier for "go faster (shift)" and "go slower (alt)".

Painting the world

• Select a "brush" (Cube).

• Press T or click the icon to toggle the tool.

• Start painting by clicking with the Right Mouse Button on other cubes.

• Use Left Click to remove blocks, or Ctrl + Z to undo.

• If you want to select a different brush, or customize the current one, just press T again to deactivate the tool and select a different brush (Cube).

• Differently from Minecraft there's no limit distance to place blocks, so you can remove or place a block from really far away.

Known issues

• The plugin may act weirdly when placing blocks with rotations or scales that differ from each other.

• The Outliner can flicker up and down when placing lots of blocks. Selecting something in the outliner usually fixes that.

• The performance can be a little weird when placing thousands of blocks in the same scene. However, that fixes itself when restarting the app, it's inconsistent what triggers the frame drops in this case.

Limitations

• It's not supported to place a cube in a Mesh or in the "void".

• While placing a tiny block in a huge block, that placement can be weird and offset to some corner. That's tough to fix, so there's no planning for that.

• It's not possible to Ctrl + S to save the project while the tool is active. That's due to the WASD movement for the navigation.

• It's not possible to position multiple blocks at the same time.

Future ideas

• The plugin no longer implements a simple tool, but a new "edit mode" called 'Creative', placed next to Edit / Paint / Animate. This new tab will not show any Gizmo or selection; it will only be for 'placing and removing cubes'.

• This new tab would have its own group system to help group the new cubes created; I've been using the plugin for creating a level design for my game, and I got 1000+ cubes in the scene, so it's important to have some group organization.

• A new interface in this new tab, that would take the UV place, displaying the current selected cube (aka. the current Sample Cube used for painting the world).

• A system that lets the user place cubes in an empty grid. The current state only lets the user place a cube next to another cube, so that can be a bit annoying at times.

• Add middle click to pick blocks like in Minecraft (Suggested by Jannis).