Emerald Woods – Day 211

It’s development day 211 based on the commit history; I’ll take that.

I wasn’t meant to work in the game today; come morning I didn’t really know what I would be working on… I kind of had the Saturday morning available, but there were so many different things, I ended up doing none of them (as usually happens).

I tried working on a Fortnite project I’m partnering with to get going, but UEFN kept crashing. So in the end I decided to get out of my head a small thing I wanted to do in Emerald Woods inspired by a conversation I had with a friend yesterday, and that triggered me doing a bit more in the game than I thought.

Besides the addition of a new type of pet (I still don’t know if it’s going to be official or not, may keep it as a private homage), I worked on correcting some things that were dangling in my local dev environment and the tip of the repository from back in February; there was an incomplete migration of the Persistence module to TypeScript, which was kind of messed up as it seems I tried at the same time to implement saving games to easily portable files instead of using local storage, when deploying the native apps. After some back and forth I managed to clean up stuff and implement both things.

As I was doing that, I decided it was also worth tackling something: the long Saving times currently caused by using LHZ compression in JavaScript to reduce the size of the big serialized object that represents the entire world; the serialized JSON is about 30 to 40MB, and using LHZ compression it goes to about 1.5MB which is great (and needed in order to use Local Storage in browser), but it’s just too slow!

Since I started doing the Electron builds, I figured there had to be a better way to do it more “natively” on the node side of things and that happened to be true; using zlib compression did indeed cut the saving times by orders of magnitude, and by that I mean the compression step is now almost instantaneous, now the heavy part is done in the serialization part which still uses my circular.js library to serialize the entire world model.

That brought me to something I’ve also wanted to check on for a long time: the size of the world… honestly, for what I envision with Emerald Woods, a single-scale level of 512×512 tiles is just too small. Something I need to look into is implementing a chunks model similar to what is already there for OpenArthurianX6, but that brings different challenges (since OAX6 maps are mostly static and authored, not procgen, so for Emerald we’d need to serialize the chunks on map creation and only write changes to the dirty chunks)

So, I tried increasing the level size to 2048×2048 (that’s 16 times larger); it worked fine overall, but world generation which took significatively longer, about 90 seconds which may or not be acceptable. Some optimization in the procgen algorithms and maybe on-the-fly generation would be needed. The other bottleneck was on runtime; maybe I’m doing some map-wide checks that would have to be checked into, because the game didn’t feel responsive at times.

Other than that, serialization of the model took longer (but not that much). After it generated the 415’749.514 character’s long JSON data string, zlib compression was almost instantaneous to about 6MB. LHZ OTOH completely blew and was stuck forever.

In any case, the experiment is folded and we are back to the small map. Another facet to check into in the future since it requires some heavy redesign of the world model.

Talking about experiments, as I added this new possible pet, I thought it was also time to address something in the game’s visual style that has bothered me for a long time: the scale of the player character sprites vs the creatures of the land… I think it’s due to how the visuals evolved from the first graphics version (v0.2.6) which based on concepts made by Mateo “carenalga” early 2023, vs. the style of the creatures made by Agua hervida (v0.3.4 also later in 2023).

My idea is to go for something that takes inspiration from both, keeping the non-comic, more realistic proportions for the player character (especially the featureless face), but somewhat scaled to the creatures proportions so it doesn’t look silly in the scene, and we keep the possibility of adding expressivity to the creatures, creature sprites are framed in 16×16 pixels here, so going the other direction (making them smaller) would result in just a blob of pixels.

I’m going after having a style contrast between the character’s sprite as his “avatar” in the woods (pulled away from reality) vs the strange, fantastic creatures you find there which have more room for expression. It’s still going to be super low-res and a bit abstract, but hopefully less jarring to the player’s perception.

I’ve also given some thought to the other aspect that have been lying around for years now; especially the “taming” facet which, frankly, I’m not very happy with the design we made which made it a super involved and time consuming process to tame an animal. I’m thinking on simplifying it a bit, making it more focused in knowing and having the right items, instead of spending time and energies in boring multi-day rituals.

This morning I also played my “Monster Trainer RL”, which I wanted to show my daughter (she liked it more than I thought she would) and I’ve also been thinking on some ideas for the upcoming 14 days traditional roguelike gamejam, the Roguetemple’s Fortnight. Honestly I’m thinking of skipping it this year and instead focus all my energies in the many ongoing projects, and maybe incorporate some of these ideas on them. (spoiler: I was thinking of making a traditional roguelike inspired by NES’ Friday the 13th, but maybe that could instead be an additional scenario for Emerald Woods).

Likewise there are some elements from Monster Trainer RL, esp. on multiple creatures management, that might make sense on Emerald Woods… but the fact that their combat focus is the diametral opposite doesn’t help.

Leave a comment