Orders system, stack language, orders feature suggestion.

[Jasper1984]

The current order system seems to work nicely. I suppose (have not read any source of it yet) it works by having a list of orders and popping one off when an order is done. (And adding to end when repeat)

I am programming an rts myself currently. And i was thinking about orders. What bugs me is how far to go into the 'language of orders'. I thought in terms of how i would like to see springs orders here are some:

• Repeat. AFAIK currently it is not an order. Why not make it an order, and allow shift+repeat to initiate repeat when the order comes.
• There is the minelayers script i saw on youtube. How would we do this in orders? Well, if we could code orders, we could say:

  Code: Select all

  poll-pos radius area-safe
  while
    randomize-order do position1 build-mine
                 do position2 build-mine
    end-randomize-order
  else
    safe-position move end-while

  This is a stack language, (Improvised a little, sorry should have learned forth more thurroughly.) (Whitespace does nothing, of course.) While recognizes the else and end-while to decide what to put on the stack. Randomize-order executes each of its entries randomizing the order it is done.(Dont get all the minelayers do the same spot.) Here i assume that the building orders would not be (attempted to be) executed when there is already a mine. (Also assumes that move will only transmit if unit is not already there/ can do better getting there/memoizes previous move order.)

The problem is now, how far to go with the stack language? Giving people the stack would give them incredible power, but it also has to be synced/transmitted, and can be abused to drain huge amounts of cpu power/overflow the stack.

I guess you could say: area-safe, repeat may only be done automatically once in 5 seconds(waiting until then), move once in 0.2 seconds, etcetera. And all commands are cleared when the stack is overflowed; users should prevent that. Perhaps stack languages is what we are lead too here, but it is not really the language we should choose.(Well since it is already there Lua would be the first choice.) In that case this post becomes a orders feature request for if-area-clear, fixing build-order when building can not be build anyway.
One thing does push us in the direction of Lua, people probably won't think of this code during the game, and because it would probably mean a lot of work. In my project, there is another even stronger thing pushing me away from stack languages; it is written in common lisp .

I feel the need to add another example:

Code: Select all

combat-group mean-pos-group combat-group radius-group area-safe
while
   combat-group repair combat-group mean-pos-group
   combat-group radius-group area-reclaim
else
   safe-position move end-while

Note that the code is a bit clunky, and, although i have a good idea how stack languages work, i really should learn Forth. Please do not be too harsh on mistakes.. Also, note that this thread is somewhat an open letter about the order system. (Perhaps i should have looked for what you already documented about it :))

[det]

You might find these links interesting:

http://en.wikipedia.org/wiki/Joy_programming_language
http://tunes.org/~iepos/joy.html

[Jasper1984]

@det: Thanks for the links :) joy might indeed be a better language for learning stack languages. Edit: Talk about stack language would deserve its own thread.

I feel like i need to explain the open question a little better: If you would have to redo the orders system would you do it differently?

What if i requested the feature 'when area safe, do next command', well i am not, because i know it can never guarantee that units will keep away from enemies: 'repeat when-area-safe build-mine-1 build-mine-2 ... move-to-safe-position'. Will only stay away when the area is not safe, not run away when laying mines. Would you try to change this? Via a stack language?

[Tobi]

Repeat. AFAIK currently it is not an order. Why not make it an order, and allow shift+repeat to initiate repeat when the order comes.

Repeat is a non-queueable command in Spring, similar to firestate (hold fire, return fire, fire at will) and movestate (hold pos, roam, etc.). These type of commands are processed immediately when they are given, and just set a state variable on the unit's CommandAI.

Then if repeat is set every queueable command will get pushed on the queue just after it is popped because it finished.

I think it's trivial to make repeat a queueable command.

I feel like i need to explain the open question a little better: If you would have to redo the orders system would you do it differently?

When I'd redo the orders system I think I'd make command queues separate objects to which units can be assigned arbitrarily. (ie. a huge group of units could have a single queue when you command them all at the same time)

Then it would require little extra code to allow fixed command queues not linked to any unit, to allow command queues of e.g. builders to keep existing when the builder dies, so you could assign the entire queue to a new builder (or multiple new builders).

Also from start I'd build in support for modifying commands later on (ie. dragging waypoints) withing rebuilding entire queue, and inserting/removing commands from begin/middle/end of queue.

[imbaczek]

If I was designing an RTS, I'd start from an UI standpoint. IMHO all UIs for RTSes suck, spring tends to suck less thanks to all the widgets (God knows it sucked before trepan.) Once you come up with an UI than sucks even less, you can start thinking up what it takes to implement it cleanly, but not limiting extensibility.

[trepan]

State commands can already be queued using CMD.INSERT.

[Jasper1984]

When I'd redo the orders system I think I'd make command queues separate objects to which units can be assigned arbitrarily. (ie. a huge group of units could have a single queue when you command them all at the same time)

Excellent idea! Would have to rethink how i am going to store my pathfinding results, though.(Those were going into the order list before.) Sharing pathfinding results does not sound like a good idea, the road might be to busy, and i might want a custom-formations type-working anyway.

If I was designing an RTS, I'd start from an UI standpoint.

I myself started with simulation and the map system. I strive to keep things flexible; keep all information available for the units. The drawing/simulation routines have access to the object itself, the game (simulation)state, the quadtree-node, -position, -element.(Made a quadtree with multiple levels per node.) Of course, normally, you try to restrict what information is known to a function, but in case of timestep/drawing functions, it is not known what information they need, and they can still just call other functions that do not ask for more information then they need. This way, the UI should be able to meet any demand.
If you started programming the UI first, you would need to make an interface to the simulation without making the simulation first.(At least for some parts) Testing would force you to use unit-tests somehow.(Well, unit tests can be a good idea. Sometimes.)

State commands can already be queued using CMD.INSERT.

Excellent! I am a bit confused what CMD.OPT_* in params[2] does. Is it UI related? (Strikes me as a little strange combining UI and giving commands.)

As for my answer to the question, i think i will not put any stacklanguage in, just using unit state. I have thought how i can do the minelaying routine that way too: (Add commands 'random-order(-end) while-safe(-end)) then:

Code: Select all

move(safe-pos) while-safe(area) random-order lay-mine(pos1) lay-mine(pos2) ... random-order-end while-safe-end

Can do the minelayer thing. Probably will even add a little 'command-line' where players can -for-instance- enter 'attack' -> icon turns into attack-icon -> click makes it attack, shift-click on back of stack.

[imbaczek]

If you started programming the UI first, you would need to make an interface to the simulation without making the simulation first.(At least for some parts) Testing would force you to use unit-tests somehow.(Well, unit tests can be a good idea. Sometimes.

No way I'm suggesting _programming_ the UI at start, I was saying about _designing_ it, in a pen and paper sense. Programming it is a completely different story, something that should be either done on a "what's needed to test" basis during development, gradually gaining importance when nearing release.

Unit tests are always a good idea, but it's kinda hard to do in an RTS.