Open source farming game progress

Slowly but surely my game is getting there.

I posted it here a few months ago and on the surface it doesn't look too much different, but under the bonnet a lot of changes and improvements have been made. The goal of this isn't a quick "vibe coded" game, it's a solid, portable codebase that can stand the test of time.

Changes since I last posted:

- Added rock and tree stump entities (I still need to make these drop wood and stone)

- Added the hoe item + tooling to author sets of tiles that fit together based on their neighbours

- Added the ability to "equip" some items such as clothes

- Improved the item authoring process - Items are defined in a data file which can refer to C functions by name and add structured configuration data which common item implementations can read back

- eventually you'll be able to specify lua functions for item implementations

- entities will one day be defined by data files in a similar way

- Improved the atlas creation process - you can define template files for animations using python's jinja templating syntax

Changes to the engine:

- It now supports the choice of SDL or GLFW backends

- Supports either OpenGL or OpenGL ES rendering API

- I'd like to add vulkan to this

- Engine extracted out into its own separate git repo which is consumed as a submodule

Next on my list of things to do is implement an inventory screen, and then basic things such as health and stamina and a day and night cycle, and then NPC's and a dialog box and interaction menu system. These are all "easy" to do, but hard to do right.

For now I'll focus on implementing gameplay features, but in the future I'm looking forward to porting the game to platforms such as mac, games consoles (as a homebrew game) and perhaps android. I've kept this goal in mind, for example the items by default load their implementation functions by name via the linux function "dlsym" or the windows function "GetProcAddress" - but some platforms may not support this kind of operation so I've also added the option to "bake" the item definition files into C code to be compiled into the game directly in order to remove this constraint. It is better to load these functions as names defined in a data file as this allows for a more "data oriented" design conducive to modding but it may not always be possible so I'm careful to try to supply an alternative. All of this being said the game uses more third party dependencies than I'd like and so the codebase is only as portable as it's most portable dependency.

I try to treat the games assets like its source code - human readable files that get compiled into machine readable binary files.

The engine itself still needs some work especially in terms of audio. Rather than spend time and effort implementing GUI editors for the engine I want to use existing GUI tools such as the level editor "Tiled" as much as possible in combination with text files, CLI programs, and flexible templating approaches. The general approach the games takes towards assets is that assets are defined as text files and "normal" formats such as .png files which are then compiled into binaries which the engines C code can easily ingest. For asset tooling I favor python as it's quick to write and works across platforms.

What I'm making at the moment is nothing more than a test area - there will come a point in perhaps (I hope) about 6 months where I'll begin to design and implement the real game, and focus on improving the look and feel of what's been implemented instead of constantly implementing new things. My goal at the moment is two things: 1.) functional gameplay features that are basically bug free and 2.) a game and game engine architecture that's flexible but makes it easy to add new content and tweak the look and feel of the game.

Currently it uses public domain sprites, but when this point is reached I want to start looking at drawing or commissioning someone to draw sprites of my own. I think the public domain assets I'm using look really fantastic and I'm indebted to the people who created them. Ultimately though I want the game to have its own unique look. You can find them all by googling "liberated pixel cup".

Could I reach that point faster by using claude code or similar? almost certainly. Am I going to? No. I don't like AI and patience is everything when you're writing a game from scratch.

u/Jimmy-M-420 — 1 day ago

Fiber Based Job System

A few years ago I first watched the talk Parallelizing the Naughty Dog Engine Using Fibers on youtube, and it was a real eye opener. At long last I've gotten round to trying to implement something similar myself, to hopefully provide the foundations of a new and efficient multithreaded game engine.

Here is my attempt:

https://github.com/JimMarshall35/Fibre-Based-Job-Scheduler

I haven't fully put it through its paces yet but initial tentative indications are it is working as i intend it to - though it no doubt has bugs that have yet to reveal themselves.

You can see my plan for its architecture here, its not exactly the same as the one described in the Naughty Dog talk:

https://jimmarshall35.github.io/Fibre-Based-Job-Scheduler/architecture/

I am currently working on the exact format of the log files as well as some kind of visualization tool for them - a timeline of job scheduling across worker threads. When I've done that and written some actual tests, and fixed any bugs for it that these throw up, I plan to build a 3d engine around it.

u/Jimmy-M-420 — 1 month ago
▲ 17 r/Forth

Debugging terminal TUI for RISC-V microcontroller forth

I've been working on a forth for RISC-V microcontrollers, and made this special TUI application for debugging. The forth is fully useable with a normal serial comms tool like minicom but this is supposed to augment it's useability with debugging features, sending and parsing the plain-text response from certain forth words in the background.

It first needs to read the startup message from the serial port, then, knowing the microcontroller is present and initialized it sends the "showWords" word which prints the memory contents of all words, which the forth_shell application parses and annotates with what certain pointers point to.

Then when a new word is added it will send "showLastWord" which will print the memory of only the last word created, which is parsed and added to the list. This is imperfect - right now it just detects when an ";" is included in the last line when enter is pressed, but for some instances like "42 const bar" in the video I need to press f5 to manually add the new word.

Eventually I will add the ability to set breakpoints (at least on words in RAM and not flash).

My first attempt at rust, which I still don't understand too well, It's a lot of libraries hacked together that allocate memory all over the place.

youtube.com
u/Jimmy-M-420 — 2 months ago