It was partly because I felt like I needed a break, but mostly because I'm now tackling a piece of the code that had been looming over me for a while now: the job system. How it should work, what method I should use. Straight code (without inheriting from MonoBehaviour) and lambdas? A text-based switch directory? Actual job GameObjects that get scattered around my map?
I can't say I know the answers to that, but I have an idea of what it should look and act like. So I'm going to think aloud here for a bit. Don't mind me.
The simple version: we have two ways of queuing up a job. We can right click an item (using raycast) and pick a task from the generated list, or we can grab a mode from the right hand menu and drag and drop.
This means, as per my MVP goals, this should happen:
- On build (tent or fire) a ghostly outline of the tent or fire follows the mouse. On placement (left click), the unfolded tent or five wood pieces are consumed. Ideally (for later) we'll have the ghostly outline turn red on invalid placement sites.
- A tree marked for chopping should have an image overlaid on it to show that it's going to be destroyed. Maybe a red X.
- A patch of land to till should have ghostly tilled tiles on each tile.
- A human moving to finish a task should have this task's name in their info box.
- Each task will take a certain amount of energy to fulfill.
- After the task is done, a method should be called. This will change, destroy, or spawn something depending on the task.
- Humans should be self-assigning daily need tasks, like eating and sleeping.
So, in short, a job should be able to require elements, and queue tasks ahead of ourselves to fetch and bring those elements to the work site. A job should have the appropriate preview image drawn on assignment. A job will require a certain amount of time spent before completion. On completion, the preview image vanishes, the final on-complete method is triggered, the job is removed from the queue.
... ... Right. So. Big task. Lambdas in the design for certain, no matter how we go about it. ... I think I'm just going to have to dive in, and it'll be complicated no matter which way I go.