View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0015761 | AI War 1 / Classic | Suggestion - Interface Ideas - Unit Selection, Management, and Orders | Aug 31, 2014 10:02 am | Sep 1, 2014 7:21 pm | |
| Reporter | giftgruen | Assigned To | |||
| Status | new | Resolution | open | ||
| Product Version | 8.003 | ||||
| Summary | 0015761: Extra champion management is overly tedious | ||||
| Description | I recently started a singleplayer game in normal+champ role with seven extra champions. While entertaining, that has some extra micromanagement to it that could be avoided. Of course every champ needs its own line for levelup points and Large starbase/engineer support as well as its own upgrade line. But why don't players share blueprints? Even on an eight player game with eight champs and different blueprints, the separation into human, spire, ... form and frigate, destroyer, ... size would prevent cluttering the menu too badly. Also, other players' champs cannot be added to one of my control groups even if they are all fully controllable by me and even if they have specifically allowed allies to control their units in CTRLS tab. I understand that I've probably taken it up to eleven with eight champs in singleplayer, but especially the latter seems to be unintended behaviour. Perhaps generally make ships of players with the aforementioned option ticked addible to control groups of other players? EDIT: Copy&pasted ship templates seem to not be able to execute the "apply to selection" or "switch to form" commands, making them quite useless. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | |||||
|
|
I agree that it could do with an overhaul, but Keith provides an in depth explanation of the current issues in this thread: http://www.arcengames.com/forums/index.php/topic,16154.0.html It may help you understand why this isn't a quick fix. |
|
|
What about a "Normal + several champs" role then? The problem with champion data storage perhaps could be avoided by using an object for every champ that holds its relevant data and isn't destroyed upon champ death? Additionally, it seems that if I copy ship templates and paste them, the other champs are neither able to "switch form" to the pasted template, nor able to "apply to selection" if they already have the same form. |
|
|
Giftgruen: That also falls under the inherent problem, AI War has RAM issues. Requiring more RAM for it will invariably cause problems. Instead you have to find a way to work out how you save the RAM you will require for the new feature. This is not so easy, since everything has been RAM optimized a lot already. |
|
|
Perhaps I'm horribly mistaken, but wouldn't an eight player game with seven players that have only one ship need more RAM than a one player game with fifteen more objects in the game world (7 more champs + 8 "champhelpers")? I mean, if eight players wanted to play with eight champions each, I could understand the additional load, but who would want to play such a game? This feature is primarily for SP anyways, I think. And even a cap of four or three champs per player would be sufficient, so 5-7 more objects. |
|
|
Giftgruen: Currently every player has one champion each. Or you could replace a player with a champion. You can't have 8 player champions and 8 extra champions. This is impossible. The creation of an extra champion creates an entire extra player, even if one doesn't exist. All other player data is null, but still takes up space. This is how the data structure is currently formed. To change this, you would need to change every facet of the underlying game, something best saved for a sequel. What you want to do makes sense in your head, and looks good until you understand how everything works at the code level. This game is old, very old. It is packed to the gills with content. The designers have enough trouble trying to add new stuff, let alone rebuilding the whole game from scratch to accommodate something like this. That said, they may one day find enough space in the memory footprint to allow for a change in how extra champions control. However don't expect much right now. |
|
|
I meant it like that: Scenario 1, how the game currently is, singleplayer (normal + champ) + 7 extra champs: An eight "player" game. That means, the memory saves things like the scores (raw and adjusted) of each of the eight "players", their CTRLS and ship design tabs' settings. Scenario 2, how it would be if champion data could be stored in an independent object, but not another "player", singleplayer (normal + 8 champs, just to make it similar to Sc.1): All the data of the champs is still saved independently, but all the player-specific things mentioned earlier are present only one time. Now, what I wanted to say, is, I undestand that if you used Scenario 2 and added 7 other players with said "normal + 8 champs" role, it would be more RAM-intensive than Sc.1. But as long as you are in singleplayer, you would have less RAM used with one player with 8 champs and 8 "champhelper-objects" than you would using one normal+champ role and seven extra champs. My argument was based on your statement that changing this was a RAM issue in the first place. If you say it is not possible to easily change this, that's something I cannot argue against, because I am not familiar with AIW's internal structure. But I do have a basic concept of data storage and couldn't believe it would be more RAM-intensive to add 8 more objects to one player than adding seven additional players. |
|
|
I just want to be clear, I'm not saying your request is a bad one, nor am I angry with you. I'm just trying to explain the complexities involved here. Leaving this as an open issue would be a good thing in the long run, as it would be a visible issue for them when they do decide to do a sequel with a new engine. Doing as you suggest would break champions in multiplayer, causing RAM issues there. Currently, every object in game tracks what groups it belongs to in an array list of the player's 10 control groups that it belongs to. Lets give that array a value of X RAM used. Now if we were to have it track other player's control groups as well, that is X*8 RAM used. That's 8 times as much as it has to work as well with 1 player as it does with 8. In your proposal, by removing them from individual players, now they don't know who's control groups are the base list. If there is only 1 player, this is a non-issue, but since there can be up to 8, you still need X*8 RAM used to track all the potential control groups it could belong to. This is because the unit determines what control groups it belongs to, rather than the control group tracking what units it possesses. I believe this was done as well to reduce the RAM footprint, as a list of many units tracked by Unit ID could be a lot larger than an array of 10 Boolean values on each unit in question. The reason I say this is something most likely introduced in a sequel is because there they can design the game to run as a 64-bit process and address a lot more memory as a result. If you ever look at the game when it runs, it uses a lot of memory, in 8 player games (or 1 player with 7 extra champs) it almost uses all 2 GB it is allotted. In fact I bet most of the lag some people encounter is actually tricks to use more memory without needing more. In short, they've packed about as much as they can get into the game as they can before it becomes extremely tough to tease any more efficiency out. What they need is more base RAM to work with, then this would be easy. |
|
|
Yeah, I understand you now. And I understand why changing the game to 64 bit would be lots and lots of work, and it wouldn't be the same game after such a step (although it is one many developers will have to make eventually). But isn't the texture preload totally counter-productive, then? |
|
|
Texture Pre-load is one of those things they do to prevent excessive load times every time you change planets, or the AI unlocks a new unit. Load times in these circumstances could destroy a game in single player, as well as prevent the viability of multiplayer due to desyncs. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Aug 31, 2014 10:02 am | giftgruen | New Issue | |
| Aug 31, 2014 11:42 am | Kronic | Note Added: 0039158 | |
| Sep 1, 2014 4:23 am | giftgruen | Note Added: 0039161 | |
| Sep 1, 2014 4:25 am | giftgruen | Description Updated | |
| Sep 1, 2014 6:59 am | Chthonic One | Note Added: 0039162 | |
| Sep 1, 2014 12:31 pm | giftgruen | Note Added: 0039163 | |
| Sep 1, 2014 12:48 pm | Chthonic One | Note Added: 0039164 | |
| Sep 1, 2014 12:49 pm | Chthonic One | Note Edited: 0039164 | |
| Sep 1, 2014 2:49 pm | giftgruen | Note Added: 0039165 | |
| Sep 1, 2014 3:08 pm | Chthonic One | Note Added: 0039166 | |
| Sep 1, 2014 5:36 pm | giftgruen | Note Added: 0039167 | |
| Sep 1, 2014 7:21 pm | Chthonic One | Note Added: 0039168 |
