Garbage Country Logbook 2018 pt.1

• Intro
• Logbook 2017
• Logbook 2018 Part 1 👈 You are here.
• Logbook 2018 Part 2
• Logbook 2018 Part 3
• Logbook 2019
• Gallery

Week 2 & 3

Fixing player prediction and movement on stairs. Using a rigidbody simulation for player movement has advantages and disadvantages.

Pros

• Players can collide and will push eachother back
• Players can be affected by other physics objects

Cons

• Rigidbodies will slide down hills which is not desired behavior for players. A lot of additional mechanisms are needed to make players behave predictably

Created variable jump height using the “Cap Velocity on Button Up” method.

Week 4

Basically just did blender tutorials on rigging and animating.

Week 5

Working on a character model.

Character Model TODO

• Write ramped shader that uses vertex color as max lighting.
• Re mirror bone structure
• Running animation
• Idle animation
• Hook up animator in real project
• Make walk animation a little more fluid
• Fix run animation leg trail
• Set UVs on model
• Create void mesh inside model
• Copy shader / ambient setup
• Get the hair back

Last day of this week, gonna start moving the physics computation to a separate C++ program. Managed to send transform updates from C++ already.

• Install Bullet physics
• Figure out how to include external libraries into the worker
• Hook up physics library

Week 6

Next steps:

• Test the order of entity creation and adding components
• BigPhysicsWorker
  • ProcessOps
  • Listen to events (critical section etc.)
    • OnAddEntity adds to list of new entities
    • OnCriticalSection: go through new entities:
      • transfer batch to list for creation
    • OnRemoveEntity
      • Somehow notify GameObject of removal?
  • has-a Dispatcher
    • use ForEachComponent to track Entity Changes
    • Handler class (TrackComponentChanges)
  • Map of SpatialEntity
    • Tracks authority status per component (map)
    • has-a Entity with component data
  • Update loop:
    • GameObject create
      • Go through new entity list and call Create
    • Go through destroyed entity list and
      • destroy GameObject
      • gameobject needs destructor
    • Gameobject Update
    • simulate physics
  • list of GameObject
    • pointer to SpatialEntity
    • pointer to rigidbody, shapes, motionstate, etc.
    • Maybe need a separate create/destroy loop
    • method to create
      • first link to spatial entity
        • then call “create block shape”
    • update method (copies both ways <—>)
    • flag for kinematic
      • set kinematic in bullet
    • lastUpdateSent
• Everything Namespaced
• utils.h
• constants.h
• Need to check out Block components
• Run thread for Update

It’s Friday and I got it to work! However, I’m also going to try a different approach. To enable fast iteration, it would be more convenient if different server types can share code, not having to duplicate physics object creation between C# and C++.

• First off, it would be smarter to put as much of the object definition as possible into the schema, so that different worker types can just read from the schema instead of duplicating the creation code
• Second — for now — use a hack to simulate big physics inside the unity worker.

The hack is as follows:

• create a ProxyBody that simulates a rigidbody in a separate environment.
  • Proxybody can be SetStatic
  • Proxybody can UpdateColliders (and mass etc)
  • Can SetDirection which in turn sets kinematic back on the controlled rigidbody (depending on the static flag).

Week 7

Todo’s before going to Improbable office

• Fix the proxy bodies
• Fix the ladder attachment (was actually just not correcting drift so player was off in server/local)

Spent some time making it easier to create stairs. Before this it was only possible to create stairs from pillar to pillar. Now the stairs can also be built on top of or towards a floor, as seen below. Additionally improved how easy it is for the player to climb stairs.

Week 8

The animation above shows the issue when trying to simply send position updates (it shows a player jumping). Floaty movement! A first fix is to always send a position update when the velocity changes rapidly as an “anchor point”. But the interpolation needs to be tighter.

• Implement the proper method for calculating target interpolation time. (moving average of srv-cli difference)
• Use events to send the positions
• Proper tweening for yaw? Just infer yaw?

For the rest of this week

Going to try and make the environment more interactive. Adding simulated elements like grass and water.

• Receiver listens to component updates on TerrainTile and unpacks data.
• Receiver applies patches when they come in from TerrainTile
• Receiver computes ‘effective height’ from rock + debris and exposes this.
• Receiver doesn’t listen to updates on authoritative worker
  • Gets patches directly from sender
• Senders perform slow (but ordered) update loop of the terrain.
• GRASS
  • light direction vector
  • Slow update loop
  • Keeps track of current square
  • factor in: light, steepness?
• Use 1D arrays and compute 2d coords manually.

Managing some kind of terrain simulation:

Week 9

Continued work on the grass update method. Each slow update hook updates a section of the terrain, and updates only half the entries in a checkerboard pattern. This is to prevent two adjacent entries from being updated in the same frame and obviates the need for a “double buffered” approach.

even frames:   
x_x_x_x_
_x_x_x_x
x_x_x_x_
_x_x_x_x

odd frames:
_x_x_x_x
x_x_x_x_
_x_x_x_x
x_x_x_x_

Then, work on planting detail meshes around the player on the terrain.

Blocks above show the detail meshes being placed around the player. Below they have been replaced by an actual plant model.

Week 11

Continued work on randomizing plants.

It’s really hard to match the plants to the terrain because they use a different lighting model. I think I have to fix the terrain shader now to match the two tone simple lighting.

What to do today?

• Fix the colors. Maybe create a universal color palette for the environment? Is tricky tho because the lighting model is added on top of that. But at least the source colors could be constant.

• Look at the SlowUpdate model. Is it fundamentally flawed? The more vines are added the slower the grass grows. I guess I said it would only be for ‘convergent systems’ i.e. systems that will end up in a certain “steady” state after a number of updates. Is the grass such a system or does it grow too slowly? I could also just crank up the number of iterations initially but that might make the vines grow like crazy. 🤔

  ​

Week 14

Working on a seamless texture for the rocks based on a 3d sampling. I started out with a simple 3d texture of 32x32x32 with something like a tiled/repeating voronoi diagram.

Then I just sample from this texture based on world space coordinates. Then I added a slider that actually offsets the 3d sample in the direction of the surface normal — with a distance based on the first sample value — for some weird refractive patterns:

Not really appropriate though. And really doesn’t fit with the pixel aesthetic of the other textures. Tricky stuff!

Also, I think I need to generate a good-looking heightmap first before trying to texture it based on its shape. If the shape changes drastically, so will the texturing.

Gonna switch to some camera jobs.

Did some work on the camera and cursor, not ideal but better than before. 👍 Made the camera follow the player when walking, and completely decoupled the crosshair position from the camera angle when standing still.

Week 15

Worked on player movement. Ledge hanging now looks acceptable.

Week 16

Working on terrain generation. Since I need to generate a 2D heightmap I need to write some 2d-image manipulation tools. (Matrix multiplication, blend modes, etc).

Week 17

http://catlikecoding.com/unity/tutorials/rendering/part-14/

Week 24

Hello.

So, it’s kind of bullshit work but I tweaked the terrain generator to store the heightmap in a 32-bit float texture to get rid of the ‘stepping’ introduced by 8-bit values. 8-bit values can only contain 256 different heightmap values, which is wayyy not enough to make smooth terrain.

Week 25

The real question is what the fuck am I doing with this game though? Can it be fun? What’s the minimum amount of things it needs to be fun? Like a game loop? Maybe that starts with gathering some resources:

Minimal dependencies:

• Create datastructure for inventory in PlayerStatus

Next step: create some kind of method for digging around in the ground. This probably means that first I will have to fix the cursor UI. I think the cursor should have two modes: locked and unlocked. In locked mode, the cursor is always in the middle of the screen, and moving the mouse will move the view. The player moves relative to the view direction.

• Create simple 3d models for the WorldItems (wood / bag of cement)
• Reduce drop chance on world items
• Create particle effect on dig

• Carrying Objects
  • Create carry animation (Animation Layer with hands / feet ?)
  • put carried objects into / on player?! — Both local player and remote player needs to show stuff in inventory.. Create PlayerReceiver class for both I guess? Just set from Data initially without shortcutting for local player? yeah.
  • carrying multipe objects: stack them on
  • How to sync this animation in multiplayer? NO IDEA I’M FUUUUCKEED.. (ok just roundtrip it to the server for everybody cause i’m lazy like that.)
  • drop objects too

Terrain Related:

• smooth out debris layer periodically with a backbuffered method.
  • General strategy for terrain seams:
    • GetEffectiveHeight smooths out seams with neighboring terrain always. That’s the only thing that really has to match anyway (the effective final heightmaps)
    • ➡️ Option A: All computations get data from next tiles
  • Do a prepass to collect data (including ‘over the seam’) and put it into a buffer that also serves as the backbuffer. This way we only have to checkout the ‘neighbor’ tile once or twice.
  • first just smooth debris alone, regardless of underlying terrain
    • take the sum of the differences to the four neighbors
    • if that sum exceeds a certain threshold (x4), modifiy by a maximum amount. (this is not really mass-preserving, but do I care?)
    • Option B: do a ‘copy seam’ first and then computations only use local tile.
  • But then the actual edge data is never updated?

Peaks are smoothed:

Carrying Over to later task:

• Better smoothing that takes into account all 4 values
• Actually taking into account underlying terrain height 😰 (kind of a nightmare as they’re quantised differently)
• event for digging so that other players also see it happening

Week 26

Okay. It’s week 26. 🤷🏻‍♂️

Construction Interaction:

• if carrying one object: it’s the cursor material
• Overlay for picking up items (👈 warmup task?)
• Better indicator of what will be built (full object preview?)

Close the loop: crashed buildings create trash

• Moving Block should check for heightmap intersection: increment debris (and spawn dust, w/ event?!)

At some point I’ll need some kind of system that alerts objects to changes in e.g. Terrain height:

• blocks can check if they are still grounded or if the ground has been dug from under them
• items have to WakeUp their rigidbodies so they stay flat on the ground and not float.
• vines should also check if they are still attached to a block when things start falling over.

Cursor / Construction UX

Okay, it’s happening. I’m currently thinking:

• Top item is building material
  • ⚠️ Is the block type (pillar/floor/stairs) still completely contextual?!
• Hold Shift to enter ‘build mode’ with free cursor
• Maybe use mouse wheel to adjust settings?
• Preview construction in more detail?
  • ⚠️ Can the cursor still be one box?
    • When building stairs: should it build multiple blocks (support, stair, etc).
      • Why is building stairs currently annoying?
        1. Margins are really tight so if blocks are not aligned they will overlap and you can’t build.
        2. Stairs take up a lot of space so it’s hard to have enough (suitable, see #1) floor space
        3. There is no modular / repeatable way to build them.
        4. You can’t get on them from the ground floor
      • A top support on stairs would solve #3.
      • Building stairs to ground with an auto-pillar would solve #4
      • Fixing the margins would solve #1
    • Can one ‘BigPhysics’ block have multiple colliders in the ‘player world’ ? (e.g. a staircase is represented as one block in the ‘BigPhysics’ but has a bunch in the ‘player world’: stairs, walls, supports, etc)

Todo List for the above

• Do the whole hold-shift-for-build-mode thing (crudely)
• Add a top support to stairs when they are constructed
  • Update the player interaction routine to be able to create stairs going from a floor
  • Update the stairs sizing routine to detect stairs from a floor and align the top support
  • Flatten the stairs so that player can enter from ground level
  • Update the stairs model so that it more accurately reflects the collider shapes (including the support) (👈 whatever do it later)
  • Don’t add the bottom support on small stairs because it breaks things
  • Update the player interaction routine to be able to create stairs to/from the ground
    • that should create an auto pillar. which is hard maybe. Because one action then spawns multiple blocks. (👈 man this is hard nevermind)
  • But I need to fix the block creation requests anyway because otherwise you can create two identical, overlapping blocks in exactly the same frame and they will both validate while the server creates the actual entity. So I have to create a little placeholder that prevents other block validation from succeeding while the server creates the entity.

Build mode:

Ok, zoom out time. Loop closing stuff:

• Falling blocks cause Debris
  • create some kind of generic block dust
  • block touching ground increments debris and is deleted
    • height data can’t become negative
    • fix bug where added debris is HUGE (the height function is wrong?!)
• Construct with what player is holding
  • Top item determines construction mode (wood vs concrete)
    • For now, keep the creation workflow separate: not everything is a Block+itemtype. Wood is a different entity type.
    • No construction outside of buildMode
  • create BuildTemplate from player method, better than keeping track of cursor pos/rot/size
  • Construction takes from player’s inventory
    • Take more than one item if big block
      • indicate how many needed
  • Cap the max size of constructed object
    • Don’t allow clipping pillar to super tiny height.
  • Cap max distance for digging

Okay last task of the week: gonna fix the wood building to build just ladders and platforms. Also make sure that only ladders trigger the climbing movement.

• Modify wood construction size to create ladders
• Allow wood with two ‘pin’ points
• Only vertical boards trigger climbing movement
• Board that touches terrain or when joint breaks is removed (Turned into worlditem)

Week 27

The priorities:

• Dynamic fog: generic aesthetics and figure out if it is a possible look (👈 I know I might get carried away on this because it’s fiddly)
• Growing pots: closing the gameloop, somewhat
• Creeper vines: aesthetics and game loop

Fog Simulation

• Set appropriate height:
  • change base height
  • fog is raised by debris events and spills over to neighbors
    • debris change raises fog:
  • add fixed constant amount
    • fog update step works like debris update: smooth out over neighbors
  • if fog is higher than (terrain + X) subtract fixed amount

Fog Visuals

• Fog Surface:
  • 1️⃣ Currently somehow broken when doing a post effect.
  • Distance should be radial based
  • 4️⃣ Also incorporate the silhouette blend (dark tone from the athmosphere)
  • Blend nicely when full-screen fog comes into effetc
• Fog Full Screen Effect:
  • 2️⃣ Adapt max-dist when above / below surface.
  • Add a height-based component
  • Shift color from silhouette to faraway blend
  • 3️⃣ Always have a minimum fog cove
  • 5️⃣ fogDist defines ‘max visibility distance’. Silhouette before that automatically
• Last problems:
  • Strong silhouetting at 50% depth does not look nice inside fog (only for far terrain)
  • reintroduce tinting for fog surface
  • fog shrink (depth lerp) doesn’t look good. fade in would be preferable
  • fog surface is rendered on top of fogEffect because fogEffect is set to [OpaqueImageEffect]
• Optional:
  • Noise or dithering

This is actually the old fog but it looks nice anyway:

It’s sad. The new fog doesn’t look as good (from above) so I don’t even have a screenshot yet. But I have to move on to other things.

The transition to ‘below fog’ looks way better now though, that was important.

• Intro
• Logbook 2017
• Logbook 2018 Part 1 👈 You are here.
• Logbook 2018 Part 2
• Logbook 2018 Part 3
• Logbook 2019
• Gallery