Saturday, March 15, 2014
There's too much progress and too much thought to log coherently. I won't even try (to log it coherently, that is).
Refining the Task Model: Capability, Requirement, Input, Output
First of all, these processes of which we've been speaking lately are now called 'tasks.' (Has anyone noticed I have a burning love of renaming things?) The conceptual model of tasks has been further refined to the following four elements:
Capability: A measurement of the capabilities that influence an agent's performance of the task. In particular, the rate of a task is assumed to be linear in the total sum of all relevant capabilities of the actors that are assigned to the task. For example, 'transference' is a capability for 'mining.' 'Storage' and 'motion' are both capabilities for transportation jobs. 'Research' is a capability for...research! In every case, you see that the task becomes quicker or more efficient as the capabilities rise.
Requirement: To be thought of like an 'activation' energy. Many processes would require, for example, some motion capability. At the same time, it doesn't necessarily influence the rate of the process.
Input / Output: You already know
Item Classes
Sometimes, a flat hierarchy of items just isn't enough. See
this topic to understand why. The engine now supports hierarchies of objects, where an object can be treated as a 'subclass' of another object. This allows for the possibility of many different objects to fulfill the role of one.
For example, I might put out a contract on Viritium, but that doesn't mean I need a specific type of Viritium. Maybe there's 'pure viritium,' 'compressed viritium,' 'impure viritium,' etc. Each fulfill the role of Viritium to a certain percentage. Maybe 'pure viritium' has a 2x multiplier, impure viritium has a 0.75, etc.
I'm excited about this. Definitely with respect to different purities of ore, different types of the same material, etc. But there's more to it than just that. Consider if 'deaths' or 'dogtags' are an item. The engine now immediately has a way to understand that 'Joe Billybob' is a subclass of 'The Band of Brothers' faction, so the item 'Joe Billybob Dogtag' can derive from 'Band of Brothers Dogtag,' meaning that a contract can be put out which pays for 'Band of Brothers Dogtags,' and it can be fulfilled by killing any member of that faction. Makes total sense, right?
This complicates inventories and fulfillment checking a little bit. But I think the price is definitely worth it. The ability of a subclassed item to fulfill the role of a superclass is going to come up in a lot of places and is going to be worth it's weight in gold!
Crew Mechanic.
Let's stop lying to ourselves, shall we? We need a crew mechanic. It doesn't have to be fancy. It doesn't have to be complex. But NPCs are intended to be first-class pieces of the game, so let's treat them as such. Introducing: crew quarters, crew taskings. Really, this doesn't add a whole lot of complexity to the game (don't worry!), it just answers a few questions that were already up in the air.
Who's piloting a ship?
"The pilot. (Duh?)"
When I buy a new ship, do I have to hire a new pilot?
"Of course."
Do I have to pay wages?
"Yes. If you hire people."
You mean I have an alternative?
"Of course. Robots."
So I can have a completely robotic fleet?
"If you like."
Can I research better robots?
"Yes."
Can I research better people?
"That doesn't make any sense. But people gain skill as they increase in experience."
I have a capital ship with 20 independently-tracking turrets. Who's controlling them?
"Someone. You decide. Could be you, could be Elroy McWampratSniper, could be GunneryBot 3000."
NPCs have stats that determine their effectiveness at certain tasks. This is not a new mechanic, it is 'capabilities' (from above) in disguise
Stats are just capabilities. An NPC's 'gunnery' ability is the exact same as a transfer unit's 'transference' capability. They both affect the efficiency of an agent at performing a specific task. In the case of an NPC, the NPC's stats can change over time with practice. This separates NPCs from robots and gives you some trade-offs to think about. On the one hand, with an entire army of robots, you don't have to pay wages. On the other hand, the up-front cost is much, much higher, and the long-term potential remains constant. With an army of people, you pay less up front and have the potential to increase the effectiveness of the fleet over a long period of time - but in the end, you'll end up paying more since you're paying wages. Good gameplay choices to be made by any ruler
Tasks and Task Allocation
Let's talk about tasks. Tasks are everywhere in the world, and tasks go hand-in-hand with crew, because crew are the people carrying out those tasks.
For example, you can think of 'control forward turret #1' as a task that's implicitly created by equiping a weapon hardpoint. In fact, in general, it can be useful to think of tasks as being created by objects. Weapons create control tasks, tech labs (oh, hey, did I mention that I renamed research units to tech labs?
) create tasks for research, production labs (heh
) create tasks for production, etc.
That's obviously taking tasks to the micro level - but that's the beauty of it. This works for all levels of scale. Let's move back up and examine factional structure, as we were doing before with processes and process trees. Now we look at a faction as a group of tasks - but where do they come from? Well, that's the neat thing. Some objects are inherently
dynamically-tasked in that they allow for dynamic creation and linkage of task networks. A faction is one such example. A faction only creates one (or maybe a few) 'inherent' task(s) - CEO, for example. But the CEO then creates a dynamic task network within the faction.
Task networks actually appear all over the place, which is why this model solves so many problems at once. One immediate example is fleet command. A fleet is a task network in almost exactly the same way as a faction - a fleet has a commander, and that commander creates tasks and assigns members of the fleet to them to build the structure of the fleet. Fleet-based tasks would be along the lines of 'scout,' 'tank,' 'support,' etc. (you might call them 'roles'). Planet? Oh, guess what, same story. A planet is a dynamic task network of 'colonies,' managed by a governor. Same structure as a faction or fleet. Same code. (Planet theory is still embryonic, so don't quote me too hard on that.)
Broad Strokes
I've said it before and I'll say it again: the only way to build something like LT in finite time is to find sweeping simplifications that asymptotically reduce the workload at every corner. Today and yesterday alone I believe I've just hit on about...er, roughly a gazillion such simplifications. At the same time, the game is looking to have more functionality than ever before. That's when you know the system is right - it's simple, clear, but flexible.
Feeling good. Very good.