Page 1 of 1

Groups and macro-orders proposal

Posted: Sat Jun 12, 2004 2:48 am
by vishnou00
I thought of posting this in the programming forum, but the topics there were more about the implementation than the design, and this post may be considered a crazy idea. The vacabulary used should appeal to the programming crown, but still written with plain english syntax.

I would ask programmers to comment on what is already done and how and what wasn't done and why.

I will update this thread with clarification, but feel free to ask and comment. The idea is early in development, there may be conflict in the vocabulary.

Groups and macro order:

-You can give macro order to groups
-everything belongs to its self-group as soon as you give the order to create the entity (order colonisation, ship building, group merging)
-Groups are destroyed manually.
-Tools are provided to assist mass destruction of groups (Destroy all empty self-group?)
-You can replace/merge the orders of an empty group to another group (including self-groups).

macro order include:
-copy orders (from another group)
-merge orders
-join/create a group
-clear orders

-wait x turn
-wait for turn x

-move (does pathfinding)
-explore (move to nearest unknown system)
-patrol (go to nearest unfriendly/hostile ship
-change encounter behavior

-add/reset/remove production
-change focus

-macro orders apply mini-order to every entity. The game apply the mini-order to the world.
-macro order are or are not be repeated upon completion
-macro order may applied once (it assign mini-order to self-group but doesn't reapply them automatically).
-macro orderer reports the applied mini-order

Tools are supplied to create groups.

every groupable object contains:

- mini-order list
- a group (which is a self group)

a group contains:

- group membership (ordered) list
- 4 macro-order lists: outertop, outerbottom, innertop and innerbottom

mini-order compilation:
- 2 temporary macro-order deck (double ended queue) (top and bottom) are created.
- create a temporary list of group that the groupable object is member of, starting with its self group, then its first membership group in the list, that group's membership list first item, etc.
every time a group is added, it is checked that the group isn't alreaady in the list.
- the group order queues are added to the temp queues that way, starting with the last group:
-outertop at the top of the top deck
-innertop at the bottom of the top deck
-innerbottom at the top of the bottom deck
-outerbottom at the bottom of the bottom deck
- the 2 temp queue are merged (top on top of bottom) in a master macro-order list
- the macro order are then processed from the master macro-order list into the mini-order list

Posted: Sat Jun 12, 2004 7:07 am
by drek
We already have Fleets which contain any number of ships. I'm not seeing how groups of Fleets would be advantageous.

Posted: Sat Jun 12, 2004 10:36 pm
by vishnou00
A group can be made of ships at different locations and they may recieve the same order.
15 fleets are at 5 different location and you want them to move to attack one other location, with a randez-vous point in between.

With groups: You can select them all (ie create a group with all of them), order it to randez vous at some point, wait for the whole group to arrive and then move to the target location for the attack. You gave all those orders the same turn and your attack is hassle free.

Without groups, you order 15 fleet movements (or less if you merge fleets, but still at least 5 move order) to the randez vous point, then (some turns later) you check if all the ship arrived and if so, order them to move to the final target (again merge/move orders).


You can also give orders to ships as soon as the construction is ordered (so you don't have to remember what they were for).
You build a colony ship to colonize Regelis III and then 2 freighters with supplies.

With groups: You order the construction of a colony ship with the following orders: load colonists, move to Regelis, colonize planet III. The same turn, you order construction of a freighter with the following orders: load supplies (minerals/food/colonists), move to Regelis and then drop supplies to planet III. You can apply the same orders to another freighter (built or not).

Without groups: You order all your constructions (colony ship, 2 freighters). When the colony ship is built (one or more turn later), you load colonists and order it to move to Regelis and then colonize planet III. You also keep track of the freighters building: you either wait for the 2 of them to be completed, merge them and then order them to load-move-unload to Regelis III OR you supply the same orders two times when each freighter is built.

You may not need to load colonist to colony ship (because it is automatic/embedded to colony ship), but the result is the same, more hassle and manipulation sessions.

Posted: Sun Jun 13, 2004 9:55 pm
by Geoff the Medio
Having post-build orders associated with a ship build request (orders that will be given to the ship upon completion) is something I support.

What does that have to do with groups of ships at different locations though?

Unless the group can include ships that don't yet exist, then it seems like you're describing a macromanagement aid/tool that automatically gives orders to ships as they're built, according to what you specify when you order the ships built (or order a colony made, which spawns the ship-build order without your direct input)

In any case, why not just have a UI element listing all fleets (the Fleets Window):

Fleet Name (at Starsystem Name)

allowing you to effectively "group select" by shift or control clicking and then giving a series of orders like: move to rally point, (wait for all ships/fleets to arrive), move to target, attack. The UI element / macro tool would then give these orders to all fleets you had selected.

It sounds like you want "groups" to be a more permanent thing, which seems, to me, unnecessary.

Thought: It would be necessary to have the orders be "smart" such that if, half way to the rendezvous point, you diverted one of the fleets, that the rest of the fleets wouldn't wait endlessly for the diverted fleet to arrive before continuing with the orders they had been given. Perhaps that would be a reason to have groups of fleets? Could be avoided by updating orders though...

Posted: Mon Jun 14, 2004 5:31 am
by vishnou00
I'll answer Geoff the Medio's post paragraph per paragraph:

Thanks, I like support! :)

The two examples (separated with '========') describe two aspects of my proposal, namely that:
-groups aren't tied with the existence of entity (orders can be assigned before creation and reused after destruction)
-groups aren't tied with location of entity (units don't have to be at the same place, as with fleets).

I see it more like a management model for everything order related (an order being any decision by the player that is not empire wide, such as research and government related decision). And I don't think it will deal with combat when the project will be there. It could also be used by the AI.
The purpose is reducing many aspects of micromanagement related to giving orders.

4 to 6.
I see group making (the action you describe with the list) somewhat of a repetitive task (say, you want to use one selection often). I also fear the UI list bo be limited someway. I plan to use such UI element to select units to be in groups. I big feature would be to use groups to do filtering.
For instance, listing only certain ship design. You could sort the list by design, cull every disigns you aren't interested in and then sort it by ETA (without getting every ship type in the way).

Groups being a pattern of orders (as well as a group of ships), they sould be reusable. This is why I wouldn't want them to disappear without user intervention.
I would see them managed like email: you keep them all, but only the really useful one standout. Those of lower relevance (old, not useful) are stashed for later consultation.
I also don't see a disadvantage to not keeping them (it's just more coding I'm willing to do). I don't consider data size a matter of concern (especially after seeing how accepted the uber heavy animated planets).

The macro orderer should report a lot of thing that have gone wrong with order execution:
-target disapeared (out of scanner range)
-group member or target has changed state (been destroyed/captured)
-things will not be done, ever (a colony building ships has been bombed to stone age)
Appropriate course of action would be proposed (cancel order, destroy group, go to last known location, remove from group). This would have to be coded in the macro-orders themselves.


Some macro order design:
Explore order:

When I first tried to play FreeOrion, I wanted to see the world. So, with my starting scout ship, I ordered it to go to an adjacent system. After arriving at the system (which have two starlanes) it just stops there, not going to the next one. Then I wonder "the decision to go to the next system is trivial, why should I have to go through it manually. I mean, it's a scout, it's meant to explore". So I go with this idea that when an exploring ship arrive to an unknown system (with two starlane), it proceeds to the next one.

But that alone is not complete. What about unknows systems with more than two starlanes? You could go at random, but there may be a better way to decide. I think that there is no reason for one to be better than another take the one with the shortest starlane. But it is not trivial anymore, so I'll have it report while proposing to go to the nearest one.

Then I think "there may be dead-end of unexplored world", but the solution is half-devised with the choosing of the shortest starlane. Just change that to "go to the nearest unknown world" and you've got quite a competent helper: transparent (it reports when it decides), non-intrusive (the macro-order reporter would be one big list of message) and useful (it's quickly a chore to direct 10 or so scouts to explore the galaxy).

So in rule form:
-execute upon arrival to an unexplored system
-report to the SitRep-like macro-order reporter (possible messages: dead-end, two starlane trivial decision, >2 starlane non-trivial shortest route based decision, no more unexplored worlds, ETA to unexplored world is very long)
-go to the nearest unexplored world

It actually didn't happen quite that fast, but it shows the way I see macro-order design: find an annoyingly trivial task and devise rules that reflects the way you deal with it.


Group potential usage:
Group as target:

You could have a couple of border world you want to reinforce your border with a couple of fleets. You create a group of those systems (Border group), another for the ships you want to send (Reinforcement group). Then you order the Reinforcement group to move to the Border group.

The I can think of two behavior of such a move order:
-each ship go the nearest system of the Border group, thus optimizing ETA
-the order sends a minimum (from 0 to Reinforcement group size/Border group size, rounded down) quantity of ship (may be power rating weighted) to each system, while minimizing ETA, but mainly getting the border evenly defended.

Posted: Sun Jul 04, 2004 6:07 pm
by vishnou00
Seems I'll back off from game design for a while. But still, I think macrotools are something that may be useful for the game.

Since they aren't anywhere in the roadmap, I wonder if the community is interested. This is not work I try to throw at the programming team as I would do as much as I can (I'd still apreciate a few pointer as to where to begin and how would it fit in the project, tough).

So, members of the FreeOrion community, do you think it would be a good idea to implement some macrotools, based on this proposal or otherwise?

Posted: Mon Jul 05, 2004 6:41 am
by PowerCrazy
vishnou00: Its obvious that you have put a lot of work and consideration into each one of your posts. However, the very nature of macrotools is simliar to AI. You can't have either be effectve until the system they will be operating on is complete. Macro-tools in the broad definition are extremely useful. However, you shouldn't program the game around teh tools, rather you should program the tools around the game. Thus when most of our systems are complete Econ, Colonizing, Combat, General Empire management, etc. There will be areas that were passed in the numerous design/public review threads that are important to the game and cannot be abstracted away. Thus your Macro tools make an entrance.

For example in Moo2 imagine how much easier it would have been to when you colonize a planet you have a drop down box with various macros that you have defined in the game. And you click one of your build queus and off you go. That makes managing the game take about 1-2 minutes instead of the usual 5-10. That is a macro tool, ALL games can use them and benefit from them.

However they are not and SHOULD NOT be designed in from the beginning. A macro by definition is user defined for a particular situation that comes up frequently, similiar to Python and Perl scripts. You don't design the tools and then find the problem. No, you find the problem and then design the tools.

Thus no one here is going to say macros are useless and should not be in the game. What they will say though is we are not goign to design the game with macros in mind (optimally we won't need any, but realistically we will). So just take it easy as far as macros go. Lets get the system solidified/balanced/functional and go from there.

Posted: Mon Jul 05, 2004 7:11 am
by vishnou00
I was not thinking doing macro tools about non designed feature right now.

What I had in mind was more along the line of ship movement and coordination (moving multiple ships to multiple locations and automovement, like patroling and exploration), wait (for event and defined delays), note to self (sending player composed sitrep message to the player) and dispatching orders before creation (right now only ships, but eventually production center).

My assumptions are:
-fleets recieve movement orders
-a fleet is a bunch of ships at the same location that share the same orders
-ships construction is ordered
-all players' orders are applied simultaneously. By simultaneous, I mean "not like Sid Meyer's games", where a player's order is applied as soon as he decides, and each players play in turn (that's what happen in SM games.
-sitrep will send a list of message to the player
-there will be a considerable number of fleet and systems

I don't know how the development of other systems (economy, empire management, combat, buildings, infrastructure) could affect those assumptions.

Posted: Mon Jul 05, 2004 7:46 am
by drek
Thus no one here is going to say macros are useless and should not be in the game. What they will say though is we are not goign to design the game with macros in mind (optimally we won't need any, but realistically we will). So just take it easy as far as macros go. Lets get the system solidified/balanced/functional and go from there.

I'll add: need for "macrotools" or other UI improvements will become apparent through playtesting--which should also suggest what kinds of solutions might needed. But, we'll need a more complete game before playtesting can begin in earnest.

Post v4, at the earliest, imho.

Posted: Mon Jul 05, 2004 7:49 am
by vishnou00
Thus no one here is going to say macros are useless and should not be in the game. What they will say though is we are not goign to design the game with macros in mind

Posted: Mon Jul 05, 2004 7:56 am
by drek
vishnou00 wrote:
Thus no one here is going to say macros are useless and should not be in the game. What they will say though is we are not goign to design the game with macros in mind
My prediction is that we'll need autoexplore, perhaps patrols, perhaps some very minor colonization automation, probably a post-build rally point. And not much else.

My goal is that there will be no need for economic automation: neither AI governors nor group orders sent to worlds.

Time will tell.

Posted: Mon Jul 05, 2004 8:00 am
by vishnou00
From what I've seen, the need is already apparent for the macrotool I propose. I don't know how adding building model, secret project, tech tree, ship combat and ship design will change anything to the current situation: moving ships around is a chore.

drek wrote:My prediction is that we'll need autoexplore, perhaps patrols, perhaps some very minor colonization automation, probably a post-build rally point. And not much else.
That is the kind of things I want to do. I'm not interested in governor and AI.

drek: I'm not sure what you mean by "group orders sent to worlds". If there is indeed global production, an order to a world could only be a focus change. Ordering a group of world would to change focus would save a couple of clicks, not much else.

My only goal with macrotools is to streamline the way the player input its decisions into the game.