Development Blog

Toroban: Update #46

Wed, 04 May 2022 23:00:00 +0000

Updates have moved to discord & twitter!

Updates

Please see the Toroban website for links to social media. I’ve been using discord as a dev-log and twitter for more polished updates. Check out the roadmap on discord for the most up-to-date future plans and progress!

Toroban: Update #45

Wed, 30 Jun 2021 22:00:00 +0000

Overworld and more!

Updates

PicoES 1.0.0 (stable)

There were many PicoES releases since the last post about alpha1. It’s now finally stable - the performance is much better and the syntax is cleaner and more consistent.

Pack

Simple, multi-threaded texture packer in Go. Made this along with various improvements to other build steps to improve my iteration speed down to milliseconds.

Overworld

This is a part of the tutorial area:

There’s many more levels not shown here, such as bonus areas and the beginning area that comes after the tutorial. I am still designing new levels to explore the mechanics more deeply. The later levels will combine the mechanics and introduce even more interesting cases. There’s been more tweaks to logic and graphics since the previous demo.

Steam Release

The last free demo was demo 3. The current version is demo 4, which has the overworld. Demo 4 will be available only on Steam - in some kind of early-access or private beta. I plan on releasing an updated free demo version on Steam in addition to the final main game, which will have the tutorial area and maybe some extra levels to show off more mechanics. I’ll post an update when more things go public.

Toroban: Update #44

Sat, 17 Oct 2020 23:00:00 +0000

Finalizing the game design. Plus PicoES 1.0.0 released!

Updates

PicoES 1.0.0

I released a new version of PicoES here. You can see the published npm package as well. At the time of this post, it’s still in alpha. It’s already been integrated into Toroban and is working correctly. Iteration performance has improved with the new world.each() syntax, and systems have been simplified and include automatic dependency injection with world.context().

Toroban updates

Toroban design

Many demo versions were iterated on since the last post. The latest findings from all the feedback was to really nail down the intuitiveness of the game mechanics and visual representation. There were certain behaviors in previous versions that I chose arbitrarily to try and “force” more advanced puzzles, but that’s a really bad idea. It’s much better to just choose a clear representation of something, and only design the logic that would make sense in real life, or at least intuitively in the game. If that logic is too weak, then change the actual objects to be something that produces stronger, deeper logic.

With that said, I’ve made an official GDD, which is super up-to-date, and will eventually contain the final game design. This is a big upgrade from my random notes documents before. This document is getting close enough to completion, to allow working on implementation again.

I’m planning on including some updated variants of good mechanics from previous versions of the game. Most of the logic will be simple and straightforward now, with complexity spread out into more objects instead of compressing the complexity into less. I won’t say much here for now, because the design isn’t 100% final, so you’ll have to wait till the next demo to see what will be included.

No more rule blocks

Rule blocks are being removed. There are many reasons for this.

There’s already a wildly popular game that fully embraces the idea of dynamic rules. In Toroban, the color-based rule blocks only partially explores a similar idea.
By combining the color states with the rules, it limits having simpler color sub-puzzles within more complex levels that make use of rule blocks, because they are too dependent. You can’t change the time travel state of an object without also changing the color, and therefore which areas its allowed to go. There was no benefit of merging the states, other than slightly simpler visual representation, but hidden behind that was complex logic.
Almost every good level required the use of multiple rule blocks, and potentially more unintroduced rule blocks, to hack certain things in to make stuff work in a certain way. This would confuse players even more, by just seeing the existence of weird looking blocks, and noticing that things work differently.

Portal blocks

This is an exciting new addition. A colored block with a portal on one edge. If there’s two of the same color, then objects and lasers can seamlessly pass through these blocks, through the edges. Depending on the direction of the blocks, objects and lasers can change direction when passing through. If there’s three or more, then optional duplication starts to occur. This complements the toroidal world well, and means that world rotation and offset doesn’t have to be completed for things to be offset or rotated.

Toroban: Update #43

Wed, 25 Mar 2020 20:00:00 +0000

Implemented color-component rules, generic rule system, and time blocks!

Updates

Black/null color

Black color can now be used as a beam and works similar to the other colors. When mixed with any color, the resulting color is black - so this works like an override. There is the concept of a “null” color value, which is either represented as black by default, or just simply no color/light. The concepts are sort of merged into one, so there are still only a total of 8 colors.

black + anything = black
null + anything = anything

Color-component rules

Colors are now mostly treated as the existence of their sub-components: Red, green, and blue. This makes colors more interesting, but with a slight cost of having 3 mixed states instead of 8 unique states. It could be more limiting for more complicated levels, and could be initially less intuitive to the player, but it’s something I’m trying out for now. This concept can be slowly introduced by starting with base components, then later adding intermediate colors that show how they contain 2 base colors.

Color areas

Color areas now have filtering capabilities due to this. They work similarly for both light and base colors of objects. The cases that the full light color is allowed through, are the same cases where base color objects are allowed through - you can’t split an object into separate objects this way (yet). Here are examples of all the important cases of color-component based light filtering:

Control blocks

Example with a control block:

Wall blocks

Example with wall blocks - note the base goal block color must still exactly match the light color for it to have an effect:

Generic rule system

Wrote a generic library/system to handle all the color component matching logic with entities, and to be able to easily apply rules to them. This helps keep the logic working in a consistent way that should make the game more intuitive as well.

The older wall blocks and control blocks have not been updated to use this new system, because they do not necessarily change rules. But, it might make sense to change the game’s design to allow for this, so that they are rule blocks instead. The control blocks have very similar logic already, but have the extra “>= 1 alive” condition. It would make sense if the players turn to ghosts when dying, that you’d still be able to control them and they would just have limited interactions/capabilities. Just by removing that one arbitrary rule and updating the theme, that logic can now match how everything else works and lots of extra code can be deleted and replaced with 1 line of code to register the rule.

Time block

Added the time block as the first official block to use the generic rule system. This pauses entities that match the light color(s) of all time blocks. This level is interesting, because you have to kill one of the players to solve it (since having 2 locked are in the way), and use time travel to make the “shape” of players match the color areas. Since the player death state control logic isn’t finalized yet, I don’t want to post an actual recording yet. In the next post - when the player logic is updated - I will show a recording. Here’s a screenshot of the working time block level:

Void world

Resurrected the old offset code, and added a temp XY offset block for testing. Eventually, I will add an official offset rule block, that works just like the time block. Fixed a few minor rendering bugs, and added a gray background to indicate the void areas as a placeholder:

There is actually a 2nd way to expose the void world as well:

I’m planning on some way to have usable level space instead of an empty area. Maybe the alternate level can be “anchored” on one edge of the level, and exposing it in different ways will let you access different parts of it. There is still a lot to do with the offsets: the camera isn’t working correctly, the change in offsets is not animated smoothly, and the void spaces are not yet usable. I’ll be working on this, along with improving the theme, player mechanics, and making existing mechanics more consistent with each other.

Toroban: Update #42

Sat, 14 Mar 2020 12:00:00 +0000

Implemented water/sand, animation engine, new locked player clones, animated overlay, control blocks, smooth camera, discovered new mechanics, and more!

Updates

Smooth water and sand

While this works similar to wall rendering, this steps it up a notch by working with diagonals to support large areas of sand and water. Using the old approach for walls, would result in needing 256 full sized sprites. I did some manual deduplication, using 1/4 sized sprites, so that only 18 sprites were needed, plus the 2 for full sand and full water.

The color palettes for the entire game still need work, as well as basically all the sprites. Placeholders are good for now so that I can make sure the logic will work with final sprites in the future.

Animation engine

Added an animation engine to be able to easily play animations in forward & reverse. Animations contain frame metadata, and can be consumed by render methods.

Locked player clones

Implemented new player logic, related to control blocks and overlays below. Now, when there are multiple players, they are moved as a locked group, so if one collides, they all collide.

Animated overlay

Players now show an overlay to indicate they are currently controlled. This gif shows the checkerboard pattern for overlay animation direction. It seemed kinda dizzying to have them all turn in the same direction, so this keeps things changed up as you move around.

Control blocks

Demo of new control block mechanic!

Camera

Spent a lot of time trying different approaches to have a smooth moving camera that automatically centers on controlled entities. It’s mostly done, but the part that re-calculates could do a better job finding a more appropriate center.

Improved automatic build system, added player exits, added color areas. Color areas only block physical objects currently, but interactions with light are planned as well.

Logic

Rule blocks

Instead of hard-coding one rule per RGB bit, there can be separate rule blocks, that work similar to goal blocks and control blocks. For example, if a time block is hit with red light, then all entities with the red bit, will be immune to time travel. The old hard-coded system can be easily replicated by setting up a rule block for each RGB bit, on top of a red, green, and blue laser.

There will be the following rule blocks:

Wall - renamed from “goal”
- Changes up/down state of walls
Control
- Sets which players are controlled
Time
- Pauses matched entities
Offset
- Enables matching entities to control world offset by relative movements
Pull
- Matched entities will no longer be able to push, and can pull

All of these will work the same with how they interact with colors, see below.

Color systems

8-color (3-bit) vs 10-color (3-bit + null + all)

Went back and forth on some different color systems like this one:

Decided on using the simplest 3-bit, 3-component system, with 8 output colors:

All the block types will be consistent in using components specifically, instead of unique colors. Example: White is actually just red, green, and blue all at the same time.

Toroban: Update #41

Sun, 23 Feb 2020 21:00:00 +0000

Plans for polishing and finalization of game logic.

Updates

Missed many past updates, I’ll try my best to continue to post, but no guarantees if it will continue weekly or monthly.

Polishing

While starting to work on polishing the game, I realized that there were some fundamental issues like having many different internal states that had to be visualized. This all leads into simplifying rules, making gameplay more intuitive, making art as minimal as possible, but all without decreasing difficulty.

Started working on an easy way to animate things.

Game Logic Changes

All these different iterations and versions of the game I keep making, are to find unique mechanics that are simple to understand, but allow for new, challenging puzzles. The last version with the “snake” player, was definitely more challenging for players than the one with life points. However, the merging rules were not intuitive and too complex for players to fully understand by simply playing the game. If I just remove the merging rules, then the snake mechanic feels like something arbitrarily thrown in, with very weak puzzle emergence. It’s still better than life points overall, but has a lot of complexity with little difficulty improvements.

Going back to the drawing board, we can pull in a bit of DNA from almost every version of Project Square and Toroban, but this time sticking to the idea of a design that can be polished and minimal.

Great Mechanics Discovered

These are ideas that have the potential for making great mechanics, discovered from previous versions. There are different reasons why they didn’t work before, but I have solutions for all of them and are planning to integrate them all with the next version:

Toroidal world
- Obviously keeping this, and now making it even better - see below
- Solves screen scaling issues, what to show for background, and adds some interesting puzzle elements
Time travel
- Playing/paused states + allowing these to be changed during the level
- Timeline concepts of branching, and going backwards/forwards in time
- Visual display of time states doesn’t allow for clean design
RGB
- Having so many objects with RGB states and the color mixing concepts are great
- There are 8 different states for minimal benefit, other than forcing mixing concepts
World offsets
- This one was an amazing way to interact with the toroidal world
- No known way to animate due to confusing wrapping math, along with disparities between logic and rendering code
- Void areas were empty and unusable, introduces new background problem that toroidal world was supposed to solve
Player rules
- Cloning
  - Having multiple player entities can make interesting puzzles, given more constraints/interaction rules
- Snake/following
  - Players that follow each other are cool, but see above about merging rules being too complex
- Death state
  - Works well with time travel and other mechanics here
- These variations on their own were interesting, so want them all but need to keep it simple
Water
- This one is an old idea, with a nice, refreshing theme
- Stacking layer mechanic was visually confusing and unacceptable, so this was removed a long time ago, instead of being fixed

Solutions & Conclusion

The prototypes showed me both what was good and bad. I’ve done a lot of brainstorming the past several weeks, and have come up with this:

RGB is now used to display visual states
- Red: Paused
- Green: World offset
- Blue: Pull
Void world level
- Void spaces that are revealed when changing the world offset, can be used as an alternate dimension with completely different objects in that area of the level
- Function to map global (player perspective) coordinates to internal level coordinates - this can be made more robust and reused by rendering code. Animation can be made smooth by queuing up movement animations on output sprites, with source & target mapped positions. Logic should be more understandable by doing everything at the tile-level, instead of the level-level :D. The set of output sprites is now known based on window size.
Animations
- Changing world offset
- Light beams
- Timeline history erasure/restoration
Simple water
- Water will drown all player entities that enter, but all objects and light are allowed to pass through.
Simple player
Control block

I am purposefully hiding details, because all of this is subject to change. I do have most of this figured out and documented. I’ll keep working on all these changes, which should provide a cleaner, more minimal, more challenging, and more intuitive game.

Toroban: Update #40

Sun, 29 Dec 2019 21:00:00 +0000

Implemented player color & time state merging.

Updates

I missed last week’s update, due to a big move and some other reasons. But, 39 weeks in a row is great! I’ll try not to miss anymore updates, but the next few might not be as big.

Player colors now merge with OR logic. Example: A red group merges with a blue group, the resulting group is completely magenta.

Player time states new merge with OR logic. Example: A paused group merges with a non-paused group. The new group is completely paused, with histories automatically erased on entities with state changes.

Fought a lot of strange player-related bugs. Ended up keeping the “follow” system running on every state change. Rewind can cause merging to occur, but at least now everything works consistently and bug-free.

I am trying to fix timeline management issues. These are related to being able to either execute an action onto a new “segment”, or append to the last one. There is a pre-pruning step that may prevent an action index from being added to the timeline, and this causes a confusing state where an action was successfully executed but not added to the timeline - so when the next action appends, it is not known when or how to add to the timeline. A possible fix would be to get rid of the pre-pruning, always add to the timeline once initially, and then have a post-prune step that is similar to requesting a full prune, but would only run on the last element just added. Could have a post-logic system that runs if the normal logic system executed something, to run that final step. This still could have issues with systems appending actions in the future to elements that don’t have a corresponding timeline index. I’ll focus on getting this completely stable this week.

Toroban: Update #39

Sun, 15 Dec 2019 23:30:00 +0000

Fixed complex time travel edge cases with player-follow logic.

Updates

Simplified follow states using only follows/followedBy components - no other component states or differences exist between different player entities, other than current color/time state. Head entities can be easily determined by checking if the “follows” component does not exist.

Added cycle detection algorithms, added cycle prevention checks, and fixed multiple infinite loop bugs.

Fixed position and direction wrapping bugs by wrapping computed positions and directions. Added a new wrapped direction method to the spatial entity map.

Wrote a two-pass algorithm for the “follow” system. The first pass prunes follow connections between player entities, when they become invalid - either detached from the world, or have impossible positions. Entities that follow must be exactly behind, as well as having a direction that is forward, left, or right. The second pass attempts to follow followable entities that are not currently following, using the opposite conditions used to prune. This two-pass approach works cleanly with the four directions of time travel/undo, and allows practically any player creation/destruction states throughout the timeline to stay valid and make intuitive sense to the player.

Implement color and time state merging updates on merged player entity groups. Use simple OR logic that is consistent with the rest of the game. Focus on fixing all remaining bugs and issues. Potentially may start working on a way to solve the camera issue - caused by the fact that there is more than one player entity now.

Toroban: Update #38

Sun, 08 Dec 2019 11:30:00 +0000

Implemented player colors, pause-intersection logic for time areas, and more!

Updates

Added new player sprites, so things look like clones with direction, following each other in chains
- “Head” players have a controls overlay to show potential movement
- These player sprites have color masks to show which initial color the player is
Long player chains on time areas (play & pause) will intersect the overrides to determine what state to override by
- Uses a request system that applies OR logic at the time of each request
Fixed more bugs related to time travel and new player
- Tail being created on top of a time area - fixed with hybrid logic, using an active system for requesting pause state, and an exit event to reset.
- Bugs with created/destroyed entities, caused by isPaused not checking ‘valid’ component as override

Split-Pause-Rewind Bug

Before, the process of splitting a player chain, would select a specific action to use to make the changes necessary for upgrading the following segment to a head entity, destroying the middle one, and updating the other group’s tail. There were different changes applied depending on the scenario and type of segment. Then, when you would pause one of the groups, and rewind, the destroyed entities would come back, headless, and would still be “following” the wrong group.

Now, I am currently working on an active “follow” system to validate, prune, and re-calculate follows/followedBy states for all followable entities. This also handles merging logic, mixing colors and paused states with OR logic, to stay consistent with the rest of the game. It runs on any state change, which includes time travel of different directions, so it should fix the split-pause-rewind bugs and more. I’ll be working on this for next week. After that, the camera positioning algorithm.

Toroban: Update #37

Sun, 01 Dec 2019 20:00:00 +0000

Added pause functionality for the new player. New player color/control block ideas.

Updates

The player with followed entities can now be paused. Fixed more issues with Create/Destroy entity actions.

Player Colors

The player entities can be initialized to a color, set on level creation. This color will be preserved when eating food, splitting, etc.

Color Control Block

This is a new, optional block type, that can dynamically enable/disable movement controls for certain colors of players. Depending on the color of light this block receives, determines which group(s) of players get controlled. This follows a common theme that works similar to goal blocks/color walls/color food. All edge cases should already be worked out:

No control blocks
- All players are controlled
One control block
- Only players of this one color are controlled
Many control blocks
- The common set of current control block colors are controlled
- Example: Blue, Red, Blue blocks - only Red and Blue players are controlled

Merging

Some possible merging rules:

Don’t allow merging of different colors or time immune states
- Fixes many potential issues and keeps things simple and constrained
Allow merging all players
- Mix colors
  - This would be interesting, but should act similar with pause state to “mix” pause bit using OR logic
- Inherit colors from front-most player “head”
  - Consistent with inheriting pause state from player head

At first: Sticking with rule to not allow any different things to merge. Later, once things are stable, I could try adding inheritance or mixing logic, and see which one produces the most interesting levels.

Color Walls

To keep consistent with the colored food constraint, the same constraint can be applied to the player. This would mean there could not exist any segments of a particular color, as well as any food, and any existing goal blocks of that color would have to be solved, for that color wall to be solved. This creates a dynamic where not only do you have to eat all the food, but you also have to kill off any players of that color. Since the player color is not controlled by the food - only by the level - it should not cause a chain of steps that must be executed often. Only if a level was initialized with the same color player as a color wall, would that player group have to be killed off - doesn’t matter how big it gets with any food type. There could be many different style levels that make use of this constraint.

Next Tasks

Merging segments and camera positioning are top priority. Merging should allow the possibility of initial player chains without food. Camera positioning should allow better usability, as it is currently locked to the center of each level.

Development Blog

Toroban: Update #46

Updates

Toroban: Update #45

Updates

PicoES 1.0.0 (stable)

Pack

Overworld

Next

Steam Release

Toroban: Update #44

Updates

PicoES 1.0.0

Toroban updates

Toroban design

No more rule blocks

Portal blocks

Toroban: Update #43

Updates

Black/null color

Color-component rules

Color areas

Control blocks

Wall blocks

Generic rule system

Time block

Void world

Toroban: Update #42

Updates

Smooth water and sand

Animation engine

Locked player clones

Animated overlay

Control blocks

Camera

More

Logic

Rule blocks

Color systems

Toroban: Update #41

Updates

Polishing

Game Logic Changes

Great Mechanics Discovered

Solutions & Conclusion

Toroban: Update #40

Updates

Next

Toroban: Update #39

Updates

Next

Toroban: Update #38

Updates

Split-Pause-Rewind Bug

Toroban: Update #37

Updates

Player Colors

Color Control Block

Merging

Color Walls

Next Tasks