go back

introducing synapsium: an abstract, node-based puzzle game prototype

16 December 2025

video showcase

introduction

in some ways, it’s quite tempting to keep a personal project away from the internet. you keep it hidden such that you can work on it until you feel satisfied enough with your progress to share it with others. however, it’s quite lonely working on something in isolation. even if no one engages with my work, i enjoy entertaining the illusion of sharing it with an audience. it’s motivating.

so, here it is.

synapsium is the game that i’ve been building over the past month and a half. i came up with the idea for this game a few months ago when building takaku, which is also a node-based game. it’s not demo-ready and lacking many of the features that i’d like it to have, but i think that there’s enough substance present to at least communicate the game’s general vibe.

the basic idea

synapsium is a puzzle game. each level consists of a puzzle that you must solve to progress onto the next.

the objects in the game that comprise the puzzles are called nodes. these nodes live in slots on a grid and can be moved between these different slots, much like a go board.

in the embedded video, you’ll see a few different examples of these nodes (e.g. smiley face, unhappy face, and lightbulb).

i’ll talk about what these different nodes do in a moment, but for the time being all you need to know is that the happy/unhappy nodes essentially function as batteries and emit particles (you can see these particles moving around the network in the video, visualised as hearts).

much like in a graph, nodes can be connected to other nodes. in the video, you’ll see these connections visualised as coloured lines when hovering over a node. the colour of the line represents which node is the source of the connection. the other node involved is the target of the connection. that is, the underlying graph is a directed graph (digraph).

connecting nodes together allows the particles to flow through the network by moving between the nodes.

to complete a level, all of the lightbulb nodes must be lit up (i.e. by receiving a particle) by forming suitable connections.

that’s essentially the gist of the game.

emitter nodes

the unhappy/happy face nodes are called emitter nodes. these are the nodes that produce the particles (hearts) that flow through the network.

all particles have a binary state. in real life, this binary state is called a particle’s charge (+/-). in the game, positively charged particles are visualised by a heart whereas negatively charged particles are visualised by an upside-down heart (anti-heart). the happy face nodes emit hearts and the unhappy face nodes emit anti-hearts.

emitter nodes can only be the source of a connection, but never the target. from the video, you’ll notice that all emitter nodes have the number 0 written to their left. this number represents how many nodes can connect into it (i.e. how many connections it can receive).

when an emitter node is connected to another node, it will begin sending particles towards it. when these particles arrive at the target node, they will be “processed” (in some manner) then either sent back to the emitter (if the target isn’t connected to anything else) or continue to flow through the network.

bulb nodes

lighting up bulbs is how you complete a level in synapsium.

there are two types of bulb: regular bulbs and anti-bulbs. to light up a regular bulb, it must receive a positively charged particle, whereas an anti-bulb requires a negatively charged particle.

bulbs can receive connections, but they cannot connect into another node. you’ll notice in the video that each bulb has a 0 to the right of it, symbolising that it can connect to at most 0 other nodes.

inverter nodes

the inverter node is the purplish node with the arrows on it shown later in the video. the sole purpose of this node is to invert particles that arrive at it. that is, it can turn a negatively charged particle into a positively charged one, and vice-versa.

so, it’s essentially just a not-gate.

what’s next?

here’s the current code for creating the first level:

  // creating the level object and giving it a name
  auto first = std::make_shared<level>("first");

  // creating the objects in the level
  auto grid    = init_lattice<3, 3>();
  auto emitter = std::make_shared<nodes::emitter>(grid, std::make_pair(1, 0), 1, true);
  auto bulb    = std::make_shared<nodes::bulb>(grid, std::make_pair(1, 2), false);

  // adding the objects to the newly created level
  first->add_scene_objects( {grid, emitter, bulb} );

  // adding the level to the level manager
  level_manager::add_level( first );

as you can see, it’s functional, but quite annoying. moreover, if i were to say create a new level and share it, then i’d have to recompile the entire game and distribute the new executable. this is not ideal.

i’d like to create a smarter system for creating/loading levels that doesn’t require me to code an entire in-game level editor. this will both solve the recompilation issue and also allow for other people to create their own levels, which i think is quite fun.

on a different note, i obviously want to experiment with adding new node types to allow for more interesting levels to be created, but my current node class hierarchy makes this not too difficult, so i’m not terribly concerned about this. the only technical issue that needs solving is how to handle nodes that require 2 or more particles to arrive before they can “process” them.

for example, a binary or-gate requires two particles to arrive and should output a positively charged particle if at least one of the arrived particles is positively charged, otherwise it should produce a negatively charged particle.

closing remarks

moving forward, i’ll continue to post updates about the game’s progress on this blog.

if you want to stay-up-date with the game’s development (or just fancy a chat), i’ve made a discord server that you can join if you so wish.

until next time, peace and love.