Back From The Grave

The Dreaded Scheduled Updates

These have been a long time coming; the dreaded scheduled updates. We kept talking about doing them, everyone agreed we should do them, and then we never did them. Funny, right? Well, we’re here now. Fr fr.

Zealot - ROLUS Redesign

These last few weeks, I have been working on porting Rolus to Godot 4.2. It has so far involved a lot of kicking and screaming, and I haven’t even touched AI yet. It also involved rethinking the game and how it should be. That’s something we didn’t do at first, and we should’ve, and that’s our collective faults. So we thought it over, I argued, Dogman argued, death and destruction ensued. 

Anyways, we now have a solid game-plan for the funny ball game, and that includes an actual genre (beyond racing), an actual design direction, and a proper fuel to combust this game into existence: We’re going to Steam with it. The first, and very hopefully not the last…

We’ll expand more on this once we have something to show.

Here’s some development footage.

Dogman - Ordinance Overhaul

We’ve made massive, genuinely exciting, breakthroughs with Ordinance in the past week.

It’s hard to get across how quickly the project went from a loose collection of systems and tech demos to something that feels halfway towards being an actual game.

First off, multiplayer. Right now, we’re in a state where the game is fully multiplayer. Not just managing to connect, but at a point where it feels playable.

We’ve been banging our heads against the wall that is server authoritative networking for years now, but it finally started to click. We managed to get three people together in a game with wildly varying ping, and were mostly able to function.

Second, the player.

Player physics are feature complete for now, as far as we can tell.

Surfing, bhop, sliding, stair stepping, crouch jumping, it all just… works. It feels snappy as hell with potential for some wacky ass action movie shit, and it’s just fun to screw around with.

It’s everything our single-player tests had, and then some.

Third, we’ve started work on a proper inventory system. It’s pretty simple, but a novel concept. It’s built to be quick and snappy in a multiplayer context, but without feeling barebones.

It’s essentially a simple list based inventory, inspired a bit by something you’d find in Borderlands, Fallout, and surprisingly - Trello. (Well, Kanban boards, technically.)

The idea is that your inventory is made up of lists. By default, you have three lists. The main Inventory list, this stores all items you can pick up. Hotbar, this stores anything you can equip in your hands. Body, this stores equipable items like armor, clothing, accessories, etc.

Additionally, you can equip bags, such as a backpack or duffel bag, to add a fourth “Bag” list to the mix.

This works essentially like a Trello board. Drag and drop to re-organize and move stuff between lists. Right clicking an item opens up a context menu that reveals extra options. Dragging an item outside of the lists drops it.

It’s very quick and simple, not meant to take too much of your focus, while still needing a bit of management.

Here’s a WIP of how the list functionality might look

Zealot - Ordinance and Modules

Something in particular I’ve been brewing has been making things modular to fix the code-copy problem. Not like one of those weird modular smartphones, except maybe a little bit, so not helpful. It’s like this: Let’s say I want to make an entity that has health that can take damage. My normal knee-jerk reaction in the past has been to come up with a couple of functions and hard code that directly into the entity. Every time I create a new entity that I want to have health, I copy paste these functions into its script. Then, I suddenly want to change the behavior of health, or perhaps damage was not fully implemented, so now I have to go back through every script and rework the functions. Obviously not ideal. 

So now, I have modules; they can either be a separate object that gets created under an entity and directly modifies the parent entity, or it’s a class that I include in that entity’s script. Either way, I can now make changes to the module and affect the entire codebase, which is nice. 

I’ve also made sure to keep the base functionality for modules as small as I can, so I can freely expand on a single module and not feel like I’m carrying around bloat to everything any module touches. This was something I had commonly seen in other open-source module systems I had looked at, which was not something I wanted for my system.

First door test

Second door test (with modules)