What is it?
A Journey of Light is a collaborative project that I have been co-lead and lead programmer of since late March 2025, with us wrapping it up as a technical demo/game concept, with it last major update soon (late February/early March). The game itself is a light-based puzzle game where the goal is to guide the light from the spotlight to a lightless orb(s), using different objects to redirect, modify or split that light along the way.
The Breakdown
As one of the leads and the principal programmer, I had a major hand in a lot of the functionality and design direction of the game. Here are some of primary areas of contribution with some brief details:
Broad project structure
- This includes basic navigation logic between main menu→game across menus and end of puzzle playlist logic.
- The internal map structure, using streamable levels to hot-swap environments suited to the puzzle size, and extendable to allow varied mixtures of environmental biomes based on the puzzle playlist (I put the structure in place, and the art crew worked on those levels).
- Managing and adding to all the core GameMode related types (namely GameInst/HUD(s)/Pawn(s)).
- Most of the structs, enums, and utilities used around the project in contributions and others (including some C++ defined ones for use in custom logic).
Puzzle objects
- Design, implementation and maintenance of puzzle object parent class, derived game objects and their gameplay implementations (essentially all the inner workings minus visual flourishes and associated logic).
- Broad input on game object choices (group effort really).
Levels
- Design and implementation for level and playlist tables (used by designer for individual level creation and strings of connected levels for play).
- Design, implementation and maintenance for level manager (aka arena manager/AM), primary driver for building levels based on target playlist table and appropriate level from that, and communicating state of objects (like orb completion status) back to the player pawn.
Pawn(s)/In-game cursor
- Design, implementation and maintenance of most of the Pawn-to-Cursor-to-AM interactions (basically all the logic involving in moving, object detection, interacting, picking up, manipulating, invalid action detection etc).
- Design, implementation and maintenance for level manager (aka arena manager/AM), primary driver for building levels based on target playlist table and appropriate level from that, and communicating state of objects (like orb completion status) back to the player pawn.
Self-reflection
This was my first major unreal project (that wasn’t an early university project), so there was quite a learning curve to be able to appropriately pull my weight for the team. A significant part of that curve was figuring out what unreal had available for use off the bat, and how I could apply what I knew and what I had to relearn to use unreal better. Things like what nodes and calls were available, native types and utilities, visibility of objects and macro libraries are some of the things that come to mind; building an understanding of what things existed, where I could save time in not trying to reinvent the wheel, and if you needed to build a new wheel, where you could place them.
Besides the nagging feeling for refactoring (needed or not 🙂 ), some of the biggest things I would want to improve on for next projects (or if revisiting for taking it further) would be around the inputs/control setup in terms of utilising different IMCs over enum→switch context checking (if more appropriate to do so), better and more consistent use of data tables more consistently throughout, and improve some general structure of the project. Expanding on that last point, I think the level manager (or arena manager), which is primarily responsible for building the puzzles on demand, started doing a little too much when the inventory system was introduced. Whilst the inventory systems functionality is largely separate logic wise, having a cleaner division in the form of sub-managers may have been better structurally.
I would have also liked to have done more C++ for the project as well. I did get some learning and practice in the types and syntax used in unreal C++, but balancing for time, learning, what can be done quicker in blueprints, and keeping on track with our timeline left little wiggle room to explore as much as I would have liked. This is something I want to allocate more time for in future projects so I can more confidently apply tailored solutions and optimisations on demand, shifting away from the majority blueprint coding I have been doing into something better suited to my core strengths.
As for next steps, a level editor would been the immediate next goal. This would bring the level design into the game itself to both help the designer(s) and have a good feature for players to enjoy. My initial approach for this would have been to base the level files in JSON, moving away from the data tables, and then looking into how to make those shareable in the best way possible (likely by looking into shareable codes via serialisation).
Benjamin Kimberley 