You missed the part where you manage the work abort.
For loop I mean an action definition that checks every x seconds the AI of the unit (worker).
I'll try to re-write my list being more specific
1) Each time a unit is created, an AI action definition is run on it and keeps looping every 0.5 secs until it's dead.
2) This AI decides the task to assign to its unit if it has the idle behavior (using job priorities and distance check)
3) When a unit get assigned to a specific task:
a) Create a dummy unit in the position of the specified work tile (if it doesn't exist)
b) Assign a behavior to the worker that specifying the task type
c) Assign behavior to the dummy unit that says it's assigned to a worker
d) Assign the dummy unit as follow target of the worker
e) Run action definition loop that checks if the dummy unit still has the same worker assigned, if something changed remove the "assigned" behavior from the dummy unit
4) When point is reached make another check and verify that the job can still be done
5) Complete the task
6) Check for the next task to do, trying to keep the same task type as the previous
1) Assign task to a worker
2) Assign the target to the worker
3) Assign a specific behavior to the worker that stores his current task type (conquest, dig, fortify, etc)
4) Start an action definition that loops, storing the worker, his target and his current task type (behavior type)
5) While looping check if the worker has the same task type and the same target, else re-assign the target task to another worker
Using the auto cast you would have the problem of imps trying to achieve the same task at the same time.
For the AI I'm going to use looping triggers.
Each time you assign a work to an imp you flag a variable to 1 (or add a behavior to the work dummy unit) and start a looping trigger that checks if the worker is still alive and with the same task. If something happened re-assign the work.
What's the best way of linking 2 units using data editing? I mean to check with triggers if the unit is still targeting another unit...
Let me know about how such a system works once you get one. It ain't exactly easy to make.
I've spend all morning on trying to remake the map. Basically I updated the entire code base in order to address conflicts I would get later on during development such as having to make silly workarounds in order to incorporate building, and selling etc. Anyhow, it works more fluently now and will work with future changes.
EDIT: Well, let's take the farm as an example. Basically you'd loop through all farm tiles and calculate their distance from the creature. Once you get the closest one simply check the size of the farm via that tile and if it isn't full already then allow the creature to come.
That's a quite huge calculation and it must be done constantly by the AI, we should find an optimized way to do that.
As I said we can check just the border room tiles (adjacent to walkable tiles) and make a comparsion with that. I think that the room size check should be done before you start calculating the distances.
I'm still in brainstorming phase, thinking to all the variables I must store. Today I decided that I will use an array struct that stores all tile variables and I'll do special functions to change that values easily.
The only way possible for wall selecting is the one you actually did with mouse click and mouse release + single click. You could use the camera lock to mouse to something cooler but I don't like this method.
Yep but the problem is to associate these room variables to tiles, I think we should assign unique IDs to each room tile.
It will be hard to update ids when rooms get splitted or joined but I suppose I can manage it :P
Let me know about how such a system works once you get one. It ain't exactly easy to make.
I've spend all morning on trying to remake the map. Basically I updated the entire code base in order to address conflicts I would get later on during development such as having to make silly workarounds in order to incorporate building, and selling etc. Anyhow, it works more fluently now and will work with future changes.
EDIT: Well, let's take the farm as an example. Basically you'd loop through all farm tiles and calculate their distance from the creature. Once you get the closest one simply check the size of the farm via that tile and if it isn't full already then allow the creature to come.
That's a quite huge calculation and it must be done constantly by the AI, we should find an optimized way to do that.
As I said we can check just the border room tiles (adjacent to walkable tiles) and make a comparsion with that. I think that the room size check should be done before you start calculating the distances.
A spider system would easily handle that. Just crawl through each tile connected to the room and give it a occupation value to only allow a certain number of creatures to be directed there at one time. How to check how large the rooms are I'm not sure.
What's a spider system? lol
However I was meaning that, depending on the position of a unit he should go to the nearest rooms he's interested in.
For example the unit want's to eat, what's the nearest hatchery to it? U can't just check the distance from the middle of the room but you must do it with all room external tiles :|
I think that we require a system that stores the amount of rooms with their type, location and size. That's required to choose what kind of monsters are attracted and what room variable must be edited when I modify the room shape.
Since workers will have to be able to dig from all angles you could simply make their colission big enough to only fit 3 on each sides which I decided to go with. Then again, sometimse they can be misplaced and only allow 2 guys at a time. Other than that it works nicely.
I dont like this solution :D
Consider that trying to dig on a single square wall (4 faces) for example of gems it will allow worker to dig from diagonal positions too.
I think i'll use 4 dummy invis units like minerals with max 3 workers a time, when the resources go down the wall is destroyed. I can share the resources between the 4 spots with triggers ;)
Edit:
Now I'm thinking to the detection of room sizes and keeping the AI informed on rooms position.
That won't be easy :|
I think I have the overall idea, however I'll try to work thinking to the whole engine and the small mechanics that can cause problems later when ignored.
So I started writing down all variables i need to store and how to store them.
I'm still trying to figure out how to limit the amount of workers to 3 for each wall face
Edit:
Maybe something that has to do with harvesting that limits the amount of workers on the same spot!
(Pan) - I got a question that I've been trying to figure out since the beta: does anybody know how to change cliff heights mid-game (triggers, actors, abilities, etc.)?
Changing cliff levels during run-time would require significant changes and we would only add support for this if there was a strong need for it. ------------
Sad :|
Ok I'll start working with your method then... years will be required to wait for blizzard :(
Nope, no terrain support as of yet. How will you tackle this obstacle or will you delay your project until Blizzard decide to implement them?
Well, you know, you can always just use actors and use multiple deformed models to simulate terrain walls.
Yeah fuck that, today I started with game design and I suppose I'll start to develope it allowing me to choose between actors or terrain if blizzard is going to implement that :|
I'm really sad :(
Hoping that won't require 2 years as it did on WC3 TFT
If tomorrow blizzard will patch the editor with terrain cliff height change triggers I'll start with my DK map too.
Hoping those editor changes will be HUGE
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Oh ok, so you are threading units AND tiles as I said :D
And what about the work abort?
Are you still here red? :D
You missed the part where you manage the work abort.
For loop I mean an action definition that checks every x seconds the AI of the unit (worker).
I'll try to re-write my list being more specific
1) Each time a unit is created, an AI action definition is run on it and keeps looping every 0.5 secs until it's dead.
2) This AI decides the task to assign to its unit if it has the idle behavior (using job priorities and distance check)
3) When a unit get assigned to a specific task:
a) Create a dummy unit in the position of the specified work tile (if it doesn't exist)
b) Assign a behavior to the worker that specifying the task type
c) Assign behavior to the dummy unit that says it's assigned to a worker
d) Assign the dummy unit as follow target of the worker
e) Run action definition loop that checks if the dummy unit still has the same worker assigned, if something changed remove the "assigned" behavior from the dummy unit
4) When point is reached make another check and verify that the job can still be done
5) Complete the task
6) Check for the next task to do, trying to keep the same task type as the previous
@redmarine: Go
Yes that should work, so that's what I would do.
1) Assign task to a worker
2) Assign the target to the worker
3) Assign a specific behavior to the worker that stores his current task type (conquest, dig, fortify, etc)
4) Start an action definition that loops, storing the worker, his target and his current task type (behavior type)
5) While looping check if the worker has the same task type and the same target, else re-assign the target task to another worker
Using the auto cast you would have the problem of imps trying to achieve the same task at the same time.
For the AI I'm going to use looping triggers.
Each time you assign a work to an imp you flag a variable to 1 (or add a behavior to the work dummy unit) and start a looping trigger that checks if the worker is still alive and with the same task. If something happened re-assign the work.
What's the best way of linking 2 units using data editing? I mean to check with triggers if the unit is still targeting another unit...
That's a quite huge calculation and it must be done constantly by the AI, we should find an optimized way to do that.
As I said we can check just the border room tiles (adjacent to walkable tiles) and make a comparsion with that. I think that the room size check should be done before you start calculating the distances.
@Forge_User_20974461: Go
I'm still in brainstorming phase, thinking to all the variables I must store. Today I decided that I will use an array struct that stores all tile variables and I'll do special functions to change that values easily.
The only way possible for wall selecting is the one you actually did with mouse click and mouse release + single click. You could use the camera lock to mouse to something cooler but I don't like this method.
Yep but the problem is to associate these room variables to tiles, I think we should assign unique IDs to each room tile.
It will be hard to update ids when rooms get splitted or joined but I suppose I can manage it :P
That's a quite huge calculation and it must be done constantly by the AI, we should find an optimized way to do that.
As I said we can check just the border room tiles (adjacent to walkable tiles) and make a comparsion with that. I think that the room size check should be done before you start calculating the distances.
What's a spider system? lol
However I was meaning that, depending on the position of a unit he should go to the nearest rooms he's interested in.
For example the unit want's to eat, what's the nearest hatchery to it? U can't just check the distance from the middle of the room but you must do it with all room external tiles :|
I think that we require a system that stores the amount of rooms with their type, location and size. That's required to choose what kind of monsters are attracted and what room variable must be edited when I modify the room shape.
I dont like this solution :D
Consider that trying to dig on a single square wall (4 faces) for example of gems it will allow worker to dig from diagonal positions too.
I think i'll use 4 dummy invis units like minerals with max 3 workers a time, when the resources go down the wall is destroyed. I can share the resources between the 4 spots with triggers ;)
Edit:
Now I'm thinking to the detection of room sizes and keeping the AI informed on rooms position.
That won't be easy :|
I think I have the overall idea, however I'll try to work thinking to the whole engine and the small mechanics that can cause problems later when ignored.
So I started writing down all variables i need to store and how to store them.
I'm still trying to figure out how to limit the amount of workers to 3 for each wall face
Edit:
Maybe something that has to do with harvesting that limits the amount of workers on the same spot!
(Pan) - I got a question that I've been trying to figure out since the beta: does anybody know how to change cliff heights mid-game (triggers, actors, abilities, etc.)?
Changing cliff levels during run-time would require significant changes and we would only add support for this if there was a strong need for it.
------------Sad :|
Ok I'll start working with your method then... years will be required to wait for blizzard :(
Yeah fuck that, today I started with game design and I suppose I'll start to develope it allowing me to choose between actors or terrain if blizzard is going to implement that :|
I'm really sad :(
Hoping that won't require 2 years as it did on WC3 TFT
If tomorrow blizzard will patch the editor with terrain cliff height change triggers I'll start with my DK map too.
Hoping those editor changes will be HUGE