n3c's game corner

So... in true development hell fashion, this latest feature took a weird turn.

Basically, I set out to implement the Status area of my design, where it would show the player's current action along with a little countdown timer.

As I started implementing that, I came to realize that the way I was handling Redis for these actions might not be the best. So... the only sensible path was to go down a never-ending rabbit hole to switch the Redis ZSET system I was using for my actions manager with a fancy new Key Expiry system (backed by a scheduled polling fallback).

Was this the best move right now, for a game in early dev stages? Absolutely not! Was this a good usage of several hours of my spare time over the course of two or three weeks? Probably not, especially considering I will most likely never actually finish this game. BUT, if I ever get further into the development of this game, this approach might (potentially) save me a lot of headaches (because by then the codebase would be even bigger and more confusing). Unless, of course, this was still NOT the right approach for this (which is what is most likely to happen).

But whatever. Eventually, I got that done, so I returned to my starting point: to implement that Status area. That one was, without a doubt, a much easier project.

Basically, by default, the new Status bar displays 'Idle', but it is updated with the current action and a nice countdown timer to show progress and duration. This is fully implemented and working for both Gathering and Moving actions (the only actions currently in my... "game"). As I implement the remaining actions, I just need to make sure they work with this system.

Oh, I also found (and fixed) a Movement/Gathering issue (caused by repeatedly spamming actions).

As I'm coming back to development hell after a month and a half hiatus pretending to be a designer, I figured I'd start with some clean-up tasks to once again get familiar with my ever-growing codebase.

After going through my To-Do list of dev tasks (trying to remember what each one was supposed to be), I decided it was the time to convert my NodeJS codebase from the old CommonJS to ES Modules.

This didn't really accomplish anything game-wise, but it was essential for future-proofing and hitting proper strict mode compatibility. And it was better to handle this now than later in the project's lifecycle (when I have even more code and files).

While at it, also took the opportunity to add a bunch of missing semicolons for code consistency, as well as remove some placeholder/unused files that I had lying around.

Wow, it's been quite a while since I last updated my dev log. Surprisingly, I haven't given up on this project (yet!).

The project has reached a point in complexity that simply continuing to focus on development would cause massive issues, as I "know" what I want, but in reality, I just have a rough idea.

So I buckled down and decided to create a rough wireframe, to ensure all the systems make sense and players would be able to play by having all the information and interactable elements at hand. I decided to use Figma for this, since it could later be used for the design of the website/app. However, I soon realized I did not know how to actually use Figma, so it took a while to get comfortable with it. Luckily, I'm married to a web designer, so I got a few power leveling sessions full of tips and tricks, which got me up to speed.

After getting familiar with the platform and starting to whip together a rough wireframe, I realized it was hard to just leave it as a rough wireframe. So I went down the rabbit hole of creating a potential design for my game. That process, again, proved to be more complex than what I had anticipated.

My goal is to create an homage to a very specific niche of really old browser games like Space Merchant Realms and TDZK (it's almost inexplicable how much I miss this very weird game). However, those games are from a bygone era, so I had to consider how to create a spiritual successor while implementing modern technologies and more real-time gameplay.

As ideas and concepts slowly started falling into place, the design started taking shape, while I slowly refined and iterated over it and all the required elements. It was an absolute PITA, but I'm happy with this result.

A look back at previous versions

And because this was a (very) long (and frustrating!) journey, I'm also leaving here some earlier versions. It's always fun to look back and see how the creative process took place.

What are my next steps?

Now that I have more than just a rough idea of what I want to build, it's time to go back to development hell! And considering I haven't touched a single line of code in this project in more than a month... I'm sure this next phase will suck.

It seems this one took forever. Mainly because life got in the way and I couldn't find enough time to focus on this.

Also, when I set out to add timers to my movement system, I had not considered that I would have to step back multiple times to redo several other items (because apparently they were all tied together).

Anyway, here's a short list of this absolute PITA of an update:

Refactored Explore page into several smaller components/composables, so it's easier to continue to add functionality to it.

Refactored the Gathering system to use Redis Sorted Set instead of polling KEYS *, while also making it more generic. Not just because it should (hopefully) be more efficient, but also because it will then allow me to re-use this for other actions (like Movement!)

Completely rewrote Movement System (using and expanding the now-more-generic system I created for Gathering), so that it is now (finally) also timer-based (and with all the other bells and whistles)!

Implemented a Finite State Machine (Gathering & Moving actions are already using it), to ensure player can only do one action at a time.

Started working on some rough wireframes, to ensure all these systems I'm building will actually support what I want the game to have. It's pretty clear I'm getting to a point where the "I saw it in my dreams" approach is no longer cutting it, and I really need to put some thought into the UI.

Overall, this was an absolute PITA. Not to mention that all of these systems are still missing tons of features. But oh well, I guess any progress is still a step in the right direction.

For archival purposes, I'm also sharing the first screenshot of my PBBG. Hopefully in a year, I'll still be working on this project and the interface will actually have some styles (and be pleasant to look at).

When I started this, I thought this was going to be easy: just improve the timers so that if a user refreshes the browser or reconnects to the game, the gathering action doesn't drop. What I failed to understand is that I still have no clue how to use Redis or Sockets.

After several days of wrangling with this thing, I somehow managed to figure out what seems to be a somewhat robust (and working!) solution.

I also ended up finding (and addressing) several more issues with my original gathering POC.

I made sure that all gathering logic is centralized on the back-end, eliminating front-end trust, which should help protect against cheating and exploits.

I also did what I naively set out to accomplish: Front-end UI now actually restores the visual status of ongoing gathers after reconnects or refreshes.

This was an absolute pain in the ass, and I hated every minute of it.

Now onto the next challenge that will make me crippled with self-doubt and question my ability to use my brain.

An accurate depiction of me trying to figure out Redis, Sockets and NodeJS:

When I first built this feature, the user would join the socket room via client-side (this is what shows other characters and resources in real-time to all players in the same location). That would potentially allow cheaters to do some bad stuff.

I'm still learning how to actually use web sockets, but I managed to refactor that part so that joining the socket room now happens on the backend.

I revamped the gathering system so it now uses Redis for timers and relies entirely on sockets instead of API calls.

Early tests show it works pretty well, and it feels like a good foundation to build on. That said, I’m still pretty new to sockets (and even newer to Redis). So there’s a good chance I’ll need to refactor it a lot as I learn more. But for now, I’m happy with the progress.

Got a couple of nice wins today:

Finished the functionality to show what resources are available in Sectors

Added a very basic POC "gathering" functionality (only so I could test the next item)

Added socket integration to that data. Now other players in the same Sector can see the resources changing in real-time!

Refactored and DRY'ed some of my code.

Nothing fancy today, but I managed to push the needle forward a bit:

Added a security check for the socket users join when entering a new sector.

After about a week of working on this on my spare time, I finally have an update!

The Explore page in my game (where players can navigate from one Sector to another within a System) finally shows other players in the same Sector. And thanks to sockets, it shows in real-time when other players enter or leave that sector.

There are still so many things to do before this project starts to take shape, but I'm pretty happy with it. And this same approach should be reusable/extended to show NPCs or resources present in the Sector.

I've been working on my project during my spare time for... about a month now, I think. I figured now's the time to create a little Tumblr account to use as a devlog, so I can send my progress and updates into this void called Internet.

Don't really expect anyone to read this, but I'm hoping it will be nice to be able to look back and see how far along I've come. That, of course, if I don't quit this project like I usually do...

So what is this project even about, no one asked? Well, it's for an old-school PBBG (persistent browser based game), reminiscent of the early 2000 games. Although it does not have a name yet (that I'm willing to divulge), it is set in space. Imagine EVE Online or NMS, but without any graphics. Just a boring text-based interface, that players can use to jump from one corner of the Galaxy to the other, while gathering resources, trading between space stations, attacking other players or even raid ports, stations and planets.

For anyone old enough to remember, think Space Merchant Realms, and similar games.