​​​2018    |    seemingly unrelated experiments

orrb has its origins in a small experiment in achieving aesthetics within an interfaceable simulation, could you achieve the feeling of a satisfying button click or object placement ?.

This resulted in experiments mainly in UI design and implementation.
 

​

2021 > 2022    |    indie dev year one

Fast forward three years and I had left my job working within the educational software industry, with a couple ideas on how software could be architected for better production of a project.

​

These ideas were all well and good but ultimately, unproven, and so I needed a project to justify trying them out, a very simple game of which I could use to experiment, and so, orrb was born!

(well 'laser' as a working title, as the game initially was about placing tiles to redirect lasers)

​

One year of self funded indie development passed. The structure of the game was roughly established:

• tiles

  • tile based placement within openings in a level, with tiles that affect the sphere in different ways such as, direction, splitting, combining, as well as tiles that affect other tiles resulting in rotations, activations, pop up/down, etc​

• turn based nature

  • with setup mode for placing tiles, then playback mode to see the laser path

• laser becomes a sphere

  • the idea of the laser was dropped after putting debug visuals in to display the pre-computed path of the laser with a sphere

    • this would afford more design space with the tiles as things where not just setup & playback, but now reactive during the playback, with tiles reacting to how the sphere is traveling through the level​

• level data

  • generic grid base in a single scene (entire game is in a single Unity scene), where level is just thrown at level loading logic which act in a way familiar to people that have done procedural generation. I consider the level data to be a very tight discrete procedure that I pass to the generator :)

  • added small parts of level dressing data to what would become the overall level  data, which initially was only the grid & tile data for the respective level.

• level structure​​

  • initial sphere start & end points in a level were placeable in early prototypes, then static but level specific, ultimately becoming standardise with levels so that they occupied the same screen position on the Y-axis of the screen.​​

• camera/perspective​

  • 3D 'static' camera at an elevated view looking down towards the ground, allowing for some kind of depths but keeping things simple and readable​

  • 'static' while in level but animated during level transition to move off left or right and allow for level loading to occur off screen

• level select/navigation

  • I didn't like the aesthetic of a level select UI menu screen with 1 -> 100 level buttons that you keep going back to after level complete, or some transition. This drove me towards a more embedded approach where levels are available 'in-game' via a HUD with levels appearing to be in the same environment and navigation between them being simple and fast with minimal 'thresholds' to pass through.​

    • This dislike of a potential level select screen ended up defining major aspects of the overall game design, way more than I would have suspected.​

      • this allowed for the generation of ideas relative to level playback chaining and ultimately that the game could technically be setup to be completed by a player before the firing the first sphere. resulting in the entire game being in playback mode for tens of minutes while the player watches the sphere travel through all the levels​ setup beforehand.

​​​​​​​​​​

​

2022 > 2024    |    first run in the games industry

Spent two years working in the games industry as a:

• Tools Programmer

• 'Commander'

  • of the studios internal codebases for 'Commander' & 'Validator'

• Source Control Whisperer

• Tools Supportist

• "Why the ever-loving f--k is Unreal engine not building?" Fast Response Unit

• DevOps-ish

• Build-Release-Patch helper person thing...

with the wonderful people at Ballistic Moon who were working on the Until Dawn Remake with Sony Entertainment.
Minimal production work with 'laser' happened during this time period, mainly just thinking about design and what the structure of the gameplay progression could be.

​​​

​

2025 > 2026    |    indie dev year two : electric boogaloo

With Until Dawn Remake released and Patch/Maintenance work completed, I said farewell to Ballistic Moon and dived back into self-funded indie development with the newly named orrb.

The main focus was building out the entire level progression start to finish, focusing in on puzzle design, and making the levels a nicer place to be with level dressing, etc.

 

to be continued...​​​

20260819:: Currently tuning a demo for Steam's NextFest, planning for release to Steam, and porting to Xbox Consoles, shall return to this wall of text at a later date :)