Garbage Country Logbook 2018 pt.2

Week 28

OKAY it is time for plants.

There were already vines but they were kind of ‘hard-coded’ so I’d never be able to have different species running different behavior and such.

So first I started off creating some kind of JSON database of plant properties and stuff, but now I’m leaning towards just including all that data inside of Unity in a bunch of prefabs. That will give me visual editing out of the box and not having to deal with a bunch of JSON reading and asset finding.

STATIC Node Data (scriptableobject)

PER INSTANCE Node Data (schema)

STATIC Plant Data (scriptableobject)

PER INSTANCE Plant Data (schema)


2018-07-13 at 15.06.34

2018-07-13 at 17.57.27


2018-07-15 at 15.34.15

Week 29

Ingredients for some kind of challenge (because it’s a game or whatever)

Todo list for the above:

side note: So after splicing in the creation to create a SoilContainer I am discovering that the whole pipeline for constructing an item is kind of fucked. There are so many custom steps doing essentially the same thing for each item:

  • Starting with the player, determine which item should be built
  • Figure out on the player’s end whether it would fit
  • Create & send a request to construct the item
  • On receiving the request, do the same check about whether the item would fit (and possibly other constraints)
  • Instantiate a placeholder to prevent concurrent requests from succeeding.
  • Request entity creation from SpatialOS Progress: I can now create a soil box

Half of it is symmetrical with items in the player inventory, and half is not. For example: right now it’s a pain to point a Seed prefab to the NodeType of the plant that it should create, because the seed prefab is just a generic WorldItem without specific components. I have to flatten all this stuff down to different prefabs and not try and be smart in code.

Solutions for the above (thanks Stephan)

All different flows:

Oh man I’m getting hardcore stuck on this stuff.. The schema of:

is hard to use when it’s not clear which of those fields determine the object uniquely. In the case of a seed, the plant type is stored in the Metadata which is a mess. Perhaps the rule should be that that is not allowed? Metadata never influences the object type but only varies the appearance? But then where do I store the plant type?

Job ad

🔎 Looking for freelancer to do some low-poly low-res 3D modeling (in #blender3d) and texturing. If interested send reference work to

💰 Paid; up to a week of remote work

🌱 Simple models: modular plants & various salvaged trash items

Please RT

Week 30

Haha, week 30 and so many unchecked boxes from last week. Just gonna copy the important stuff here:

Ok that’s done. Still pretty rough but it’s a start. (Needs some way to split out this ApplyTo stuff depending on which kind of object (client/worker/playerHeld) it is applying to)

2018-07-23 12.20.24

But for now I’ll just stick with GetComponent<X> != null .

Construction Recipes

First, I think I have to formalize the “construction recipes”. Implicitly selecting whether the player wants to build a stairs or a pillar or a floor or a soil box from context is no longer gonna cut it.

I need a well defined data structure that is used both on the client and the worker which contains all the data for

What data does a recipe need for validation?

In Buildmode: 
	(No selected recipe) -> MouseWheel selects recipe. Click Activates
	(With selected) -> MouseWheel / Click / Drag are fed to recipe.

Maybe there is some kind of RecipeConfigurator that transforms cursor positions into the required recipe data (pos/rot/size). (Actually, I just added abstract void Configure to the Recipe base class, no separate object)

✅ Damn! I got all the recipe stuff to work. Player code is SO MUCH cleaner now and more symmetrical between client and worker. Nice. Only for SimpleItems though. So next step is recreating the ability to create pillars, floors, stairs, etc.

When all this is done I’ll be able to add nice graphics to the Recipe Preview and also icons to select recipes etc etc.

So the last bit of this week was plagued by some SpatialOS bugs that I had to work around.

Small Jobs

Week 31

Let’s start with some small tasks re: recipes:

Since I saw that the build mode interface is hard to parse for a new player, I have a couple of ideas for improvent:

Then what am I doing in the rest of this week?

Today I wanted to hook up some new models by Carolina.

2018-08-01 at 14.58.14

But for building Items it’s not as easy as just creating a prefab, because the current system is kind of shit. There is only a single prefab for “Soil Container”, which would not be able to distinguish between the wooden one and the one built out of barrels. So I think the solution here is that I need to split “WorldItem” into an “Item” component and a “Grabbable” component. So that even non-grabbable items can still have an itemType . I guess almost every single entity would then have this itemType 🤷🏻‍♂️. It’s kind of what Spatial used the metadata field for but unfortunately that is tightly linked to the EntityPrefab in the spatial default entity creation pipeline.

Looking cute.

2018-08-01 at 16.48.03

Week 32

You want some beginning of the week notes? Ok: “Hello”.

For real though. It’s week 32.. That means I have…

Almost eight weeks left before the ‘playtest’

So okay the soil container things are falling through the ground because they are proxy objects and the Terrain does not exist in the BigPhysics simulation. What can be done about this?


2018-08-09 at 16.09.55

Good stuff.

Week 33

  1. What are the issues that really need to be fixed for playability?
  2. Can I group those issues into themes so that I can handle them in batches?
  3. Will there be any time left for adding content, and what should that be?

Hookay, let’s start with some of those animations then. 😱

Maybe I need to simplify the animation system a bit to just pass a single int animationState to the animator, which could also be synced over the network.

Oh god I need to rewrite the player movement again. 👉 Okay, turned it into actual FSM. That made things much easier to read.

Now that I got that crap out of the way, maybe I can hook up some mechanics for the player taking damage and crawling after doing so.

The interface for Build mode is problematic.

Two types of recipe feedback:

  1. Non-draggable recipe (just click & place)
    • Conf SUCCESS: Show preview box
    • Conf FAIL: Show fail reticule. HUD.ConfigurationFail
  2. Draggable Recipe
    • Hovering
      • DRAGGABLE POINT: Show Initial pre-drag preview box
      • NOT VALID STARTING POINT: Show fail reticule
    • Dragging
      • Conf SUCCESS: Show preview box
      • Conf FAIL: Show drag fail reticule. (Original point + line + regular fail reticule)

Conclusion: Draggable recipes should:

I guess there are different configuration states:

Okay, reworking this UI stuff.

Week 34

This is gamescom week so not a lot will get done. Though if I have to show this game impromptu at gamescom, what should I fix? Hmm maybe that’s kind of hopeless. I could just work on the UI a little bit.

Week 35

Gamescom. Did nothing.

Week 36

So, change of plan. Moving playtest to October b/c Improbable asked for feedback on the GDK. So I have to get familiar with Unity ECS and the GDK.

Things I learned about ECS:


Okay, time for a little exercise. Let’s create a hybrid ECS thing.

Exercise number two. Add an additional entity type to the GDK example

My current Entity Creation Workflow:

For example: There are different things lying around in the world that are just “WorldItem” prefabs. The ObjectType is an int that specifies whether it’s a CementBag, WoodPlanks ,PlasticBarrel, etc. Some items are uniquely specified by the Metadata.entity_type (the Prefab name string) but some are not.

entity creation pipeline before

With the SDK Pipeline out of the way, though, a more sensible and ‘linear’ entity creation pipeline comes to mind, one that goes through the Template first, before Instantiating a Prefab.

entity creation pipeline before

For a GameObject-based workflow, this Template could be a sensible place to store much of the definition-y stuff that we talked about before.

My question is: Is this something I can elaborate? Or will the GDK design break this in the future?

Week 37

Worked on ECS / GDK (see separate logbook:

Week 38

So going to rewrite the TransformUpdater or the ProxyBody to an ECS system.


Week 39

Ok I’m back home again. Time to reprioritize to do a playtest. Today I was figuring out why my bandwidth usage was so high last week when testing with 10 people.

2018-09-24 at 15.49.38


I have to add a durability system I guess. What are the requirements for this?

Had a nice talk yesterday with F & D about writing logbooks. Gonna keep it up :)

And today I’m getting back in a productive mood which means I can be happy refactoring stuff without ever keeping an eye on the big picture. Hooray. So I’m gonna create an Interactable interface for interacting with items on the ground, with the terrain, with cutting plants. That should simplify player code a lot.

For the Playtest

  1. What are the issues that really need to be fixed for playability?
  2. Can I group those issues into themes so that I can handle them in batches?
  3. Will there be any time left for adding content, and what should that be?

Big Features

Long Term Plans


Crosshair Movement, Cursor UI and Camera Tracking

Growing food and resource Limits

Test deployment and pick date for playtest

Terrain Generation

Player Movement and animation

Optimizations (LATER❗️)

1️⃣ make it work, 2️⃣ make it right, 3️⃣ make it fast.