Tech
The game was made without any game engine or framework. What makes coding fun to me is thinking of the best way to structure a project from the ground up. How are the different responsibilities separated, i.e. rendering, updating game state, user interaction. In a maintainable and extensible game these responsibilities should be very clearly divided and be worked on individually without impacting other parts of the application.

The project is set up like this:

• A central store which holds all of the application state
• A long list of actions which can be dispatched on the store, from the very core actions like game:update and game:render to game specific actions like game:area:plant-seed or game:avatar:use-toolbar-slot
• All game logic is contained in behaviors, these behaviors can reduce/subscribe to actions on the store. Whenever an action is dispatched all reducers and subscribers are called in order of priority and each has the ability to modify the state, this is the only place the state can be changed
• Every animation frame the game is rendered based on the current state
• The user input is all abstracted to an input object on the state, the game never directly listens to mouse/touch/keyboard/gamepad events, the behaviors just check the input state to see if a mapped button is pressed or not
• The UI is separated from the rest of the game and can only listen to or dispatch actions on the central store. The UI never directly changes the state

Some advantages of this setup:

• Adding new features usually means just adding one or a couple of behaviors without much editing of any other files
• The central state makes saving and restoring games quite trivial
• The game doesn't have any tests yet, but the fact that all state changes are done in dedicated behaviors and each reducer returns a new (immutable) version of the state means writing tests is probably fairly straightforward.