You can also add recuring tasks - the easiest way will probably be to just add the task with timeout again to the graph each time it is done.So There are a couple reasons I play with ASCII: You can also add priorities to nodes, and the task may be to find such ordering, among all orderings that fullfil the dependencies, that has the bigger priority nodes performed first. In such case the algorithm should probably indicate to the player that these tasks can't be done. It's also possible that there are no way to sort a graph topographicaly - this happens when there are cycles in the graph (you have no wood, to get wood you need to chop a tree, to chop tree you need axe, to make axe you need wood). Now, there are many such orderings usually (because some nodes have no dependences and can be put anywhere, and some nodes have the same dependences and aren't dependent on each other so they can be in any order between themselves, and any node can be put in any place after it's dependencies are done, and before nodes depending on it are done ). You want to do all the tasks, so you need to produce SOME ordering of the nodes that is topographicaly OK (the depending nodes are after the nodes they depend on). You have a graph, each node is a task that needs to be done, and some nodes depend on some other nodes (this is represented by an edge in the graph from depending node to the node it depends on). So this is basicaly topographical sorting problem. if unit dies at ANY step, the resource he locked must be released) Each task needs a proper locking and unlocking of resources (f.e.Very similar tasks are within one class and ruled by few IFs (deliver to house or deliver to unit).Generally one task per module, but similar tasks are in one module.Each task implements abstract Task class with just a few common methods (create, execute, save, load).Everything is hardcoded (no need to write parser, interface methods, backwards compability).Action ends with either Done or Aborted state and passes it to the Task.Tasks give unit actions (go there, enter, exit, go here, stay, work, go).Start %animation_6% inside for %time_2%.Take %req_resource1% in %req_count1% count.Work on place using %animation_2% for %time%.Go to that location using %animation_1%.Workplan says what kind of resource unit must pick, from what kind of house, using which walk animation, using which work animation, time to work and all such details. In case of deliveries e.g.: WorkTask operates with a WorkPlan. If you can make sequences pretty general, there's not much of a spaghetti code.
Lager dwarf fortress ascii code#
Whether you implement this in code or in an external file like XML is up to you.
Logically, you can represent these commands as a flow chart, that is run from the top each time, and what you do depends on whether you answer yes/no at each step.
0 kommentar(er)
