LambdaMod 0.1.0 Release

6th May 2021

This is the initial release of LambdaMod. This is really just a preview release, in its current state the game isn't very good for... well, anything. The groundwork has been laid but it's mostly backend stuff (think the scripting language, networking, rendering, VR context creation, etc.) so I'll dedicate this blog post to talking about the things it can't do instead.

Quality of Life

The first item that needs work is the sheer number of rough edges when trying to use the system. For an example take the user-move function, commonly used during testing to reset the camera to the origin. Right now that command looks like this: (user-move my-user-id '(0.0 0.0 0.0) '(1.0 0.0 0.0 0.0)). By removing the requirement for floating point literals in vec3s and quaternions that could be reduced to (user-move my-user-id '(0 0 0) '(1 0 0 0)) and then reduced further with the addition of builtin constants to (user-move my-user-id origin no-rotation). There are lots of editor features that would be useful too, such as the ability to pivot around some sort of 3D spatial cursor like in Blender or the ability to cancel a transform with the Escape key, also like Blender. Generally the editor needs to be a lot more like Blender.

Networking

This is very important for anyone who actually tries to use this version of LambdaMod so I'm going to put it in bold: right now LambdaMod does not have ANY lag compensation features! That means if you play on a network with any significant lag (essentially any Internet connection, probably even some LANs) you're going to directly feel it as input lag when in attached mode or when editing (the viewer mode camera's movement happens on the client-side). This will be rectified in a future version by adding some sort of client-side prediction system but I'm not entirely sure how that's going to work yet. Typical client-side prediction systems work by executing part of the game code (movement, the visual and auditory effects of firing weapons, etc.) on the client. LambdaMod's game code is entirely dynamic and user-specified which makes that approach much more difficult. My preferred solution would be to allow game masters to set very basic fixed-function predictions for inputs i.e. pressing W might predict a physics impulse moving the player character forward, pressing the left mouse button might predict the playing of a firing sound associated with the currently equipped weapon and so on. The specifics of the predictions (i.e. how fast the player character can presently move) would be updated by game code on the server to avoid having a separate execution context on the client and all the additional complexity that would bring, both for the implementation and for game masters. That said, I have little idea if this is a realistic solution. It may simply be too difficult to make the wide variety of predictions necessary in this manner. There are other types of lag compensation to consider as well (interpolation, extrapolation and server-side correction) but I don't plan to tackle them until the client-side prediction issue is solved and I can get a better sense of what's actually necessary to provide a good experience.

Animation & Sound

Full animation features were meant to be in this release but unfortunately they weren't finished in time because I think the current system is a dead end. It was conceived to be extremely simple, only containing controls to start playback and stop it completely. Ultimately I think that model was a little too simplistic. If nothing else a good editor needs the ability to seek through the animation and play segments back to the user for review. Sound has most of the same problems because it uses the same start/stop-only architecture, plus some extra issues with user friendliness to boot.

A stick figure maps pretty well onto how most people understand the human body: the forearm is a roughly tube-shaped object jointed to the upperarm which is another roughly tube-shaped object, that connects to the body which can also be estimated as a sort of tube, there's a ball-shaped thing on top called a head and so on. A piano roll expressed in terms of volume, pitch and tone color is a much worse fit for how people think about sound. People do use these attributes to describe sound (i.e. "it was a very loud sound", "it was so high pitched") but for describing the overall character of the sound people tend to use onomatopoeic concepts like a "hiss" or a "crack" or a "crunch". I suspect this is the direction the sound system is going to head in, replacing or augmenting the existing volume/pitch/tone color system with a collection of flexible sound primitives that better represent how people think about sound. Perhaps a "crack" primitive could be used for a tree snapping in strong wind and also adjusted to create the sound of glass breaking or mixed with a "rumble" primitive to create a tunnel caving in.

Game Primitives

LambdaMod relies on a library of prebuilt primitives to let people build things quickly. These primitives come in three main groups: builtins, game code and controls. Builtins are features like the onomatopoeic sound primitives discussed above and also features like the heightmap primitive and the "boolean-cuboid-interior" primitive, which will be necessary to represent basic natural-outdoor and artificial-indoor environments respectively. Game code primitives handle commonly desired entity functionality like jumping which only works if the character is touching the ground. Controls are features for shaping the player experience and making it more cohesive. Some controls are already in the game, like the Magnitude and Advantage controls which provide peace of mind and metagame consequences for failure respectively, but many more are still to come. In particular I think a Checkpoint control will be vital. Part of the comfort of tabletop roleplaying games is the ability to rewind time at any moment through the mutual agreement of the participants, making it much easier to correct mistakes.

VR

VR support in this version is a basic proof of concept. Last time I checked on it it was possible to open the game and observe the 3D world around you in VR, but not interact with it in any way. That said, given the changes I've made to the linear algebra functions since it's possible it doesn't work anymore. I don't have a great setup for VR development so the VR features don't get tested very often. I suspect VR support won't get improved until after basic lag compensation because the two big ticket items for VR are really physics and animation integration. Physics needs to allow for a Boneworks-style VR body that can grab an object and pull and be pulled by it, while animation needs inverse kinematics features to make visualization of the player's body possible at all. These features are currently 100% server-side which poses problems as VR needs extremely low levels of lag to avoid player motion sickness. The client-side prediction upgrade will move parts of these systems to the client to facilitate that feature, paving the way for VR as well.

These are just the issues I'll probably focus on first, you can check the roadmap in the GitLab for the full list of features I hope to add. Hopefully I'll have a more usable version out soon!

Created by Amini Allight on amini-allight.org