- GDScript 100%
| addons | Implemented viewport debug draw (render mode) driven by a CVar in map.gd | |
| docs | Update docs/cvars.adoc | |
| .gitattributes | adding pre-merge framework | |
| .gitignore | feature_mapping ( #18 ) | |
| CONTRIBUTING.adoc | Add and update documentation ( #17 ) | |
| default_env.tres | adding pre-merge framework | |
| export_presets.cfg | Merge from feature_movement_park + some fixes on top | |
| game_profile.json | feature_mapping ( #18 ) | |
| icon.svg | adding pre-merge framework | |
| icon.svg.import | adding pre-merge framework | |
| LICENSE | Initial commit | |
| project.godot | Merge from feature_movement_park + some fixes on top | |
| README.adoc | Update README.adoc | |
HEAVY DEVELOPMENT - software under construction - expect the unexpected! The following document describes the vision for Liblast Framework, but many features are not yet implemented and/or integrated yet. Most of the technology has been prototyped and at least partially proven, but at the time of reading expect breakage.
Liblast Framework
Liblast Framework is a Godot add-on that provides core systems and components used in the open-source multiplayer first-person shooter game Liblast. The (Liblast) Framework is meant to hold all the reusable technology that Liblast (the game) needs to function, but in the long run to provide a great starting point for other FPS games, single- or multiplayer. Possibly non-FPS games might also be feasible with some more work on the game developer’s side. A lot of the core features of the Framework are completley genre-agnostic.
Key goals and features
-
High Level FPS-focused tooling - FPS games are complicated. Godot has all the basic tools, but there’s a lot that’s missing. We aim to provide an integrated set of high level tools that elevate Godot from a DIY general-purpose engine to a specialized FPS-focused engine. Liblast (the game) is going to be a full-blown demonstration of the Framework, and hopefully a starting point for many aspiring game developers, modders and players!
-
Networking comes first - your game is either designed to play well over the Internet or you will suffer trying to bolt multipler on. Liblast Framework strives to make networking a natural extension of everything you build with it. You want your game to work online now? Sure. As long as you have been sticking to the Framework’s way - it’ll just work.
-
Brilliant 3D asset workflow and pipeline - the chase of highest fidelity is the bane of modern gaming industry. File sizes, loading times, disk speed & memory requirements, artist workloads and asset budgets are out of control. This not only stretches production time and cost, but also alienates budget gamers. Not to mention that one failed game is usually enough to collapse a long-standing studio. A common reaction in the indie space is to go back to the hardcore retro aesthetic. Embrace ultra-low poly counts, nearest-neighbour texture filtering, vertex-lighting and wobble etc. We believe there is a sweetspot that’s being overlooked here. Our custom workflow and technology enables great balance between quality and production cost while maintaing low file size and memory footprint and providing high variety and asset reusability. The 3D pipeline frontloads asset creating with building reusable textures that can the can smartly applied to lowpoly models to achieve mid/high-poly look very quickly. Authoring custom assets becomes fast and fun. levels can be filled with custom props, because (1) making them is easy and they "automatically" look really good and (2) models are low-poly and almost never use custom textures, so rendering them is quite fast, while giving character and detail to simple models.
-
Break out from the golden cage - proprietary technology is still industry-standard in the gaming space. We want to prove that free (as in freedom) and open-source software ecosystem is a viable alternative to vendor lock-in and can be a solution to the shifting sands of corporate-owned engines, platforms and tools. As digital independence is slowly seen as more important, we want to demonstrate that black-box subscription-based foreign-controller software is not necessary to build awesome, good-looking, great-feeling games.
-
Facilitate player’s creativity - modding is something that makes our favourite games evergreen, because decades after release, there’s still novel stories to be told and fresh experiences to be created in the worlds we lived through. FPS games rarely ship with fully-fledged editors nowadays. Even when they do, the cost of creating assets that match the visuals is too high for hobbyists to match. Long-term goal is to facilitate user-created content and provide easy tools to make and distribute it in-game.
Subsystems
Core Services
The framework is made up of a Core and a set of Core Services that provide high-level interfaces for various game systems. These are like singletons, only we use dependency injection and explicitly spawn them in Core for more control.
CVars
A specialized database made to hold your game’s configuration. Liblast Framework features a hierarchical, layered configuration variable system. The system allows easily and dynamically applying layers of overrides - be it in form of mutators, mods, user configurations or total conversions. Long term CVars will allow for A/B testing and tweaking game balance live during an online session, because all game variables are accessible through the in-game console or GUI editor. As a game host you are allowed to change all the rules, save your overrides to a file and load the config changes later or make them into a mutator, mod or just a custom server config.
Entities Components and Attributes
Entities are objects that contribute to the variable world_state. Components add behaviours to entities they are attached to. Attributes are variable properties of Entities and Components that are comprising a State. For example static geometry or a non-interactive particle effect or light some are not entities, unless they are given a script that contains the EntityInterface and define variable Attributes.
To make a particle effect or light interactable, it needs to have a script that has @export var entity_interface: EntityInterface and initiates it’s EntityState defining attributes. Game also tracks all possible Entity types, and their scenes so that it can spawn any entity that the world_state describes.
Entities
-
Actor - an autonomous entity that can act on it’s own volition. Extends Entity with actuators and sensors to provide a unified way of controlling antonomous entities/
-
Biped - extends Actor to add the notion of head, feet, hands, an inventory, weapon slots (left and right hand), special collision areas (feet), head etc.
-
Interactable - extends Area3D and lets Actors control Devices, Vehicles or other entities
-
Projectile - transient object that facilitates Affector Components. Projectiles may or may not be handled in batches by a Projectile System (ECS-style)
-
Effect - audiovisual decorative object that doesn’t directly affect gameplay, could be a light, particle effect or sound
-
Zone - extends Area3D and facilitates things like triggers and affectors
-
Vehicle - extends Actor, can feature BipedSlots where Bipeds can sit or stand to control the vehicle, mounted weapons or just be a passenger
-
Spawner - entity that can create other entities - for example boxes on a factory line
-
Deleter - entity that can delete other entities - for example boxes on a factory line (when they go out of the level, so they don’t)
-
Teleporter - entity that can instantenously transport other entites - for example boxes on a factory line can go back to the start after finishing their route
-
Transporter - entity that can apply movement to other entities - like a fctory line moving entties that are on top of it
-
Weapon - can be carried and used by Characters to deal hitscan or meele damage and spawn projectiles
-
Item - can be picked up and stored in a Characetrs’s inventory (ammunition, health packs, etc.)
Components
-
Mover - defines a simple A-B linear motion - used for doors, lifts, buttons, levers, crushers and moving decoration, usually comes with a Zone and a Trigger
-
Trigger - detects Actor presence using a Zone and sends signals to specified entities to make them react (for example Movers)
-
Affector - alters Entity Attributes - applies damage, healing etc.
-
BipedSlot - allows a single Biped to take a "seat" or "stand" in a vehicle, stationary weapon or other devices
Attributes
-
Integrity - basic attribute of all Actors, it’s hit points. When integrity reaches zero, the Actor dies.
Virtual Devices (experimental)
A set of scripts that can be attached to any Node3D, allowing for the creation of interactive objects in the game world.
-
Device (Base Class): The base class for all virtual devices, providing shared functionality and interfaces.
-
Radio: A communication system for chat and messaging, which can be used by players or as components for game modes and missions. Radio channels are custom resources RadioChannel class for managing communication.
-
Display: Devices that render 2D viewports within the 3D world, capable of showing interactive buttons, touchscreens, or other visual elements.
-
Application: Interface devices that provide specific functions within the game world, such as a speedometer for a vehicle.
-
Computer: A central system that connects multiple devices and displays, allowing them to communicate and function together. Computers can use applications to interact with connected devices, enabling interactions like opening doors, activating lasers, or controlling elevators.
3D Asset Workflow
Liblast Framework proposes a 3D asset workflow and pipeline that aims to achieve relatively high visual fidelity and variety while maintaining low memory and labor requirements. This is achieved through a clever use of specially prepared assets, textures, materials and an ubershader that binds it all together.
Our workflow allows artists to have relatively simple models punch way above their weight. Lowpoly models can seem closer to midpoly ones, and midpoly ones approaching the quality of dedicated baked highpoly→lowpoly assets, while using tileable textures that can be recombined in many different ways, and universally re-used hardsurface atlas that allows creating beveled and weathered edges on a blocky model with a single click.
The tools used to get there are:
-
unified material library to prevent material and texture duplication - our scene post-import script finds all materials used in your level or prop GLTF file, and replaces them with a material with matching name from the project’s material library. This means you no longer need to manually remap materials for every GLTF file you create, and don’t have to worry about assets in the game appearing with wrong placeholder materials. The import script will use a special error material that will make it
-
hotspot UV mapping using hybrid atlasess/trimsheets (using DreamUV add-on for Blender)
-
channel-packed baked vertex colors (baked using a custom NodeGroup: High-Radius AO, Low-Radius AO and Curvature)
-
multi-channel UVs and UDIMs used to select material variations per faces and layer paint on top of base materials. PaintOverlay atlas allows adding markings to models that behave like paint which wears off with scratches using curvature and AO information from both vertex colors as the hotspot atlas
-
per-instance uniforms (shader properties) and scripting to allow props to use shader LOD, align dirt and wear parameters to environment zones automatically as well as provide randomized appearance to break repetition and make most out of the assets you build.
As the ubershader is used to render majority of the game’s frames, this allows to provide convenient shader complexity and performance tuning including shader LODs (we want Parallax Occlusion Mapping up-close but there’s no point processing it on a distant prop).
The goal is to blit all your assets in as few draw calls as possible, making it viable to build densly populated detailed environments, that are ultimately made out of simple models using customizable materials. Because a lot of game’s look is defined by a few universally reused textures, altering these can easily change the entire game’s look. Change your hardsurface atlas, distress masks, paint overlay atlas and world_noise textures and your games has a new look! By placing a color palette in PaintOverlay atlas and building your assets around that you could swap a game’s color scheme by swapping a single texture. Or make a pallette for each team and then swap the paint overlay texture to apply color schemes for game factions, eras, bioms etc.
At first we’ve got a single Ubershader with all features, but in the future we can split the features up into VisualShaderNodes and allow Framework users to build custom shaders that still use all of Framewrok’s features easily.
Generating API Documentation
The documentation build process is not complete yet, more coming.
To generate the API documentation for the Liblast Framework, run the following command in the repository root:
godot --headless --quit --doctool docs/classes/ --gdscript-docs res://addons/liblast_framework
This will generate XML files that need to be then converted into RST files, which can be then processed using Sphinx to produce HTML files which can be navigated in your browser.
Stay tuned...