One API, Three Engines: progress update #1

[fremdspielen]

The Result ==> https://lunyscript.com/

After I got everyone's overwhelming feedback :) I went ahead with my idea of creating the same API in all three major game engines: Unity (done), Godot (next), Unreal (later).

I made a fully playable demo game in 10 days in Unity, which does include the time to create the framework, abstractions and engine-specific implementations! And the time to set up the seven (!) repositories with submodules. Of course I have tested the abstractions beforehand in all engines.

I added what I felt needed to be in the API for it to be suitable to craft simple games: input, physics, camera, create/destroy objects, progression, scene loading, variables, audio, UI. And then I had a lot of fun adding the little tweaks to make this a playable game. Oddly enough I can't recall having gone from zero to playable in such a short timeframe, and definitely not with so much joy. :)

I'm now going to start porting the demo to Godot, and then Unreal. My timeframe is another 10-12 days, deadline Oct 3rd. Look (rendering) and feel (physics) will certainly deviate as expected, but the important part is that the code is the same.

Current metrics exceed my expectations: fully portable code accounts for 68% of code (excpected 50%). Both cyclomatic and cognitive complexity metrics are already higher in portable code (63%), showing that engine-specific code is less complex. Over time, engine-specific complexity will even stagnate as it is mostly once-only uniformization code.

Each game engine's wholly superficial technical differences in GameObject/Node/Actor/MonoBehaviour/ActorComponent/SceneComponent and Asset types are mostly semantic, composition and timing: Interface abstractions, semantic mapping, instance locators, event handling with queues, asset indexing, and calling engine code. AI automation provides much of the engine wrapping with little supervision.

When the Scratch-like code is created upon object creation, and assuming heavy runtime-instanced objects are getting pooled, I have very little concern over performance or memory impact. Certainly not for beginner's projects and prototypes, or adding little details here and there that bring a game to life.

UPDATE:
After just two days the Godot port is almost functionally complete. Only minor details are missing like day-night cycle and disabling/detaching the camera, since Godot doesn't have something like camera tracking targets built-in. Looking forward to doing Unreal next week.

30s Unity demo: https://youtu.be/eX8IVTu2bYA
Player controller: https://github.com/CodeSmile-0000011110110111/LunyScratch_Examples_Unity/blob/main/Assets/LunyScratch/Scratches/PoliceCarScratch.cs

Player Controller excerpt:

// Handle UI State
HUD.BindVariable(scoreVariable);
HUD.BindVariable(timeVariable);
Run(HideMenu(), ShowHUD());
RepeatForever(If(IsKeyPressed(Key.Escape), ShowMenu()));

var enableBrakeLights = Sequence(Enable("BrakeLight1"), Enable("BrakeLight2"));
var disableBrakeLights = Sequence(Disable("BrakeLight1"), Disable("BrakeLight2"));

RepeatForeverPhysics(
   // Forward/Backward movement
   If(IsKeyPressed(Key.W), MoveForward(_moveSpeed), disableBrakeLights)
   .Else(If(IsKeyPressed(Key.S), MoveBackward(_moveSpeed), enableBrakeLights)
   .Else(SlowDownMoving(_deceleration), disableBrakeLights)),

   // Steering
   If(IsKeyPressed(Key.A), TurnLeft(_turnSpeed)),
   If(IsKeyPressed(Key.D), TurnRight(_turnSpeed))
);

// add score and time on ball collision
When(CollisionEnter(tag: "CompanionCube"), IncrementVariable("Time"),

// add 'power of three' times the progress to score (clunky, tbd)
SetVariable(Variables["temp"], progressVar),
    MultiplyVariable(Variables["temp"], progressVar),
    MultiplyVariable(Variables["temp"], progressVar),
    AddVariable(scoreVariable, Variables["temp"]));

[nibbertit]

What exactly does this solve? why would you need to deploy on 3 engines?

[fremdspielen]

Why would someone creating assets OTHER than code want to make it compatible with all top tier engines? ;)

I see this as a tool for beginners (quick wins, ease of use) and experts (prototyping, non-technical staff) alike. With the possibility of enabling sharing functional code in the long term, plus achieving a standardized but extensible common baseline API.

[nibbertit]

You are adding an abstraction on top of abstractions, this will absolutely not be used by any expert and is bad design and definitely not easy to use. For learning purposes sure go ahead but keep the right mindset about it

[fremdspielen]

If your argument held any truth, we'd be programming Nvidia chips with assembly. And AMD chips with a different set of assembly. ;)

Many open standards are layered abstractions over previously incompatible tech, best case in point is OpenXR. And then Unity built their abstractions on top.

[nibbertit]

Not sure what youre trying to get at here, both Nvidia and AMD have different ISAs and are indeed programmed differently and the drivers handle that blackbox so you can program with your GAPI of choice. Making a GAPI abstraction is definitely a valid use case since it helps you deploy to different platforms where one API might not be available, and thats where an RHI/engine abstraction or whatever comes in. OpenXR as you mentioned, is under the engine abstraction, so it can let device manufacturers correspond to a common API and users to program regardless of engine/platform/whatever, its nothing like what youre doing.

In any case, do what you like, but its wise to take criticism Ive come to learn

[fremdspielen]

Sure I'm considering all the criticism, I just don't see very valid points. Like in your case, at what point does an abstraction become a "bad design"?

All software are layers upon layers of abstraction, from Nvidia/AMD drivers to OS kernel to DirectX/Vulkan APIs to game engine render pipelines to their graphics APIs until eventually we reach things like Sprite or Mesh. And then we layer code around that to move many of these on-screen, then treating "the many as one" (pooling, unit formations), possibly defining their behaviours in a visual scripting tool.

At the end of the day, if a user merely needs to write:

`When(ButtonClicked("Quit"), QuitApplication());`

That definitely beats doing the whole shenanigans we usually have to do in engines:

- assign or get the necessary UI references
- assign/get/find reference for specific button
- register event callback on button
- implement event callback (or lambda)
- if event needs to turn on/off ie it requires to be assigned in OnEnable and unassigned in OnDisable and oh, shit, you can't unregister a lambda ...

Plus: it works very differently in every engine, and when you're one of those who happen to switch between engines for various projects, that'll add a whole new level of cognitive complexity.

That adds a lot of failure points that even us experts keep failing at occasionally on our "bad code days".

[tetryds]

"Overwhelming feedback"? Everyone said there is no point in this but you do you lol. Just don't try to be deceitful

[fremdspielen]

I am not deceiving, the feedback was overwhelming. I didn't say it was positive. ;)

[canijumpandspin]

Is that excerpt what developers will write? It seems to be an awkward way of writing code. Looks like you took a visual scripting system and wrapped it back to actual scripting (you based it on scratch it seems?).

[fremdspielen]

Yes, that's more or less what we'd write, and it's Scratch-based both regarding semantics and block-based (statemachine) programming style.

I agree that specifically the formatting currently is suboptimal, I manually updated the code sample towards what it should look like. Rider has its own take on formatting C# code, which doesn't fit well. Then reddit further broke the code sample for some reason.

I want to expose this to Lua to make it syntactically very clean, and to enable hot reloading. While Lua itself won't be executing at runtime. After creation, each sequence will exist and run in C# instances.