I was playing the early access version of Coral Island and whenever I play a game for a while all I can think about is how I'd build it, so I did.

The game is a cozy farming game in the mold of Stardew Valley and as mentioned Coral Island. You start off owning a house and a small plot of land and can start farming, meet and build relationships with the townspeople or become an explorer in the caves.

You can play the game on desktop with mouse/keyboard and on touch devices using an on-screen controller.

The game is still in progress and will update frequently in the coming weeks.

Tip: If you want to play on a mobile device add a link to the game to your home screen, this enables you to play fullscreen.

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.

Features currently implemented

• Planting seeds
• Growing crops
• Chopping trees
• Prying rocks
• Interacting with NPCs
• Milk cows
• Pick up chicken eggs
• Buy/sell items in various shops
• Move items in inventory and storage
• NPC routines
• Exploring infinite procedurally generated caves
• Many more

Graphics
Most of the graphics I used were made by Shubibubi