Base building in a RTS based on a queue of orders
-
I think a saw once a file made of a queue of commands for a strategy game that did that, it was more than a decade ago so it’s very vague in my mind. What I’m sure about is that it wasn’t script what I saw. My question is if the file is structured as follows: Build SCV Build SCV Build Barracs Build SCV Train marine Etc. How do you build SCV number 4 in the queue before building Barracs is over. When either training a unit is over or constructing a building is completed you generate an event which can be used to move on to the execution of the next item in the queue. But how do you proceed when you don’t want to wait until the execution of the previous command is over?
I create objects with one or more "counters"; that count down or up (time remaining; time elapsed). I handle every object at least once during a "frame" (if it is "active"). Time remaining is when they are performing an action that must "expire" (e.g. change in formation) before going on to the next "order". Time elapsed is how long they've been at something (moving, double time, firing, fighting, etc.). So, no "events"; just changes in state or "levels of condition" (fatigue; loss; ammo) that are monitored. The only "orders" I have needed so far are for "waypoints" on a given route. ("AI" :) and the user does the rest).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I create objects with one or more "counters"; that count down or up (time remaining; time elapsed). I handle every object at least once during a "frame" (if it is "active"). Time remaining is when they are performing an action that must "expire" (e.g. change in formation) before going on to the next "order". Time elapsed is how long they've been at something (moving, double time, firing, fighting, etc.). So, no "events"; just changes in state or "levels of condition" (fatigue; loss; ammo) that are monitored. The only "orders" I have needed so far are for "waypoints" on a given route. ("AI" :) and the user does the rest).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Thanks Gerry, that gets me a bit closer to what I’m trying to do even if I’m not using exactly the same approach. In this case what matters most is the order in which the money are spent so as soon as building the Barracs has begun you can jump to the next item in the queue if you have the money
-
Thanks Gerry, that gets me a bit closer to what I’m trying to do even if I’m not using exactly the same approach. In this case what matters most is the order in which the money are spent so as soon as building the Barracs has begun you can jump to the next item in the queue if you have the money
I have "various" queues. If I need to rotate over time, the angle is "queued" as a counter. During each frame (time interval / slice) the angle is reduced and applied to the object. Since my "game" can run at anywhere from 1x to 40x, it's all a function of time. The route waypoints are queued and consumed at a rate equal to the time it took for the last one; which varies with terrain. One queue can direct multiple objects (object chain of command). The guns have to be unlimbered before they can fire ... a queue on itself. One queue is fatigue ... which increase with rapid gaits, and only decreases with reduced movements.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I have "various" queues. If I need to rotate over time, the angle is "queued" as a counter. During each frame (time interval / slice) the angle is reduced and applied to the object. Since my "game" can run at anywhere from 1x to 40x, it's all a function of time. The route waypoints are queued and consumed at a rate equal to the time it took for the last one; which varies with terrain. One queue can direct multiple objects (object chain of command). The guns have to be unlimbered before they can fire ... a queue on itself. One queue is fatigue ... which increase with rapid gaits, and only decreases with reduced movements.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
I think I got it figured. When a unit is killed the AI has to build another unit to make up for it. If you use the unit death event to start building a new unit you might not have the money to do it, so you have to queue the training for later. Implementing this behavior takes extra code. My guess is that in the case of the method presented in the opening post a capacity limit for units is created. As the processing moves down the priority list the capacity limit for various units increases. The computer checks if the actual unit number the AI player has and capacity limit number match, if they don’t ( due to units dying) units are trained.
-
I have "various" queues. If I need to rotate over time, the angle is "queued" as a counter. During each frame (time interval / slice) the angle is reduced and applied to the object. Since my "game" can run at anywhere from 1x to 40x, it's all a function of time. The route waypoints are queued and consumed at a rate equal to the time it took for the last one; which varies with terrain. One queue can direct multiple objects (object chain of command). The guns have to be unlimbered before they can fire ... a queue on itself. One queue is fatigue ... which increase with rapid gaits, and only decreases with reduced movements.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Hi, thanks for feedback > if I need to rotate over time I guess you can queue a lot of things. If we talk about rotations a place where you could use that would be when you want your units to face in the direction they are walking towards. In my game the graphics are as basic as they can get. A unit is just a small square. If I were to change the graphics to something slightly better, for unit look at I would probably be using sudden changes of rotation, the method used in Blizzard RTS games. Returning to base building... a question that has got me thinking is the problem of training low level units vs training high level units. When the AI player is far into the tech tree and has advanced units available for training it chooses to replenish the low level units lost in the battle too. ( a human in the same situation usually chooses to train only advanced units)
-
Hi, thanks for feedback > if I need to rotate over time I guess you can queue a lot of things. If we talk about rotations a place where you could use that would be when you want your units to face in the direction they are walking towards. In my game the graphics are as basic as they can get. A unit is just a small square. If I were to change the graphics to something slightly better, for unit look at I would probably be using sudden changes of rotation, the method used in Blizzard RTS games. Returning to base building... a question that has got me thinking is the problem of training low level units vs training high level units. When the AI player is far into the tech tree and has advanced units available for training it chooses to replenish the low level units lost in the battle too. ( a human in the same situation usually chooses to train only advanced units)
Yes, I use rotation to align the front / line of battle. They're "blocks" too, but are to scale as to front (line of battle) and depth (column of route). In terms of cheap versus advanced units, AI could use cheap units for a diversion while the advance units attacked the primary target. The first "phase" of each time interval is evaluating possibilities and threats; which starts with (in my case): is anyone firing on me?
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I think I got it figured. When a unit is killed the AI has to build another unit to make up for it. If you use the unit death event to start building a new unit you might not have the money to do it, so you have to queue the training for later. Implementing this behavior takes extra code. My guess is that in the case of the method presented in the opening post a capacity limit for units is created. As the processing moves down the priority list the capacity limit for various units increases. The computer checks if the actual unit number the AI player has and capacity limit number match, if they don’t ( due to units dying) units are trained.
My "event" (if you call it that) happens when the loss inficted by the attacker is applied to the target. At that point, the target: maintains ground / continues to advance; is dispersed, temporarily or permanently; is shattered; is captured; is pursued; or is destroyed. The state of the various parties determines what can happpen in the next "round". If was to spawn or seed something, it would be "triggered" here. (So, let's say I use triggers instead of events).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Yes, I use rotation to align the front / line of battle. They're "blocks" too, but are to scale as to front (line of battle) and depth (column of route). In terms of cheap versus advanced units, AI could use cheap units for a diversion while the advance units attacked the primary target. The first "phase" of each time interval is evaluating possibilities and threats; which starts with (in my case): is anyone firing on me?
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
> Yes, I use rotation... Sounds like more than math for beginners so I really can’t engage with you in a debate about it. Regarding your other post I think we are on the same page.
-
> Yes, I use rotation... Sounds like more than math for beginners so I really can’t engage with you in a debate about it. Regarding your other post I think we are on the same page.
At the very least, one must allow 15+ seconds for any change in formation. I don't animate everything; I will show different icons on my blocks depending on the status of the block: marching; limbering / unlimbering. If you're in realtime and to scale, some movements are hard to see from a user point of view so you have to be more visible. Nothing wrong with doing an "instant" turn; you just have to pace it properly (i.e. it still takes time; use an hour glass icon + another one on the block (which is simply text using font icons; e.g. Segoe UI Symbol / Emoji).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I create objects with one or more "counters"; that count down or up (time remaining; time elapsed). I handle every object at least once during a "frame" (if it is "active"). Time remaining is when they are performing an action that must "expire" (e.g. change in formation) before going on to the next "order". Time elapsed is how long they've been at something (moving, double time, firing, fighting, etc.). So, no "events"; just changes in state or "levels of condition" (fatigue; loss; ammo) that are monitored. The only "orders" I have needed so far are for "waypoints" on a given route. ("AI" :) and the user does the rest).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Certainly if you have refuted a significant proof that has been in place for perhaps 80 years or more then you should immediately write it up and submit the article to one of the formal mathematical journals. It would be an astounding achievement. It would likely be submitted for several significant awards (along with monetary awards) and would likely lead to you getting quite a few job offers from both universities and companies.
Regards:Pubg Name Generator (symbols,nicknames,copy paste)[^]Pubg Name Generator