Brent

Force updating project's engine code

One of the problems with being an engine developer is that often you want the latest changes you've done to the engine to be pulled into the project you're working on. Historically, the way that you would do this is by bumping the editor version in editor_version.go and then loading the project. This will trigger the out of date popup and ask you to replace the source in the project. This is a bit annoying when you're doing incremental changes to test and not releasing a whole new editor version.

So I've fixed this problem by adding the ability to trigger the engine replace popup by holding Shift+CTRL when opening a project from the project select screen. This will do the exact same flow as an editor version bump without the need to waste your time messing with bumping the editor version.

Ditching the GOB encoder (and making my own)

The Problem with gob

For a refresher of what the gob encoder is, it's basically a replacement for what people often use protocol buffers (aka ProtoBuf) for. Using reflection, the package is able to efficiently map your structure/data to a binary format while being able to change/modify your structure. This is useful for storing the data as a file format or sending it over the internet. This is particularly useful because the structure/type is irrelevant, all that matters is the fields/data.

Focusing on that last sentence there, you might be able to see where things start to go wrong. When serializing types hidden within interfaces, you need to register that type with a call to something like gob.Register. This will register your concrete type so that it can be spawned from the data. There is one fatal flaw, types with identical fields will collide and the package will panic.

Take for example these two structures:

type First struct {
    Index int
}

type Second struct {
    Index int
}

type EntityData interface {
	Init(entity Entity, host Host)
}

type GameBoardSpawn struct {}

Custom POD encoder

Below is a breakdown of the pod encoder.

1. Uses fully‑qualified type names (package + struct name) as the unique key, eliminating collisions for empty or identical structs.
2. Stores a type‑lookup table and a field‑lookup table in the binary header, so the format is self‑describing.
3. Skips unsupported kinds (pointers, interfaces, channels, functions, unsafe pointers) during encoding, because they cannot be reliably reconstructed without additional context.
4. Supports slices, arrays, and nested structs while preserving field order independence—fields can be added, removed, or reordered without breaking compatibility.

How It Works (High‑Level Overview)

The encoder/decoder are in the engine/encoding/pod folder.
- pod_encoder.go - builds the lookup tables, writes the header, and recursively encodes values.
- pod_decoder.go - reads the header, resolves types, and recursively reconstructs values.

Both files rely on a global registry (a sync.Map) that maps a qualified type name to its reflect.Type. Registration is done via pod.Register and unregistration via pod.Unregister.

This new encoder is actually very simple thanks to reflection. There is actually more test code than actual encode/decode implementation code, which is also nice.

SIMD Optimizations for Matrix Operations in Kaiju Engine

Introduction

The following post walks through the three core functions we accelerated, explains the assembly line‑by‑line, and shows the real‑world benchmark impact.

Benchmark Summary

These gains translate directly into higher frame rates and lower CPU budgets for physics, animation and UI rendering.

AMD64 Assembly Breakdown

1. Mat4Multiply

// func Mat4Multiply(a, b Mat4) Mat4
TEXT   ·Mat4Multiply(SB),NOSPLIT,$0-192
	// Load b rows (contiguous)
	MOVUPS b+64(FP),  X1  // b row0
	MOVUPS b+80(FP),  X2  // b row1
	MOVUPS b+96(FP),  X3  // b row2
	MOVUPS b+112(FP), X4  // b row3
	// Compute ret row0 = sum (a row0[k] * b row k for k=0..3)
	MOVUPS a+0(FP), X0    // a row0: a00 a01 a02 a03
	MOVAPS X0, X5
	SHUFPS $0x00, X5, X5  // broadcast a00
	MULPS  X1, X5         // a00 * b row0
	MOVAPS X0, X6
	SHUFPS $0x55, X6, X6  // broadcast a01
	MULPS  X2, X6
	ADDPS  X6, X5
	MOVAPS X0, X6
	SHUFPS $0xAA, X6, X6  // broadcast a02
	MULPS  X3, X6
	ADDPS  X6, X5
	MOVAPS X0, X6
	SHUFPS $0xFF, X6, X6  // broadcast a03
	MULPS  X4, X6
	ADDPS  X6, X5
	MOVUPS X5, ret+128(FP)
	// ... rows 1‑3 repeat the same pattern ...
	RET

2. Mat4MultiplyVec4

// func Mat4MultiplyVec4(a Mat4, b Vec4) Vec4
TEXT   ·Mat4MultiplyVec4(SB),NOSPLIT,$0-96
	MOVUPS m+0(FP),  X0
	MOVUPS m+16(FP), X1
	MOVUPS m+32(FP), X2
	MOVUPS m+48(FP), X3
	MOVAPS   X0,  X4
	UNPCKLPS X1,  X4
	MOVAPS   X0,  X5
	UNPCKHPS X1,  X5
	MOVAPS   X2,  X6
	UNPCKLPS X3,  X6
	MOVAPS   X2,  X7
	UNPCKHPS X3,  X7
	MOVAPS   X4,  X8
	MOVLHPS  X6,  X8
	MOVAPS   X4,  X9
	MOVHLPS  X4,  X9
	MOVAPS   X6,  X12
	MOVHLPS  X6,  X12
	MOVLHPS  X12, X9
	MOVAPS   X5,  X10
	MOVLHPS  X7,  X10
	MOVAPS   X5,  X11
	MOVHLPS  X5,  X11
	MOVAPS   X7,  X13
	MOVHLPS  X7,  X13
	MOVLHPS  X13, X11
	DOT(b+64(FP), X8, ret+80(FP))   // x
	DOT(b+64(FP), X9, ret+84(FP))   // y
	DOT(b+64(FP), X10, ret+88(FP))  // z
	DOT(b+64(FP), X11, ret+92(FP))  // w
	RET

3. Vec4MultiplyMat4

// func Vec4MultiplyMat4(a Vec4, b Mat4) Vec4
TEXT   ·Vec4MultiplyMat4(SB),NOSPLIT,$0-96
	MOVUPS    b+16(FP), X1
	MOVUPS    b+32(FP), X2
	MOVUPS    b+48(FP), X3
	MOVUPS    b+64(FP), X4
	DOT(a+0(FP), X1, ret+80(FP))    // x
	DOT(a+0(FP), X2, ret+84(FP))    // y
	DOT(a+0(FP), X3, ret+88(FP))    // z
	DOT(a+0(FP), X4, ret+92(FP))    // w
	RET

ARM64 Assembly Breakdown

1. Mat4Multiply

// func Mat4Multiply(a, b Mat4) Mat4
TEXT   ·Mat4Multiply(SB),NOSPLIT,$0-192
	FMOVQ b_0+64(FP),   F0
	FMOVQ b_4+80(FP),   F1
	FMOVQ b_8+96(FP),   F2
	FMOVQ b_12+112(FP), F3
	MULROWWISE(0,  128)
	MULROWWISE(16, 144)
	MULROWWISE(32, 160)
	MULROWWISE(48, 176)
	RET

// macro used above
#define MULROWWISE(inOff, outOff) \
	FMOVQ a_rI+inOff(FP), F4      \
	VDUP V4.S[1], V5.S4           \
	VDUP V4.S[2], V6.S4           \
	VDUP V4.S[3], V7.S4           \
	VDUP V4.S[0], V4.S4           \
	MULSUM4ROWS()                 \
	FMOVQ F14,    ret_rI+outOff(FP)

#define MULSUM4ROWS() \
	WORD $0x6e24dc08  \  // fmul.4s v8, v0, v4
	WORD $0x6e25dc29  \  // fmul.4s v9, v1, v5
	WORD $0x6e26dc4a  \  // fmul.4s v10, v2, v6
	WORD $0x6e27dc6b  \  // fmul.4s v11, v3, v7
	WORD $0x4e29d50c  \  // fadd.4s v12, v8, v9
	WORD $0x4e2ad56d  \  // fadd.4s v13, v11, v10
	WORD $0x4e2cd5ae     // fadd.4s v14, v13, v12

2. Mat4MultiplyVec4

// func Mat4MultiplyVec4(a Mat4, b Vec4) Vec4
TEXT   ·Mat4MultiplyVec4(SB),NOSPLIT,$0-96
	FMOVQ a_0+0(FP),   F0
	FMOVQ a_4+16(FP),  F1
	FMOVQ a_8+32(FP),  F2
	FMOVQ a_12+48(FP), F3
	FMOVQ b+64(FP),    F4
	VDUP  V4.S[1],     V5.S4
	VDUP  V4.S[2],     V6.S4
	VDUP  V4.S[3],     V7.S4
	VDUP  V4.S[0],     V4.S4
	MULSUM4ROWS()
	FMOVQ F14,         ret+80(FP)
	RET

3. Vec4MultiplyMat4

// func Vec4MultiplyMat4(v Vec4, m Mat4) Vec4
TEXT   ·Vec4MultiplyMat4(SB),NOSPLIT,$0-96
	FMOVQ m_0+16(FP), F0
	FMOVQ m_4+32(FP), F1
	FMOVQ m_8+48(FP), F2
	FMOVQ m_12+64(FP), F3
	FMOVQ v+0(FP), F4

	WORD $0x6e24dc05          // fmul.4s v5, v0, v4
	WORD $0x6e24dc26          // fmul.4s v6, v1, v4
	WORD $0x6e24dc47          // fmul.4s v7, v2, v4
	WORD $0x6e24dc68          // fmul.4s v8, v3, v4

	WORD $0x6e25d4a9          // faddp.4s v9, v5, v5
	WORD $0x7e30d920          // faddp.2s s0, v9

	WORD $0x6e26d4ca          // faddp.4s v10, v6, v6
	WORD $0x7e30d941          // faddp.2s s1, v10

	WORD $0x6e27d4eb          // faddp.4s v11, v7, v7
	WORD $0x7e30d962          // faddp.2s s2, v11

	WORD $0x6e28d50c          // faddp.4s v12, v8, v8
	WORD $0x7e30d983          // faddp.2s s3, v12

	FMOVS F0, ret_0+80(FP)
	FMOVS F1, ret_1+84(FP)
	FMOVS F2, ret_2+88(FP)
	FMOVS F3, ret_3+92(FP)
	RET

Results and fallback

For platforms other that don't support SIMD, or that we've not yet written the assembly for, the compiler will fall back to the traditional Go variants of the matrix math (found in src/matrix/matrix.none.go). Contributors can feel free to write the SIMD assembly code for other platforms as needed, just follow the pattern already set for AMD64 and ARM64.

Credits:
- AMD64 assembly authored by Brent Farris
- ARM64 assembly authored by rhawrami

Working with VFX in Kaiju Engine

Introduction

In this post we'll explore the architecture of the VFX system, dive into the key data structures (Particle, Emitter, and ParticleSystem), and show how to edit emitters using the built‑in editor UI.

VFX Architecture Overview

1. Particle - a lightweight struct that stores transform, velocity, opacity and lifespan.
2. Emitter - owns a list of particles, spawns them according to a configuration, and updates them each frame.
3. ParticleSystem - aggregates one or more emitters and provides a single interface for the renderer.

Relevant source files include:

- src/rendering/vfx/particle.go - defines the Particle type and its update logic.
- src/rendering/vfx/emitter.go - implements spawning, path functions, and per‑particle data.
- src/rendering/vfx/emitter_path_funcs.go - registers built‑in path functions (e.g., Circle).
- src/editor/editor_workspace/vfx_workspace/vfx_workspace.go - UI glue that lets you edit emitters in the editor.

Particle Structure

type particleTransformation struct {
    Position matrix.Vec3
    Rotation matrix.Vec3 // TODO:  This can be 1D for billboarded particle
    Scale    matrix.Vec3 // TODO:  This can be 2D for billboarded particle
}

type Particle struct {
    Transform       particleTransformation
    Velocity        particleTransformation
    OpacityVelocity float32
    LifeSpan        float32
}

func (p *Particle) update(deltaTime float64) {
    p.LifeSpan -= float32(deltaTime)
    t := &p.Transform
    v := &p.Velocity
    t.Position.AddAssign(v.Position.Scale(matrix.Float(deltaTime)))
    t.Rotation.AddAssign(v.Rotation.Scale(matrix.Float(deltaTime)))
    t.Scale.AddAssign(v.Scale.Scale(matrix.Float(deltaTime)))
}

Emitters

Key fields in EmitterConfig:

type EmitterConfig struct {
    Texture          content_id.Texture
    SpawnRate        float64
    ParticleLifeSpan float32
    LifeSpan         float64
    Offset           matrix.Vec3
    DirectionMin     matrix.Vec3
    DirectionMax     matrix.Vec3
    VelocityMinMax   matrix.Vec2
    OpacityMinMax    matrix.Vec2
    Color            matrix.Color
    PathFuncName     string `options:"PathFuncName"`
    PathFunc         func(t float64) matrix.Vec3 `visible:"hidden"`
    PathFuncOffset   float64
    PathFuncScale    float32
    PathFuncSpeed    float32
    FadeOutOverLife  bool
    Burst            bool
    Repeat           bool
}

Path Functions

func init() {
    RegisterPathFunc("None", nil)
    RegisterPathFunc("Circle", pathFuncCircle)
}

func pathFuncCircle(t float64) matrix.Vec3 {
    // Normalise t to the range [0,1]
    for t < 0 { t += 1 }
    for t > 1 { t -= 1 }
    angle := matrix.Float(2  math.Pi  t)
    var pos matrix.Vec3
    pos.SetX(matrix.Cos(angle))
    pos.SetZ(matrix.Sin(angle))
    return pos
}

Editing VFX in the Editor

- Left panel - list of emitters, system name, and add/save buttons.
- Right panel - per-emitter data bindings (texture, color, direction, etc.).

VFX Workspace UI

Adding a New Emitter

w.addEmitter(vfx.EmitterConfig{
    Texture:          "smoke.png",
    SpawnRate:        0.05,
    ParticleLifeSpan: 2,
    Color:            matrix.ColorWhite(),
    DirectionMin:     matrix.NewVec3(-0.3, 1, -0.3),
    DirectionMax:     matrix.NewVec3(0.3, 1, 0.3),
    VelocityMinMax:   matrix.Vec2One().Scale(1),
    OpacityMinMax:    matrix.NewVec2(0.3, 1.0),
    FadeOutOverLife:  true,
    PathFuncScale:    1,
    PathFuncSpeed:    1,
})

Still a work in progress

Known limitations

Planned improvements

Contributing

1. Implement the function in src/rendering/vfx/emitter_path_funcs.go following the pathFuncCircle example.
2. Register it with RegisterPathFunc("MyPath", myPathFunc) inside the same file.
3. Submit a pull request with tests that verify the function's output range.

If you encounter bugs or have ideas for new emitter features, open an issue on the repository or join the discussion in Discord.

A Sony conference changed my perspective

In my last post I was investigating an idea for an isometric 2.5D game inspired by final fantasy tactics. However, since then, I went to a private Sony conference and was honestly bothered seeing a bunch of people who probably never played a game in their life talking about publishing, developing, and the business of video games; and honestly it struck a nerve with me.

The Sony conference

Of course these big companies have a lawful requirement to do whatever they can for shareholders, but they also have to make money to keep alive. It's not such a crazy idea, I know many indie developers are making games to either make a "hit" game to make a lot of money, or are making indie games so that they can make it their day job and stop working for someone else. So, indie or AAA, it seems to be a lot about the money, and very little about the games themselves.

Indies? Hustler culture?

So many indie developers are spending so much time creating games in hopes that it'll "pop off". I can't even begin to count how many instances of indie developers I've ran into who have a "great idea" (meaning money) rather than a "fun idea". It feels like the same hustle culture that I felt at the Sony conference. And... The worst part of the whole thing is that I fell into the same trap as everyone else.

Going back to "the good old days"

I have always just done what I want to do, and that's why I have so many dead projects. I find one thing I'm interested in and then try to make some big ol' game idea based off that. Then I do the stuff I want to do and abandon the project. What I need to do is what I used to always do, which was find a very small scoped game I want to make, then make it for the fun of it and not even care if I sell it or make any "return". There is no return that I want other than to do the work to make the game. I thoroughly adore "the process" and not the goal, so when my view shifts to "the goal", I completely lose interest.

More than just mere words

The game I've been working on for the last 2 weeks is a multiplayer Sudoku game. The game will use PBR rendering, and network code I developed just for the game. I've also developed a master server registry so that players can find each other and utilize UDP NAT hole punching. The primary gameplay loop is playing sudoku, getting a token for playing easy/medium/hard/multiplayer, and unlocking name tags and special player cursors (which show in multiplayer).

I can have a more formal development log for the Sudoku game specifically in another post, but that's basically just me "putting my money where my mouth is" as it relates to these things I've been feeling since that Sony conference.

Where do we go from here?

Designing an isometric 2.5D game like Final Fantasy Tactics Advance

One of my favorite game consoles was the Game Boy Advance, particularly the SP version because it had a light-up screen and you could fold it to fit in your pocket. However, I find that I'm enjoying the old form GBA now days, mainly due to being able to mod it to have a back-lit screen, and it's more comfortable to play with.

modded back-lit screen game boy advance, with final fantasy tactics advance

One of my favorite games on the GBA was Final Fantasy Tactics Advance, when I was a kid I picked it up because I liked the artwork on the box. Recently, I've been playing the game anytime I have some down-time and, other than being fun, it has got me thinking about developing a game. Playing through it I started to think about how cool it would be to create a game with that isometric style including using pixel art characters and animations.

Isometric, without tactics

final fantasy tactics advance tile layout

It would also be interesting to see if I could get the world to dynamically load in as you move around, this way there would be no loading screens in the overworld. If I dynamically load the interior of buildings as they are loaded into view, it might also be possible to teleport the player to the building interior instantly upon entering the building door.

The last part of this is that I want to make the world 3D, but the characters and props are going to be 2D sprites. This will make the physical movement around a bit easier, and it will make it easier to place objects within the world. This might give it a bit of a Ragnarok Online feel, though I don't really have an intent to orbit the camera around, it'll likely be fixed but can zoom in/out. Ragnarok didn't have this tactics style isometric floor, but it did have the 2.5D artwork (see below example).

ragnark online gameplay

Gameplay

Game Engine

Getting started with tiles

Mesh* m = isoland_create_cube(host, IsolandConstructCube{
	.height = i+1,     // Copied from a loop, thus the 'i'
	.tilesetWidth = 4, // Tiles in the tileset image
	.tilesetHeight = 4,
	.sideTileX = 0,    // Side tile image in tileset
	.sideTileY = 0,
	.topTileX = 0,     // Top tile image in tileset
	.topTileY = 0,
});

first test of floor tile code

Resolution and camera

Example of 320x240:
example of rendering at 320x240

Example of 720x480:
example of rendering at 720x480

Example of full resolution:
example of rendering at full resolution

For the camera, I'm likely going to be rendering in perspective, but with a lower FOV (field of view) to get a somewhat orthographic look without actually using an orthographic camera. I'm not entirely fond of a fully orthographic camera for rendering just because I think some perspective gives it a little more life/character than no perspective at all. As stated previously though, I'm not likely going to allow for the camera to orbit, but I will likely let it zoom in/out a bit for cinematic effect.

What to work on next

Placing buildings and props should be as easy as specifying their location in the world, the height should be automatically picked up from the heightmap data. This will require a standardization of assets, all of the pivot points of each asset must be at it's base so that it will snap to the floor correctly. However, I will need to also provide the ability to offset from the floor, in case the prop is on top of something or floating in the air for effect.

Timeline and goals

As for my goals, it really is just to make a game in my game engine. Retro Sketch's goal was to create some software I can actually use to create games, but also to fully test out my bespoke UI system idea in the engine. Since that was pretty successful, I'd like to use this game as a way of proving out the ability to create games without much friction from the engine. I'm not typically focused much on money/return on the things I create, though nice, it's not exactly my primary goal for creating things.

Addressing the hiatus

Hello everyone! It’s been a little while since we’ve had any updates on the blog, Retro Sketch, or the game engine I’ve been wrestling with. But fear not! I’m getting back into the swing of things, and thought it would be a great opportunity to share what’s been happening.

Life, as it often does, threw a few curveballs recently, which pulled me away from engine development. You know how it is – other exciting projects pop up, demanding your attention! Thankfully, I’ve tackled those life events and distractions, and I’m now laser-focused on games and the engine.

My next step is to start working on another game in the game engine. That means I probably won’t be pushing out updates to Retro Sketch unless a bug pops up, or I need it for a feature while I’ve been developing my game. Don’t worry though – I use Retro Sketch myself for my pixel art, so there will almost certainly be updates related to that!

Of course, diving back into code after a few months can be…interesting. Turns out nothing was compiling or running! I spent the last couple of days wrestling with the engine just to get it building and running again. The good news? The address sanitizer is now fixed and working! That was pretty annoying to be without for a while. Another cool feature I’ve been experimenting with is time travel debugging – a fantastic tool built into Windows when you install WinDbg. With all my cool tools back online, it’s finally time to start developing that new game!

I’ve been making games for over 15 years, and have published quite a few… though not under the “Game Goat” moniker. Previously, I ran a studio called Bearded Man Studios. But that chapter has passed, and most of the amazing people who worked with me have moved on. Those games have faded into obscurity, and they’re sadly built on older versions of Unity, making a resurrection quite the challenge. If I find the time and the desire, I might resurrect them in the new engine someday. But my focus right now is on creating something brand new.

Once I have something genuinely fun and interesting to share, I’ll be posting it here on the blog. For now, I’m overflowing with ideas – but, ideas are cheap. I’m starting to test out some of these concepts, probably sticking with pixel art for the near future. The game engine itself is a 3D engine, and it plays very well with Vulkan. However, creating 3D art and all the assets that go with it takes a lot of time and energy, especially when you’re a bit of a perfectionist (like me!). I want to make simple, fun games, and the easiest way to do that is to embrace some constraints.

Although I am completely comfortable working in 3D and working with 3D game engines, animation rigging, texturing high-poly models, re-topologizing, sculpting and the rest of things that come with 3D. Right now, it just isn’t something I can realistically focus on. Feel free to stay tuned for what I’m working on next.

Community game development topic rules

You are free to share the games you are working on. There are a few rules to your games though

1. Explicitly sexual content is not allowed
2. Content that can be considerered a fetish is not allowed
3. Don't spam your games, re-use threads for iterations
4. Be nice to other's games, critique's are fine

General Forum Rules

Updated forums formatting, categories, embeddings, and more

We've added a lot of new updates to the forums so that posts can be formatted in more interesting ways. Tables were added so that guide threads are easier to both explain things and read things. We've added embedding of Imgur, Odysee, and YouTube links for more media interactivity as well. You can also select a category for your thread so readers know what they're getting into before clicking. You also can now click on an account image/name to view that person's profile and their latest posts.

List of additions

Kaiju Engine topic rules

You are free to chat about anything related to the Kaiju game engine, our in-house, open source game engine. Talk about your games/applications, show progress, ask for help, or help others. Before you post or reply, there are some rules that must be followed:

1. Don't post anything related to adult content
2. Don't create multiple threads about your game, a single thread will do
3. Don't spam about your game, use your game's thread to talk about it
4. Stay on topic with the thread, don't veer off on unrelated subjects
5. Test code you are about to suggest or clearly explain that it is pseudo-code

General Forum Rules