Feasibility of major interface functionality changes?

Discussion in 'Mod Discussions' started by evilc1, February 3, 2014.

  1. evilc1

    evilc1 New Member

    Messages:
    4
    Likes Received:
    3
    Hi, I recently bought PA, whilst I am not a particular fan of RTS, TA was always one of my favorites.
    Picking it up again reminded me why I always sucked so bad at RTS - I hate micro and trying to keep track of everything. Queuing up a huge series of build orders, only to have the unit destroyed and have to do another hundred clicks is very annoying - I am very much a believer that good game design means you fight the opponent, not the interface.
    Now whilst a lot of this is down to practice etc, this got me thinking as to what I would change to make things more manageable and accessible to a wider variety of players.

    I did some reading up on PA modding and the UI seems highly moddable, using languages I am already familiar with - I recently made a career shift into the development industry as a developer-in-test/coder (with a heavy slant on UI stuff), so I could certainly see myself getting involved with a project such as this.

    In general, what I would like to achieve is to separate the tasks you wish to accomplish from the in-game units. In other words, you describe to the game the tasks you wish completed, and then you can assign / unassign units to that task.

    Some examples of how this might work in practise (Items in [brackets] are talking about proposed UI items):
    In the context of patrols: You create a patrol route using [the UI] and store it in your [list of patrol routes].
    You then assign some troops to that route. Later you expand your base, so you go into your [list of patrol routes], select the route and alter it. The units assigned to that route start following the new waypoints.

    In the context of building: You plan to build some structures at some point, so you click on the [build button] which presents you with a build menu, showing ALL items (whether you can build them now or not). You place a number of ghost structures and click [save]. At some point in the future, you wish to build these structures, so you browse the [list of build orders] and assign a group of fabbers to to the build order. In the process of building, these fabbers subsequently get destroyed. Normally this would cause the build orders to be lost, but seeing as the build order is now independent of troops, you can simply select a new group of fabbers and assign them to the build order.


    Some ideas I have had:

    Non unit-specific build queues
    As described above.

    Non unit-specific move orders
    As described above

    Named / Categorized Groups
    IMHO, there is much room for improvement in the way RTS games handle organization of units.
    ~10 numbered groups may be enough for your strike force, but for me, it falls short in other areas.
    I would love to see some way of being able to organize your units better, with the ability to categorize troops in various ways. This would probably require a UI element to be able to visualize these groups - some kind of hierarchical collapsing menu would probably work.
    For example, fabbers on patrol and repair duty could be labelled and organized as such - you could have a group "Repairers", then a couple of groups in there such as "Perimiter", "Vital buildings" etc. Then another category "Fabbers", and in that a couple of groups such as "Nuke assisters" and "Factory assisters".
    Some categories could also have other significance. For example, a "Reinforcements" category - troops that have been built but are awaiting a purpose can be placed in this group, then requisitioned at a later point (eg to replenish lost troops from an existing group).
    Finally, a view mode that replaces normal icons with category icons to let you get a quick overview of where various types of troops are stationed.

    Build to Group
    Add a UI to fabbers to allow troops built by that fabber to be automatically added to a group.

    UI Target for context commands
    If you create a group, it has a corresponding icon always visible that can be used to click upon. So if you want to have group 2 assist group 3, you can select group 2 and right click the icon for group 3 - that way if some of group 2 die, group 3 will still keep assisting. Maybe even have group 3 take over group 2's orders if they are destroyed.

    Does anyone know of anybody trying to achieve similar goals?

    How many of the goals would be achievable currently?

    How many of the goals are likely to be ultimately achievable?

    Also, any other comments or suggestions welcomed.
    lokiCML and mwreynolds like this.
  2. cptconundrum

    cptconundrum Post Master General

    Messages:
    4,186
    Likes Received:
    4,900
    There are some good ideas here. I think the answer is that we will have to see. We really need a better api for engine calls if there is any chance of creating real helper mods. Right now we have the auto factory mod, but it is just working around this limitation by automatically selecting factories, giving orders, and deselecting. We really need a way to give commands to units directly without having to select them.

    If Uber gives us this level of access, I expect to see some amazing ui mods. With the right api, you could theoretically program an entire AI using just client-side javascript.
  3. LavaSnake

    LavaSnake Post Master General

    Messages:
    1,620
    Likes Received:
    691
    Same here. Those are some great ideas but they're a little beyond the current API. Uber has said that they plan to improve the modding support and API a lot so this will hopefully be doable by release.
  4. evilc1

    evilc1 New Member

    Messages:
    4
    Likes Received:
    3
    Thanks for the feedback so far...

    I found the modding reference guide which seems to indicate that the only documentation is reading the source to see the methods that are available, I guess I will have to sift through that to find out what is currently possible, maybe I can rig up prototypes (or at least rig up some mock UI elements) for some of these ideas while we wait for the API to be improved.
  5. LavaSnake

    LavaSnake Post Master General

    Messages:
    1,620
    Likes Received:
    691
    Looking at other mod's source code is also a good idea. Start with some simple ones like my profile pic fixer (simple js code that edits the UI) or my Stargate name bug fix (simple unit json shadow).
  6. cptconundrum

    cptconundrum Post Master General

    Messages:
    4,186
    Likes Received:
    4,900
    During Garat's playtest stream today, I asked him if they would be adding engine calls that allow units to be given orders without the need to be selected. He said they definitely plan to give us a better api, but they haven't worked out exactly what that will be yet. The developers are aware of the benefits to the kind of engine hooks we are asking for, but they are also worried about the possibility for cheating.

    Basically, this is technically possible as long as the devs decide to do it. They just want to come to a decision on what exactly cheating is defined as before they go ahead and give us something with this much potential for abuse. The best thing to do would be to give your opinion on the definition of cheating here and then wait for the devs to make a decision.
    ORFJackal and LavaSnake like this.
  7. Dementiurge

    Dementiurge Post Master General

    Messages:
    1,094
    Likes Received:
    693
    This idea, in one form or another, crops up everywhere from time to time. It's very dear to the hearts of some, and I can see why. Any RTS more complicated than Starcraft needs to rethink the one-order-per-unit philosophy.

    But I don't know what the PA devs think of it, since it's really something that would need to be part of the base game. I doubt you could implement it properly without storing a list of every unit you've ever selected inside of the UI.
    LavaSnake likes this.
  8. Raevn

    Raevn Moderator Alumni

    Messages:
    4,226
    Likes Received:
    4,324
    This is also known as "Orders as first class entities", and becomes very useful if implemented right. An example of when not implementing this is bad is what happens with transport ferry routes in Supreme Commander - if the original transport(s) die, any transports added to the route afterwards lose the order and stop wherever they are.

    There are challenges with making this intuitive and simple, so it's not something that can be implemented without a lot of thought.
  9. evilc1

    evilc1 New Member

    Messages:
    4
    Likes Received:
    3
    Whilst I can understand where Uber are coming from regarding cheating, I think that if they used that as the sole metric, they would be missing a trick.

    What I feel would be more productive would be to release a version that has a lot of hooks into the engine, but is not approved for regular matches (Separate exe?).

    People like myself could then write systems such as what I have proposed, and once it is done and working, Uber could then look into how this could potentially be integrated into the main game, or how it could be added as another game mode (ie players using this system can only ever play other players using this system).

    If the community actually did manage to pull it off, I would imagine that Uber would stand to benefit considerably.

    Nah, with proper API hooks, you could request info about units from the engine. Besides, with the memory of modern PCs, having an object in memory for each unit would probably be pretty insignificant.

    Thanks for the link though, it helps put me in touch with like-minded people :)

Share This Page