❔ Designing a Worker system for a game
I've had a game idea for a long time and figured you guys would give good critique on one of the pieces of the design that I've been struggling with - managing Jobs, Workers, and Resources (together)
The idea is simple enough; Surviving Mars, Rimworld, or any colony management game. I want Workers, who are automatically assigned Jobs as needed based on proximity to the job, and possibly other conditions
Summarizing it here will be less simple but I'll try to make it very brief...
Recipe - Each class inheriting this contains a hardcoded set of Tasks (not C# Tasks) that must be completed for the recipe to produce an output, and info about inputs/outputs
Task - Contains the required Resource type, and the location it must be delivered to (and/or info for other job types, Worker requirements, etc). May contain an inner set of Tasks which must be completed before the primary Task can be completed. Contains methods to mark as completed, which are called by the Worker they are assigned to, and emits events when completed
JobGiver - Contains Recipes. Emits JobReady events containing Tasks for a recipe. Subscribes to events for completion of each primary Task, and produces the Recipe output when all Tasks for a Recipe are complete
Worker - Has a single ActiveTask. Emits WorkerReady event when it has no Task
ActiveTask - Inherits Task, includes a direct reference to the specific Resource instance that is reserved by this Task JobManager - Subscribes to all WorkerReady events, tracks available workers and their positions. Subscribes to JobReady events; queues Tasks if workers or resources are unavailable. Creates and assigns ActiveTasks when a valid resource and worker are found for the Task. Tracks reserved and unreserved resource instances by listening to appropriate world events This is the barest essence of my idea so far. But I have some concerns... - Tracking every resource instance could get very expensive, not to mention checking distance between every worker, the JobGiver, and every potential resource (Realistically I'd probably pick one to prioritize; minimum distance from resource to JobGiver, or minimum from worker to resource) - Should the JobGiver be responsible for checking its own inventory contents, and marking tasks complete if the resources are already available? Or should the JobManager handle that? - Relying on events means that I'll have to make special cases for anytime a player can mess with something; taking a reserved resource, for example. But that'd just be re-queuing the Task It's also worth pointing out that the reason for tracking resources is because we need to reserve them; we don't want two Workers trying to grab the same resource, and we don't want Workers taking resources that are stored and about to be used for some Recipe Anyway, I'd love any ideas or critique on the high-level design
Recipe - Each class inheriting this contains a hardcoded set of Tasks (not C# Tasks) that must be completed for the recipe to produce an output, and info about inputs/outputs
Task - Contains the required Resource type, and the location it must be delivered to (and/or info for other job types, Worker requirements, etc). May contain an inner set of Tasks which must be completed before the primary Task can be completed. Contains methods to mark as completed, which are called by the Worker they are assigned to, and emits events when completed
JobGiver - Contains Recipes. Emits JobReady events containing Tasks for a recipe. Subscribes to events for completion of each primary Task, and produces the Recipe output when all Tasks for a Recipe are complete
Worker - Has a single ActiveTask. Emits WorkerReady event when it has no Task
ActiveTask - Inherits Task, includes a direct reference to the specific Resource instance that is reserved by this Task JobManager - Subscribes to all WorkerReady events, tracks available workers and their positions. Subscribes to JobReady events; queues Tasks if workers or resources are unavailable. Creates and assigns ActiveTasks when a valid resource and worker are found for the Task. Tracks reserved and unreserved resource instances by listening to appropriate world events This is the barest essence of my idea so far. But I have some concerns... - Tracking every resource instance could get very expensive, not to mention checking distance between every worker, the JobGiver, and every potential resource (Realistically I'd probably pick one to prioritize; minimum distance from resource to JobGiver, or minimum from worker to resource) - Should the JobGiver be responsible for checking its own inventory contents, and marking tasks complete if the resources are already available? Or should the JobManager handle that? - Relying on events means that I'll have to make special cases for anytime a player can mess with something; taking a reserved resource, for example. But that'd just be re-queuing the Task It's also worth pointing out that the reason for tracking resources is because we need to reserve them; we don't want two Workers trying to grab the same resource, and we don't want Workers taking resources that are stored and about to be used for some Recipe Anyway, I'd love any ideas or critique on the high-level design
2 Replies
"no plan survives contact with the enemy"
"The map is not the territory"
not to be flippant, but I think if you work on the basic prototype of your idea, it will settle a lot of your concerns, just because you'll find that when you get to the point where you'd implement your above stated worker system, that your idea for the game has evolved so that it's no longer exactly as you currently envision
also generally, don't track the resources, instead track the intent to aquire resources. then when performing the task it can find the best suited resource at that time.
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.