046 - December 15, 2019

These last two weeks have seen quite a bit of progress!

I finished up porting the game server to use specs, an open source, well designed entity component system that was in all ways better than my hand rolled one.

Along the way I had to make some changes (and some rewrites) of code that I wrote when I first started using Rust in January 2018, so I ended up significantly improving the codebase.

Specs Refactor

I used test-driven development for the entire port - so I ended up with a much more solid backend and I'm really excited about the speed at which I'll be able to add new features.

If I maintain this pace of TDD I anticipate spending very little time debugging and almost all of my time writing tests and getting them to pass.

In the near future I'll start using specs on the front-end. Fortunately that won't require a re-write since the front-end state is mainly used to render the screen and isn't as intertwined as the backend state was.

Handling entity death and respawning

One place that I got stuck on for some time was handling entity death and respawning.

Before the refactor I had a complex respawn component that had three stages. Alive, about to respawn and respawning.

If an entity was alive it would get sent down to the client, if it was about to respawn it would also be sent down to the client but without most of its components so the client could play a death animation.

Then when it was respawning it wouldn't get sent down to clients.

This was an overly involved process - but as I was rewriting the spawn system I was struggling to come up with a better system. We needed to let players know when an entity was respawning so it could play a death animation, but we also didn't want our backend systems to accidentally process entities that were respawning. I didn't want to make every system check if an entity was respawning before acting on it - so I started thinking and sketching things out in my notebook.

Eventually I landed on just keep tracking of the entities that died in each "region" of the game (a region right now is a 16x16 block of tiles). Then on that tick we'd let all players in that region and neighboring regions know that that entity ID has died.

Now the client can be responsible for playing the death animation for that entity and then removing it from the client's local state.

The only accomodation the backend needs to make for this is sending down the entities that died this tick - nothing more.

In general this is how we want to move forwards with things like this. The backend should do as little as possible to accomodate frontend specific things like animations. The game server should know as little about how to deal with the visual representations of entity's as possible.

It should just worry about data for the most part.

When an entity with a respawn component dies we push a new entity to our entities_to_spawn: Vec<EntityToSpawn> resource and after some time it will spawn.

#[derive(Debug, Copy, Clone, PartialEq, Eq)]
pub struct EntityToSpawn {
    kind: EntitySpawnKind,
    position: TilePos,
    /// The number of ticks until this entity spawns - if this is zero at the beginning of this
    /// tick then the entity will spawn during this tick
    tick_delay: u16,


Our financials for November 2019 were:

itemcost / earning
revenue+ $4.99
aws- $113.44
adobe substance- $19.90
GitHub LFS data pack- $5.00
photoshop- $10.65
ngrok- $10.00
chinedun@akigi.com Google email- $12.00
akigi.com domain renewal- $14.90
upby12.com- $12.00
upbytwelve.com- $12.00
UpBy12LLC Formation- $65.06
total- $269.96

A bit over the usual expenses this month.

We formed an LLC that we'll be filing taxes for the business and it's expenses under.

We also bought and renwed a few domain names. The $12.00 for the gmail account is questionable - I think it's on the chopping block of things I don't need right now. ngrok is also on that chopping block - I hope to get around to finding an alternative.

I haven't used ngrok for over a year now so that's just wasted money right now.

This Week

This week I'll be diving back into making things that players can see and interact with. I'm working on Pookie's (an NPC in Capuchin City) house.

The Capuchin's aren't the most architectural bunch - so their "houses" are just fenced off patches of grass and dirt sometimes partially "roofed" by an overhanging tree leaf.

Pookie's desk

After that I'll be working on implementing the ability to train the Hitpoints discipline. I'm excited about introducing this - as it'll be the first real mechanic in the game.

I'll talk more about this in the next journal entry.

Cya next time!