As 2023 comes to a close I'm really satisfied with where I've been able to bring Dinghy. I'm over the hump of the initial startup cost of just figuring out how to do everything, and given it's trim, code-only nature, it means that working on it now is often just a matter of pulling together threads that already exist in the development workflow/API, adding a little bit new, and then having tangible progress.

The place this manifests most is through the current driving paradigm of Dinghy's development — demo samples. I think this is most inspired by HaxeFlixel's demos page but also especially Heaps' demos page and Sokol's samples page. The idea is simple — enumerate major functionality through single purpose demos. The demos act not only as API examples, but also help to teach "ergonomics" around the engine/API and show how they are all intended to be used together. Developing them also acts as nice little coding exercises that see you actually "using" the engine, and allowing you to question your own biases around the development process and tweak the experience of working with the engine to better approach the target "feeling".

Currently, there are 14 demos in Dinghy that represent core functionality:

1. Texture - Shows how to load in a texture and show it on screen

2. Texture Frame - Shows how to load in a texture and show only a portion of it ("Frame") on screen.

3. Animation - Shows how to load in a texture and slice it for animation playback.

4. Simple Update - Basic demo showing how to use an update loop.

5. Interaction - Shows how to tie into the input system for feedback

6. Bunnymark - Smoke test benchmark

7. Physics - Shows how to setup entities for use in a physics system (uses Volatile physics)

8. Shape - Shows how to spawn a simple shape for an entity (basically a textureless GL_Primitive type object)

9. Physics Shape - same as physics demo but uses shapes

10. Entity Emitter - Just shows how to spawn lots of entities

11. Collision - Shows how to do things like mouseover for entities as well as find closest contact point, etc.

12. Grid - Shows example of using the grid class to spawn entities in a user-specific grid

13. Particle System - Demonstrates the particle system in the engine

At first, each demo was just a function in a top level program, and running them was a matter of commenting/uncommenting the specific demo and rebuilding the project.

This was okay at first, but as the number of demos started to climb it became a bit unwieldy. You can still write Dinghy games fully in a single file (and I recommend you do so for small stuff!) but I realized I needed a better organizational scheme. Additionally, I wanted to be able to switch demos at runtime, which also meant the ability to setup/teardown demos as well as the interface for navigating between them.

These two constraints led the two other major efforts of the past few months since the last update —the creation of a scene system and integration with Dear Imgui.

Before I got into the specifics, I’ll show the end result. Here's me just navigating through the demos one by one in Dinghy:

Pretty nice!

The scene system is inspired a bit by Ceramic’s scene system, and works in the ECS like anything else. This was definitely a big "rubber meets the road" moment as well for deciding if Dinghy was going to truly be only code. There are obvious ways for scenes to just be data and have them configured at runtime a la Unity, but instead of going down that path I wanted to maintain that Dinghy was code-only and as such chose a more OOP model for Scenes (instead of data). You could still totally build a runtime scene editor to plug into the scene system, but out of the box I’m providing a strongly typed object and some utility functions to configure scenes and their lifecycles. Here's a code example of a scene (the basic Texture demo):

namespace Dinghy.Sandbox.Demos;
​
[DemoScene("01 Texture")]
public class Texture : Scene
{
    private TextureData conscriptImage;
    private SpriteData fullConscript;
    public override void Preload()
    {
        conscriptImage = new TextureData("conscript.png");
        fullConscript = new(conscriptImage);
    }
​
    public override void Create()
    {
        Engine.SetTargetScene(this);
        new Sprite(fullConscript);
    }
}

Scenes also do provide Update hooks for objects (the SimpleUpdate example):

using Dinghy.Core;
​
namespace Dinghy.Sandbox.Demos;
​
[DemoScene("04 Simple Update")]
public class SimpleUpdate : Scene
{
    private TextureData conscriptImage;
    private SpriteData conscriptFrame0;
    public override void Preload()
    {
        conscriptImage = new TextureData("conscript.png");
        conscriptFrame0 = new(conscriptImage, new Frame(0,0,64,64));
    }
​
    Sprite e;
    Point startPos = (0,0);
    public override void Create()
    {
        Engine.SetTargetScene(this);
        startPos = ((Engine.Width / 2f) - 32, (Engine.Height / 2f) - 32);
        e = new Sprite(conscriptFrame0)
        {
            X = (int)startPos.X,
            Y = (int)startPos.Y,
        };
    }
​
    public override void Update(double dt)
    {
        e.X = (int)startPos.X + (int)(Math.Sin(Engine.Time) * 100);
        e.Rotation = (float)Engine.Time;
        var scale = (Math.Cos(Engine.Time) * 2);
        e.ScaleX = (float)scale;
        e.ScaleY = (float)scale;
    }
}

Scenes are meant as a better organization system for units of functionality in a game, and multiple can be loaded at once. Like Unity, you do set an "Active" scene (Dinghy calls it a "Target" scene) that designates where spawned entities are spawned into. Entity constructors can override this functionality and spawn entities into non-target scenes as well, but generally you probably want to set a target scene.

Scenes were one of those things that were conceptually easy to do based on all the previous work, so it was exciting to get to work on this because it felt like I was really reaping what I had sown (in a good way).

Getting Dear ImGui working was a bit harder because it meant threading the needle between Dear ImGui, Sokol, cimgui.h, and the Zig build pipeline. Specifically, it was weird because I was mixing C and C++ libs together in a target final DLL. What was nice to find was that the process was a bit simpler to do in the end than I thought it was, but at the same time Zig is still very much in development with pretty bad docs, so finding answers for questions I had was a matter of pestering the Zig Discord until I got the answer I was looking for. For reference, here's my build.zig file, with it largely being an edit of the one Andres created for the Sokol Zig bindings:

const std = @import("std");
const builtin = @import("builtin");
const Builder = std.build.Builder;
const LibExeObjStep = std.build.LibExeObjStep;
const CrossTarget = std.zig.CrossTarget;
const Mode = std.builtin.Mode;
​
pub const Backend = enum {
    auto,   // Windows: D3D11, macOS/iOS: Metal, otherwise: GL
    d3d11,
    metal,
    gl,
    gles2,
    gles3,
    wgpu,
};
​
pub const Config = struct {
    backend: Backend = .auto,
    force_egl: bool = false,
​
    enable_x11: bool = true,
    enable_wayland: bool = false
};
​
pub fn build(b: *std.Build) void {
​
    var config: Config = .{};
        
    const force_gl = b.option(bool, "gl", "Force GL backend") orelse false;
    config.backend = if (force_gl) .gl else .auto;
    config.enable_wayland = b.option(bool, "wayland", "Compile with wayland-support (default: false)") orelse false;
    config.enable_x11 = b.option(bool, "x11", "Compile with x11-support (default: true)") orelse true;
    config.force_egl = b.option(bool, "egl", "Use EGL instead of GLX if possible (default: false)") orelse false;
​
    const target = b.standardTargetOptions(.{});
    const optimize = b.standardOptimizeOption(.{});
    
    const cpp_sources = [_][]const u8 {
        "imgui.cpp",
        "../../cimgui/src/cimgui/cimgui.cpp",
        "../../cimgui/src/cimgui/imgui/imgui.cpp",
        "../../cimgui/src/cimgui/imgui/imgui_demo.cpp",
        "../../cimgui/src/cimgui/imgui/imgui_draw.cpp",
        "../../cimgui/src/cimgui/imgui/imgui_tables.cpp",
        "../../cimgui/src/cimgui/imgui/imgui_widgets.cpp",
    };
    
    const c_sources = [_][]const u8 {
        "sokol.c"
    };
    
     const dll = b.addSharedLibrary(.{
        .name = "sokol",
        .target = target,
        .optimize = optimize
    });
    dll.linkLibCpp();
    dll.linkLibC();
    
    var _backend = config.backend;
    if (_backend == .auto) {
        if (dll.target.isDarwin()) { _backend = .metal; }
        else if (dll.target.isWindows()) { _backend = .d3d11; }
        else { _backend = .gl; }
    }
    const backend_option = switch (_backend) {
        .d3d11 => "-DSOKOL_D3D11",
        .metal => "-DSOKOL_METAL",
        .gl => "-DSOKOL_GLCORE33",
        .gles2 => "-DSOKOL_GLES2",
        .gles3 => "-DSOKOL_GLES3",
        .wgpu => "-DSOKOL_WGPU",
        else => unreachable,
    };
​
    if (dll.target.isDarwin()) {
        inline for (c_sources) |csrc| {
            dll.addCSourceFile(.{
                .file = .{ .path = csrc },
                .flags = &[_][]const u8{ "-ObjC", "-DIMPL", backend_option },
            });
        }
        inline for (cpp_sources) |csrc| {
            dll.addCSourceFile(.{
                .file = .{ .path = csrc },
                .flags = &[_][]const u8{ "-ObjC++", "-DIMPL", backend_option },
            });
        }
        dll.linkFramework("Cocoa");
        dll.linkFramework("QuartzCore");
        dll.linkFramework("AudioToolbox");
        if (.metal == _backend) {
            dll.linkFramework("MetalKit");
            dll.linkFramework("Metal");
        }
        else {
            dll.linkFramework("OpenGL");
        }
    } else {
        var egl_flag = if (config.force_egl) "-DSOKOL_FORCE_EGL " else "";
        var x11_flag = if (!config.enable_x11) "-DSOKOL_DISABLE_X11 " else "";
        var wayland_flag = if (!config.enable_wayland) "-DSOKOL_DISABLE_WAYLAND" else "";
​
        inline for (c_sources) |csrc| {
            dll.addCSourceFile(.{
                .file = .{ .path = csrc },
                .flags = &[_][]const u8{ "-DIMPL", backend_option, egl_flag, x11_flag, wayland_flag },
            });
        }
        inline for (cpp_sources) |csrc| {
            dll.addCSourceFile(.{
                .file = .{ .path = csrc },
                .flags = &[_][]const u8{ "-DIMPL", backend_option, egl_flag, x11_flag, wayland_flag },
            });
        }
​
        if (dll.target.isLinux()) {
            var link_egl = config.force_egl or config.enable_wayland;
            var egl_ensured = (config.force_egl and config.enable_x11) or config.enable_wayland;
​
            dll.linkSystemLibrary("asound");
​
            if (.gles2 == _backend) {
                dll.linkSystemLibrary("glesv2");
                if (!egl_ensured) {
                    @panic("GLES2 in Linux only available with Config.force_egl and/or Wayland");
                }
            } else {
                dll.linkSystemLibrary("GL");
            }
            if (config.enable_x11) {
                dll.linkSystemLibrary("X11");
                dll.linkSystemLibrary("Xi");
                dll.linkSystemLibrary("Xcursor");
                
            }
            if (config.enable_wayland) {
                dll.linkSystemLibrary("wayland-client");
                dll.linkSystemLibrary("wayland-cursor");
                dll.linkSystemLibrary("wayland-egl");
                dll.linkSystemLibrary("xkbcommon");
                
            }
            if (link_egl) {
                dll.linkSystemLibrary("egl");
            }
        }
        else if (dll.target.isWindows()) {
            dll.linkSystemLibraryName("kernel32");
            dll.linkSystemLibraryName("user32");
            dll.linkSystemLibraryName("gdi32");
            dll.linkSystemLibraryName("ole32");
            if (.d3d11 == _backend) {
                dll.linkSystemLibraryName("d3d11");
                dll.linkSystemLibraryName("dxgi");
            }
        }
    }
    
    b.lib_dir = "../../../../Dinghy.Core/libs";
    b.installArtifact(dll);
}

On the actual library side, I ended up using the cimgui.h C bindings for the actual C# PInvoke code, which, as you can see above, is compiled alongside the normal C++ Dear ImGui library in the final DLL. I tried binding against the raw Dear ImGui headers, but ran into some issues with the PInvoke code for the C++ headers that were maybe solvable but I just opted for cimgui.h instead. Like everything else, the bindings are generated via ClangSharpPInvokeGenerator for MAXIMAL SPEED.

Once the scene system and Dear ImGui were setup, I set about porting all the demos to the scene system and used some nice little bit of reflection (did you notice the attributes on the Demo code samples?) to procedurally build the UI to move between them. This means the overhead to add new demos is really low, which helps me maintain development velocity and not feel too much pressure about how hard it may be to add a new one. Here's the relevant code:

ImGUIHelper.Wrappers.BeginMainMenuBar();
if (ImGUIHelper.Wrappers.BeginMenu("Dinghy")) {
  if (ImGUIHelper.Wrappers.BeginMenu("Demos")) {
    Scene? scene = null;
    foreach (var type in demoTypes) {
      if(ImGUIHelper.Wrappers.MenuItem(type.Name)) {
        scene = Util.CreateInstance(type.Type) as Scene;
        scene.Name = type.Name;
      }
    }
    if (scene != null) {
      Engine.TargetScene.Unmount(() => {
        scene.Mount(0);
        scene.Load(scene.Start);
      });
    }
    ImGUIHelper.Wrappers.EndMenu();
  }
  ImGUIHelper.Wrappers.EndMenu();
}
ImGUIHelper.Wrappers.EndMainMenuBar();

You can see a peek at some scene lifecycle management stuff here as well — Unmount has a callback you can tie into to do whatever else — in this case I mount a new scene and set it to Load, with a callback for the scene to start right after it loads.

You can also see some ImGUIHelper.Wrapper methods — working with raw PInvoke ImGui bindings is a bit onerous for end users (lots of fixed statements, etc.), so I'm working to wrap a lot of the functionality around managed function calls that at least get rid of boilerplate for ImGUI stuff and provide ways to pass strings to function calls without needing to explicitly call fixed in your own code. For example, ImGUIHelper.Wrappers.BeginMenu("Dinghy") wraps this way:

public static unsafe bool BeginMenu(string name, bool enabled = true)
{
    var b = System.Text.Encoding.UTF8.GetBytes(name);
    fixed (byte* ptr = b)
    {
        return Internal.Sokol.ImGUI.igBeginMenu((sbyte*)ptr,(byte)(enabled ? 1 : 0)) > 0;
    }
}

This way it's really easy to add in normal ImGUI calls wherever. For example (again), one thing I did that you may have seen in the particle demo is that I can use a similar reflection thing a la Unity to draw runtime property editors for any object:

This code is all you need to do that:

DrawEditGUIForObject("emitter",ref emitter);

You can easily do this for any object or config anything. It's really nice! I suspect this function may be used a lot for Dinghy games so I'm working on fleshing it out a lot with nice defaults based on field types, and also providing ways for devs to author their own properties for editing (think Unity CustomPropertyDrawer but with ImGUI). I'll likely defer serialization to end-users as well, but proving a nice on-demand edit option for users is pretty nice (I think!).

A note on Magic: Dinghy's core pillars are still immediacy, coziness, and magic. Right now I think I'm doing a lot in the immediacy/coziness dimension, but the engine definitely lacks the Magic. I've got plans for implementing that stuff down the road, but for now the core functionality is still the target, and the Magic is something that would build on top of that foundation. As such, not a lot of magic right now!

Lastly, one thing I've been thinking a lot about is Luau. I spiked a prototype to get Luau working in C#, and the more I think about it the more I think it would be really cool for most all of Dinghy's functionality to be exposed via Luau scripts. This would unlock things like live-coding at runtime, which, afaik, isn't a thing most engines offer. I'm really inspired by what seems possible with Luau (not to mention it being battle-tested by the Roblox team), and I like the idea that Dinghy could, with Luau support, be a stepping stone for Roblox players/creators looking to leave the Roblox ecosystem and do standalone development. Also, live-coding is definitely in line with the principle of "immediacy", so I'm really considering it. That said, the only work done so far is that prototype, but expect to hear more about Luau in Dinghy in the future.

In all, I'm feeling really good where Dinghy is at. It's really meeting the exact goals I set out for it from the start, and I can feel how already I want to make stuff with it. If you're someone also interested, please reach out to me! I'd love to put together a small cohort of users to start getting a sense of how people like it/what they want/need. There are a ton of loose ends and missing functionality in the engine, but I think it's already at, if not VERY close to, having a lot of what you need to make a simple and small game to post somewhere like itch. If this is you, please reach out!

Otherwise, looking forward to sharing more progress in the next few months about where things are at and also hopefully share the first real game made with it!

Until next time!

Subscribe now

At Afterschool, we’re committed to building out not only internal tools to help us develop games more quickly, but to also release some of those tools out into the wild to help grow the wider game development ecosystem.

To that end, we’re spinning up a new section of this newsletter, Tools, that tracks the progress and development of our tools and other R&D efforts.

Subscribe now

We’ve got two posts already available for reading:

First, an overview of the C# game framework we’re working on, Dinghy:

Next is the first alpha release of a skunkworks moodboarding tool we’re developing called Dreamwalker:

In addition, we’ve got two other tools fully available now, both used throughout Cantata, that we have released publicly:

Depot

https://depot-editor.com

Depot is a data editing tool designed for games that give you the ability to author rich interconnected data in a JSON format but edited like a spreadsheet. We used Depot extensively on Cantata and as such is the backbone of the game as well as its modding format, translation data, etc.

For games of any size, Depot is the tool for you.

Download for Visual Studio Code here (11K downloads!)

Squiggle

https://github.com/afterschoolstudio/squiggle

Squiggle is a very simple scripting language and runtime that allows you to author and execute sequential commands inside a game at runtime. We developed Squiggle as a lightweight alternative to tools like Ink or Yarn, such that we could author dialog and code-commands inside of Cantata without needing to perform a pre-compile step.

This is a simple Squiggle script:

[playSound knock 1]
Carol: Hello! I've arrived!
Carol: And I've brought something special!
[playAnimation move carol door]
[setLights dim]

We’ve got a specific forum section for our tools where you can talk about them/test out new releases here:

We’ve got a few other things in the pipe as well that we’ll be happy to talk about in the future, but just wanted to generally share everything we’ve been up to both in and around game development and hopefully inspire people to make their own tools, and give ours a try!

Lastly, this email was sent out as part of the “Tools” section of the Afterschool newsletter. We’ve gone ahead and added everyone to the newsletter by default to get the word out, but if you don’t want news/updates on our tools, you can unsubscribe to just this section of the newsletter by managing your subscription in Substack.

However if you’re new to us or want more, feel free to subscribe! Thanks for reading and talk again soon!

Subscribe now

I’ve been playing around with generative image models a lot since last year and one major thing that stuck out was that using them in general seemed to really de-emphasize “playfulness”. The tools then (and now) were really geared towards the idea of putting together “the perfect prompt” instead of just experimenting. Chat interfaces, prompt construction, etc. all seem ill-suited for the work of “finding the image you’re looking for”.

I’d had an idea in my head for a while around trying to make this experience better, and when the first AIxUX was announced in NYC I thought I’d throw my hat in the ring and hack on something to see what could come of it. And I did it! Here’s my presentation from that event (timestamped):

I called it “Dreamwalker” — a way to explore latent space. I also got the domain. The idea was to make working with image generations more like developing, or even tending to something like a moodboard. Have it be this corpus of exploration that sees you searching for ideas and pruning branches and trying to hone in on what you’re thinking.

The idea is that Dreamwalker gets you from that blank page feeling and maybe does help you find a good prompt, but helps you mostly just get started. The images it generates can be starting points, helpful to find that next step.

After the presentation, Dreamwalker sat on my harddrive for a bit. I thought about what I wanted to do with it and all the dreams I had for things it could do, but instead of trying to do all of it I have just (ROUGHLY) buttoned up the core features of the tool and am happy to finally release it to the world today to see what people think. Here’s a video demonstrating the core functionality of the tool:

I think in part, seeing what OpenAI is doing with DALL-E chat prompt work makes me want to also get a stake in the ground for the way I think things should go. I want people to be able to think outside the chat prompt for image model interaction, and hopefully I can inspire some other people to also create non-traditional AI tools.

You can download Dreamwalker via the link below, and also find some instructions on how to use it:

Download Dreamwalker Here

The link is a forum link, so if you have thoughts or ideas or comments, feel free to leave them there! I’d love to know what people think and what they find useful/features they would like to see.

Thanks for reading!

Turns out making a whole videogame is a lot of work, so the amount of time I've been able to dedicate to any side projects had been somewhat minimal. Doing something as "big" as Dinghy is even harder to find time for, because there's so much initial exploration and so little return.

There HAS been work though, especially since Cantata's release, so here's something I'm happy to show:

I'll talk about this more in a little bit, but first wanted to talk a little bit about thinking instead of just coding.

Subscribe now

Something that working on Cantata forced me to do, just given time contention, was that the time I could spend on Dinghy was never enough to really start coding it. So instead, I spent a lot of time thinking about it, channeling Rich Hickey's idea of "Hammock Driven Development". I have a lot of project ideas, but not a lot of time, so my strategy for focusing on something/choosing something to actually pursue is to, almost like spaced repetition, return to ideas over time to see if they "stick". If they don't stick, I'll stop letting it take up mind space, and if so, I'll think a little more about it. I write down nearly every idea I have with this in mind, knowing that 90% of them will fade beyond that initial spark, but some will indeed rise to the top. I continuously circle around the ideas and try to re-surface them to myself often enough that I can reevaluate if I still like the idea, and if so, think more about it.

Keeping this running catalog of ideas is especially important during the throes of another project. Big projects take up all of your time, but then can all at once stop, and then that vacuum of newfound free time can easily absorb even the most ill-advised idea that may have just happened to pop into your head around the same time. What you want is that when you free up, you start working on the right next choice. And after many rounds of thinking over it and it continuing to stick, Dinghy is definitely one of those things.

Dinghy consistently passes that test of "stickiness", and over time feels like what it's trying to do is more than just convenient but instead, vital. An exodus of C# programmers from Unity, especially people that do 2D, are looking around and trying to find what makes sense to go to next, and there honestly aren't enough good answers. Dinghy is trying to be one of them. It's meant to be a simple, cross platform framework for C# that you can rapidly prototype games and interactive things in, but also have bones that can scale to larger projects. Seems simple enough, and all the pieces are really laying there, but nobody else has done it!

I think also really just sticking to 2D and never trying to touch 3D is really helping me maintain that focus. If you assume 2D, you can do a lot of stuff around engine/API UX that wouldn't make sense for a 3D engine, but also would make there be a lot of "API noise" for people doing 2D things in an engine that supports 3D. So we're keeping it trim and to the point.

So what has actually happened? Well, a lot!

Sokol

Probably the biggest change from the previous blog posts and is that I moved from Kinc to Sokol. There are a few reasons for this:

• Sokol is generally further along than Kinc and feels less like a prototype.

• The primary maintainer of the Sokol repo is really friendly and responsive.

• More people in general know about Sokol and use it. For someone like me that knows so little, being able to ask about Sokol to other people besides the repo owner is really nice.

• Sokol has tons of examples, making learning the headers a lot easier! The documentation is also embedded in the source itself, which is weird at first but then turns out to be really nice — you just search what you are looking for in the IDE and can instantly pull up the docs about it.

• Sokol has lots of built in support for other libs (DearImGUI, etc.) that are mostly drop-in.

Related to that last point, Sokol has a lot of nice little things that really help out engine dev. The DearImGUI bindings are obviously big, but then other nice examples like the Fontstash interop, Debug Text, and upcoming WebGPU bindings, make me feel good about "living" in the Sokol ecosystem.

Sokol_GP

As a small aside, I'm also primarily using Sokol_GP for the actual 2D drawing — it's basically a simple modern 2D drawing lib that sits on top of Sokol mostly with ease of use. You can mix and match Sokol's core libs with GP, so it's been pretty nice!

ClangSharpPInvokeGenerator

I've also moved to using the ClangSharpPInvokeGenerator to generate the PInvoke code to bind C# to Sokol and other libs. In the past I was mostly handwriting all the PInvoke code. This was... insightful, but incredibly tedious and really prone to error. It was nice to get my head around the whole Marshalling/PInvoke workflow, but one thing you realize in doing that is that there is a right answer to any binding function, and as such generating them is far more efficient. I also learned more about the concept of "blittable" bindings (aka, no runtime Marshaling), which pushed me to adopt the new generator because it directly spits out those bindings!

Working with blittable bindings is great for performance, but it does mean the API surface of using those functions is a bit more involved. Starting up Sokol for example looks like this:

unsafe
{
    var window_title = System.Text.Encoding.UTF8.GetBytes(opts.appName);
    fixed (byte* ptr = window_title)
    {
        //init
        sapp_desc desc = default;
        desc.width = opts.width;
        desc.height = opts.height;
        desc.icon.sokol_default = 1;
        desc.window_title = (sbyte*)ptr;
        desc.init_cb = &Initialize;
        desc.event_cb = &Event;
        desc.frame_cb = &Frame;
        desc.cleanup_cb = &Cleanup;
        desc.logger.func = &Sokol_Logger;
        App.run(&desc);
    }
}

Pointers? Fixed?? Address references??? Doing it this way does mean you've got to dive headfirst into unsafe waters, which (for me at least) meant a large onboarding period of just wrapping my head around this "type" of C# programming. But now that I'm on the other side of that cost, I'm much more comfortable with it! C# can also nicely encapsulate this work, so for anyone who uses Dinghy they don't need to worry about any of it. Working in Dinghy is more "normal" C#.

As a side note, I think I may write a small post on my main blog about using the generator. The docs are a bit hard to parse so I think it could be useful to see a common use case in action.

Zig Build

So I've got nice new bindings for Sokol, but how about actually compiling the headers?

Previously, the build system was a bit weird. But weird in a way that I imagine any cross-platform library is. Building the headers meant generating platform-specific project files for the dependent platform (Visual Studio/MSVC on Windows, XCode on OSX), then basically building those projects from the command line version of those tools. This seemed sort of inescapable, and I guess is nice for some use cases, but I always found it sort of jank.

But then I learned about Zig, and more specifically that Zig ships with a drop-in, cross-platform C compiler replacement. I tried it... and it works?? It feels like magic. So now all I basically do is just run zig build (with the correct Zig script) and out comes platform-specific DLLs.

I'm also lucky here because Sokol has actively maintained and auto-generated Zig bindings, and also happens to have a Zig Build script that I can copy and modify to build a DLL instead of an exe. Thanks Andres!

Worth saying as well that I am generally digging Zig. Dinghy is still very much focused to be a C# library, but I can definitely see myself dipping into Zig + Sokol land on the side.

General Lib Workflow

This pipeline also really works for other STB style libs, so I've started to incorporate some STB headers in as well. stb_image specifically is now in the engine for image loading, and I'm eyeing others in there as things grow out. I feel like with STB and other single-file header libs (like the Cute ones), I'll have most core functionality I'll need at the C level and all the wrangling of libs themselves at the C# level.

ECS

Everyone's favorite game development buzzword. I'm making Dinghy be an ECS-oriented engine (via Arch). If I'm honest I'm just trying this on a bit. I'm not fully committed to it yet but so far it's a nice paradigm and it is fast. I think people discount how many objects are often in 2D games compared to 3D games, so it does feel like gaining performance from this paradigm makes sense.

You can circumvent the ECS (or everything?) in the engine if you want, but I intend to make all the learning material/tutorials/etc. try to repeat and show the same paradigms. The "critical path" of the engine should feel well-trodden and smooth.

One thing I do like about Arch is that, in addition to just the general quality of the library itself, it has some Dinghy-aligned features (specifically "magic") that I think will be nice to have via it's Extensions package and the source-generated Queries (aka systems):

[Query]
[All<Player, Mob>, Any<Idle, Moving>, None<Alive>]  // Attributes also accept non generics 
public void ResetVelocity(ref Velocity vel)
{
    vel = new Velocity{ X = 0, Y = 0 };
}

The actual query code is source-generated against that function + attributes, and reduces the overall need for boilerplate.

Actual Engine Screenshot

So let's talk about what we're seeing here (It runs smooth I promise, just GIF recording, etc. etc.):

Hell yeah! So at a baseline, the key thing is that, all you need to get what you see on the left is just the code on the right (provided you have the Engine DLLS obv, etc. etc.) No platform setup code, no GraphicsDevice to worry about — You just write the code on the right, and you can do what's on the left. Ideally we can make it even more terse, but for now you get the idea. The code is basically all signal with minimal (no?) boilerplate.

What's especially cool about this is that, a few years ago, I wrote fake Dinghy code to show how I wanted game authoring to be, and this basically meets that target. It's also not like it's sitting on a ton of abstractions just to prove a point — this is all workhorse code that you would probably write the same if it's for your project.

Low "Ceremony"

Jon Skeet (blessed be he), has this concept of "ceremony" in programming. The idea of it is sort of ancillary noise that has to exist next to code that actually does something, such that the "ceremonial" code isn't doing much besides scaffolding the core idea. So the idea is that ideally you can reduce how much ceremony which is required at a baseline, but, when you want to roll out the red carpet, you can still bring it back.It's the difference between old C# style "high-ceremony" main function entry:

public class Program {
	public static void Main(string[] args) {
		Console.WriteLine("Hello World")
  }
}

And the "low ceremony" new style top-level statement entry:

Console.WriteLine("Hello World"); //literally all you need in a Program.cs file

You can still do it the old way, but all the code is basically boilerplate and is the same for 99% of use cases, so instead of requiring ceremony, you can just do the thing you intend. Default instead to a common base case, with opportunity to expand into full ceremony if necessary.

Dinghy.Quick

Dinghy is very much crafted in this mold, and to that end is the Dinghy.Quick namespace, which this the code above uses. It's "you'll most likely do it this way" style functions and wrappers that are meant for quickly scaffolding games, and gets at that Dinghy tenet of "Immediacy" (with a dash of "cozy"). It takes barely two lines of code to get a sprite on screen, and nothing about the function constructors or method calls are ambiguous about what they output is.

You can use all the Engine APIs yourself (and you will for any large project), but the idea is to onboard new people really easily with the most likely versions of functions and data that they will use, and you can change it up when you outgrow them.

So instead of writing:

InputSystem.Events.Key.Down += (key) =>...

You can write:

OnKeyDown += (key) =>...

Workflow

Similarly, one of the key things I've been working on here was to really understand the development loop for Dinghy, and asking myself what does it mean to work with it.

I think this is related to a thread drawn from Dinghy's idea of "magic", but the more I think about games the more I really just end up thinking about "how can we make working with Data better?"

Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won’t usually need your code. – Eric Raymond

Game programming (and generally working with game engines) is so wrapped up in thinking about code that I want to try to frame (to users) that working with Dinghy is less about writing code and more about just hooking up data. Yes, there will be still be scripts and whatever, but thinking about, and getting users to think about, data from the very start of the project will I think be something really useful.

It's related to the idea that good data and dumb code is almost always better than bad data and good code. Dinghy wants to try and always give you Good Data, so that hooking it up for games is trivial. Going back to the idea of ceremony, it means looking at data as something that can be directly actionable instead of needing to wrap it in boilerplate.

There's the murmurings of an asset pipeline in the engine now (but also where a large focus of the "magic" I want to be is at), but the gist in terms of the current implementation is that external assets are wrapped up into data containers, and those data containers then have the ability to instantiate the most likely version of themselves into the world.

Dinghy will provide a lot of the common 2D ones out of the box (Textures, Sprites, Tilemaps, Animations, etc.), but you also easily author your own and tie those into the "import" pipeline. You can also easily compose data structures together (they're just classes) so if you need larger composite structures you can build those out as well.

As an aside, I just wanted to mention how this is different from things like Unity out of the box. In Unity, you import an asset. That asset is just an asset and can be theoretically used for anything. In Dinghy, we assume that all data is instead actionable via it's own definition of an asset. Once an asset is in Unity, it's just loose sitting around, and then is attached to a component. That component can be on literally any type of object, that can then also contain literally any other components. On one hand, it's very flexible, but on the other hand it's very prone to foot-gunning and misconfiguration, as there are basically no guardrails towards doing what is likely intended. Dinghy instead is meant to be more rigid, and provide you with guardrails geared towards productivity, with the ability to move outside them if you want to.

Data -> Entity

So for a simple example, we've got SpriteData, which takes in a reference texture name and some data about where the sprite should go on screen, great. Here's SpriteData currently:

public record SpriteData(string texture,int startX = 0, int startY = 0) 
  : EntityData {
    public override void GetEntity(out Entity e)
    {
        e = Engine.World.Create(
            new Position(startX, startY), 
            new SpriteRenderer(texture));
    }
}

Notice that Data is a record, meaning that the class is meant to be immutable. It's just a container for information. However, by being data you have to define some notion of what it means to consume you. If you're a SpriteData, that means you're probably making a Sprite, and as such there is a direct function implemented to do just that.

You can still have non-object data, but the goal is to have no "loose" stuff lying around — everything should be data build towards entities, or data that gets directly incorporated into the development experience via [magic] code, but more on that in a future post.

Entity -> Components

Once you've got an entity, you add some components to it to give it behavior. SpriteData's Entity gives you a Position and SpriteRenderer by default, but you can also add components after the fact (Arch has a few ways to do this):

SpriteData logo_img = new("logo.png");
var logo = Add(logo_img); //adding the logo to the scene
logo.Add(new Velocity()); //adding a velocity component

In addition to components, you can also do non-component behavior modification to the entity as well, so you can use the ECS to-taste:

OnKeyDown += (key) =>  {
	ref var vel = ref logo.Get<Velocity>(); //arch's way to grab component data
	(int dx, int dy) v = key switch {
		Key.LEFT => (-1, 0),
		Key.RIGHT => (1, 0),
		Key.UP => (0, -1),
		Key.DOWN => (0, 1),
		_ => (0, 0)
	};
	vel.x += v.dx;
	vel.y += v.dy;
};

If I was building this out as a real demo, I'd move that movement update code into its own PlayerMovementSystem class, and add in a PlayerControl component. But also if you're just throwing something together, you aren't beholden to just ECS. For really simple demos I could see also just not really emphasizing ECS, but then for more advanced ones showing how to work with it. Speaking of ECS...

Components -> Systems

This is probably the main area Arch comes in, and leverages a nice querying/filtering API to act on Entities with the correct components in a (basically) non-allocated way:

var query = new QueryDescription().WithAll<Position,SpriteRenderer>();
Engine.World.Query(in query, (in Entity e, ref SpriteRenderer r, ref Position p) => {
  //act on entites that match the query
}

For Dinghy, queries are simple classes that wrap Arch queries. They are registered with the engine internals and execute based on the Interface they implement:

public abstract class RenderSystem : DSystem, IUpdateSystem {
    public void Update() {
        Render();
    }
    protected abstract void Render();
}

public class SpriteRenderSystem : RenderSystem {
    QueryDescription query = new QueryDescription().WithAll<Position,SpriteRenderer>();
    protected override void Render() {
        Engine.World.Query(in query, (in Entity e, ref SpriteRenderer r, ref Position p) => {
            //render code
        }
    }
}

Right now there is just IPreUpdate/IUpdate/IPostUpdate, but I may add more.

If you want to make a custom system in Dinghy, you just extend the base system and then add the interface in order to hook into standard system ticks.

Performance

I ran a naïve BunnyMark test and this current configuration gets me 50,000 entities all updating at 60fps. Not bad! There are lots of ways to make it faster, but it's nice to know that if you aren't thinking about performance at all you can get a pretty nice baseline without minimal setup.

Subscribe now

Wrap

In general, I'm really happy with where Dinghy is at and where it's going. I feel like I could honestly start giving it out to some people soon if they're interested in giving it a spin and giving me some early feedback.

If you think this is you, feel free to respond to this email! Would happy to know what you're looking for and what you want to try and make. If you aren't getting this through email, you can email me at kyle@afterschool.studio and say you're interested in trying it out!

Otherwise, hoping to have at least one more update post by the end of the year, but until then thanks for reading and being part of the ride. Talk soon!

Hello all!

WHEW!

Cantata has fully made its way into the world and I couldn’t be happier with how it’s been received. To be clear, it is definitely a strange game and some people have bounced off it for that, but for every person that doesn’t find it to taste there are people that are pouring hours into the game and really engaging with what we’re trying to do.

Purchase Cantata on Steam ↗

For the unconvinced (and the confused) though, we’ve put together a How-To video to help visually walk people through what it actually means to play Cantata. If you don’t want to play the in-game tutorial or just want to check out what playing Cantata actually “is” before buying, I highly recommend you watch the video. It’s not an annotated play through of the tutorial, but instead a visual walkthrough of all the parts of the game with examples, highlighting, etc.

Check it out here:

As we move beyond the 1.0 release of Cantata, I’m also starting to chart a path for what development looks like for the game. The Campaign of the game is finished, and as I look down the road there’s a fair number of quality of life enhancements for the game possible as well as focusing on heavily-requested items like a proper Skirmish AI.

Given that the development team is now just me, I’m unable to just work on everything at once, as much as I’d like to! So what I’ve done is introduce a feature voting portal on our forums where people can vote (and comment) on what specifically they would like to see next in the game:

Access Feature Voting ↗

On the page, once you register, you can vote for two options in the category. Once the category is closed, you will get any votes you put towards that category back and can reallocate them! My hope is that this helps everyone who plays and is interested in the ongoing work of Cantata feel empowered to help steer development towards what they would like to see in the game.

Lastly, if you’re playing Cantata and enjoying it, please leave us a review on Steam! Every little bit helps as we’re still small a relatively low-profile game!

Cantata on Steam ↗

Beyond that, we’ve still got more things cooking around Cantata. I want to make the game great and think we’ve got all the ingredients here to build something special on top of a solid foundation. Until next time, thanks so much for reading and following us along this journey. Enjoy your time on Shoal, discover its mysteries, and we’ll talk again soon!

A journey that started nearly a decade ago is finally coming to a close as today Cantata is officially released into 1.0 on Steam.

Purchase Cantata on Steam ↗

To all of you that have been with us since the very beginning, thank you. The belief people held early on that this was a game worth playing and the comments and feedback given to the game from that point up until now have not only helped me continue what has turned out to be an incredibly ambitious and admittedly weird game, but have helped to better shape what the game actually is.

As you can likely see from this email as well, we’ve changed newsletter provider and are now on Substack! The newsletter itself has been rebranded as The Afterschool Studio Newsletter to better reflect that this is not only the gathering point for Cantata, but a place for us to track the ongoing development around other projects (some exciting NEW things that are as of yet unannounced).

We’re also happy to announce that today marks the release of the Dreamwalker edition of Cantata!

In addition to the game itself, the Dreamwalker edition contains an absolutely MASSIVE soundtrack for the game:

Cantata’s composer, Royal Teague, went all out for this, and we’re so happy to offer a way for the music to be listened to outside the scope of the game itself. This thing also goes as well, and is full of music that totally stands up on its own while also conveying the texture of the game it’s pulled from. It’s that good listening, if you know what I’m saying. We even snuck a few tracks on here that aren’t even in the game! We can’t help ourselves!

With all that said, I again want to thank everyone that’s been on this journey with us since the alpha launched all those years ago. I’ve personally learned a ton about game development and design (and business!) in those years, and for all that stuck through until now, thanks for believing in me and thanks for believing in Cantata.

Purchase Cantata on Steam ↗

(If you purchase and play, please leave us a positive review! It seriously helps the game standout on Steam’s backend and will help it find more players!)

As Cantata crests out of Early Access and into 1.0, we’re obviously thinking about the future of the game and what it will hold. We’ve got some really interesting ideas in the pipe that we’ll be relying on the community again to help us navigate, so if this sounds interesting to you, definitely subscribe below to be notified when that (and some other things around REDACTED) are announced!

Subscribe now

Thanks so much for reading and following us along this journey. For now, enjoy your time on Shoal, discover its mysteries, and we’ll talk again soon!

Subscribe now