Completionist run: 013/365

Fig. 1: Link to source

What I want to do today

Today’s game mechanic came to me in a dream. Shame it already exists.

Core mechanic

RTS-like grid

How to implement it

  1. [20 minutes] Implement a lattice whose points snap to the nearest node. Think Voronoi diagrams but more Cartesian and regular. Include methods for navigating said lattice (e.g., Move(direction dir), GetNearestNode(Vector3 position)).
  2. [5 minutes] Write a script that instantiates a prefab upon click. Make it instantiate the prefab at the nearest node.
  3. [15 minutes] Modify (2) so that you can see where the prefab will be instantiated.
  4. [40 minutes] Implement A* on lattice. If needed, modify (1) so that nodes can have weights.

ETC: 1h 20 m

Potential Difficulties

The lattice script might nerd-snipe me.

What I was able to do

Checklist

  1. [20 m] Done.
  2. [11 m] Technically done.
  3. [5 m] Failed (due to (2) failing).
  4. [? m] Gave up

Discrepancy: ∞ minutes

Explanation

:(

Final thoughts

About game design

Can statefulness ever be eliminated1?

About me

I give up too quickly. Quite frankly, I have to be somewhere after this session so I think that was a huge factor in my failure.

What I might do tomorrow

Actually do this thing.

 


  1. Unity3D’s Transform component cannot be instantiated, only mutated (Though a quick new GameObject().transform does the trick, it isn’t as satisfying.) 

Completionist run: 012/365

Fig. 1: Link to where the source would be if intellectual property laws ceased to exist

What I want to do today

Finish some of what I failed to do yesterday.

Core mechanic

Tool-switching.

How to implement it

  1. [15 minutes] Read through VRTK and make a list of useful methods.
  2. [30 minutes] Write a tool container script based on VRTK. Said container script must be able to switch between the Duplicate and Destroy tools.
  3. [30 minutes] Attach a radial menu to each controller. Write a script that calls the switching functionality found in (2).

ETC: 1 h 15 m

Potential difficulties

My little library hunt might take too long.

What I was able to do

Checklist

  1. [? m] Failed.
  2. [22 m] Done.
  3. [? m] Failed.

Discrepancy: ? m

Explanation

I broke Pomodoro so I had to fail (1). For the third, I got distracted by team updates on Slack (thereby also breaking Pomodoro).

Final thoughts

What I might do tomorrow

Let’s get started on creation tools.


ETC
Estimated time to completion
Pomodoro
a timeboxing technique where you cycle between working for 25 minutes and taking a break for 5 minutes, with longer breaks every few cycles

Completionist run: 011/365

A short detour

Today, let’s do something different. I’m going to describe in detail what I’m going to do, do it, then write up how I measured up. This is a good thing for two reasons:

  1. I’m going to learn how to estimate and manage my time, which is a Good Thing.
  2. In expertise theory, estimation is a seat-of-your-pants way to gain deep practice.

Furthermore, it is much easier to implement what’s been written down as opposed to doing what I call stream-of-consciousness programming.

Mold

To help me help myself, I’m going to base my articles on this template from now on:

[screenshot of build]
[link to build]
What I want to do today
    1) Core mechanic
    2) How to implement it (+ time estimates)
    3) Potential difficulties
What I was able to do
    1) Checklist (+ time estimate discrepancy)
    2) Explanation for the discrepancy (if any)
Final thoughts
    1) About game design
    2) About me
    3) What I might do tomorrow

Without further ado…


Fig. 1: Link to where the source would be if intellectual property laws ceased to exist

What I want to do today

I’m in the middle of a crunch time project so let’s work on that first.

Core mechanic

Swappable in-game tools for doing various things via SteamVR controllers

How to implement it

  1. [6 minutes] Write a generic tool interface:
    1. Every tool has an input, a function, and an output. So the interface must have three methods: an input method that, when called, stores generic objects in a generic list, an apply method that is mapped over said list, and an output method that returns the mapped over list.
  2. [20 minutes] Write a Duplicate tool:
    1. Upon trigger press, take all GameObjects in its input region and store it in a list.
    2. Upon trigger press again, instantiate all GameObjects in said list at the same transform values relative to the tool before, but now relative to where the tool currently is[^1].
  3. [10 minutes] Write a Destroy tool:
    1. Upon trigger press, apply DestroyImmediate to all objects in the input region.
  4. [15 minutes] Write a tool container script based on VRTK. Make it a functor and attach it to the SteamVR controller GameObjects. Said container script must be able to switch between the Duplicate and Destroy tools.
  5. [30 minutes] Attach a radial menu to each controller. Write a script that calls the switching functionality found in (4).

Estimated time to completion: 1 h 21 m

Potential difficulties

I might not be able to preserve composability, especially when writing the tool functor.

What I was able to do

Checklist

  1. [7.5 m] Done.
  2. [31 m] Done.
  3. [9 m] Done.
  4. [14 m] Failed.
  5. [57 m] Failed.

Time to completion: 1 h 58.5 m

Discrepancy: 37 m

Explanation

I lost steam towards the end of (4) due to having been misled that interfaces cannot be obtained using GetComponent<T>() in Unity3D. Add to that fact that I haven’t read through the whole VR Toolkit library yet.

Final thoughts

About game design

This is a technical issue so there ain’t much to be learned here in terms of design.

About me

What I cannot (or did not) create I cannot understand.

What I might do tomorrow

Probably get this in order.


Glossary

Deliberate/deep practice
the hokey-pokey but useful concept near the getting-a-coach-and-doing-optimised-drills idea in ideaspace
Stream-of-consciousness programming
a series of short but intense typing punctuated by grunts of “What next?”; see Markov chain

Completionist run: 008/365

Fig. 1: Link to source

Work’s ramping up so I made another script today. This is a simple billboarding script that makes its container face a target (by default, the main camera). I remember how difficult it was for me to figure that out as a beginner so it feels nice to be able to write this now with my eyes closed.

Completionist run: 006/365

Fig. 1: Link to source

Unfortunately, today’s mechanic is also behind corporate curtains but I figured grabbing in VR is general enough to share publicly. Today’s build is a simple grabbing script for SteamVR controllers. You can grab and throw stuff with it. The approach isn’t novel, but I have forgotten where I first came across the technique. Just note that the code between <boilerplate> tags ain’t entirely mine.

 

 

Completionist run: 004/365

Fig. 1: Link to where the source would be if intellectual property laws ceased to exist

Unfortunately, today’s game mechanic is behind a corporate wall so I can’t share the source. But it’s easy to figure out how to do it once you notice the miniature model sitting at the center of the image. I was able to sync the movements of objects in the environment to a miniature version which ideally I should be able to manipulate using those sexy-looking Vive controllers beside the red ball. Said manipulation ability will come in a future update.