Forwarded: [Battle] Army management, stacked unit display

[DeletedUser103370]

Proposal
Show only stacked units in army management modal.

Have you Checked the Ideas section for the same idea posted by someone else? Is this idea similar to one that has been previously suggested?
No, though I know there are many ideas regarding the army management screen.

Reason
Faster and easier access to units, less loading time.

Details
The reason why you can't see all the units individually in the army management modal is the same, I propose to further reduce it, I don't see why not. So only show 1 icon - perhaps a stacked icon if there are more - for each individual units, and put the number of existent units let's say in the bottom right corner of the icon.

Visual Aids
N/A.

Balance
Faster access, further reduced lag.

Abuse Prevention
N/A.

Summary
This could pave the way for a bit of an overhaul of the army management modal, I can imagine many different scenarios, either way this could be a smarter approach.

 

[DeletedUser110195]

+1
Yes! This would make it possible to see your entire army unless you've got every unit type from every age, which corner the number goes in doesn't particularly matter though I'd put it on top right.

 

[Prinza the Hunter]

A cautious +1

My reasons for holding back a little on my enthusiasm is:
1. Injured units and how they would appear. Since the decision to use a unit might be dependant on the injury state of other units of the same kind, I suggest that all injured units would have to be shown individually, with only fully-healed units being stacked. This somewhat reduces the appeal of the whole idea.
2. Attached units would need to be shown seperately to unattached units, since that, too, can be a deciding factor in whether to use them and the selection of them needs to be distinct.
3. Defending units would have to be seperated because that, too, is a deciding factor in selecting them for attackers.

These points combined mean that some unit kinds will still have several icons, two for the healed units (attached and unattached), defenders, and more for each injured unit. Taking a snapshot of my units right now, my nine catapults would still take up five icons:
1 icon for the two defenders
1 icon for the uninjured unattached
1 icon for the uninjured attached
1 icon for one almost healed
1 icon for one almost dead

So what seemed like a great idea on first reading might still be an OK idea but it might just make things more complex for newbies (though it could be a switchable option).

 

[DeletedUser103370]

A cautious +1

My reasons for holding back a little on my enthusiasm is:
1. Injured units and how they would appear. Since the decision to use a unit might be dependant on the injury state of other units of the same kind, I suggest that all injured units would have to be shown individually, with only fully-healed units being stacked. This somewhat reduces the appeal of the whole idea.
2. Attached units would need to be shown seperately to unattached units, since that, too, can be a deciding factor in whether to use them and the selection of them needs to be distinct.
3. Defending units would have to be seperated because that, too, is a deciding factor in selecting them for attackers.

These points combined mean that some unit kinds will still have several icons, two for the healed units (attached and unattached), defenders, and more for each injured unit. Taking a snapshot of my units right now, my nine catapults would still take up five icons:
1 icon for the two defenders
1 icon for the uninjured unattached
1 icon for the uninjured attached
1 icon for one almost healed
1 icon for one almost dead

So what seemed like a great idea on first reading might still be an OK idea but it might just make things more complex for newbies (though it could be a switchable option).

Yeah, that is why I said I could imagine a complete overhaul for the modal, though I'd put that in your hands or the devs.
Just some examples how I could vision it:

1.
- unattached units in separate page
- attached in separate page
- injured in separate page
if you want to, the stacks could be expanded/collapsed showing the individual troops with a click

2.
- unattached and attached units could be shown in two separate pages, same principles, so show only 1 of each
- stacks could show only uninjured units, injured ones would go in a separate space-holder in their relevant page (attached or not)
- on top of injured stack always show the one with the least injury

But to be honest this could be done a hundred different ways, really not sure which one would be the most popular.
The concept is simply further reduce the number of troops shown, down to a size which is the bare minimum, thus we could reduce lag and make access faster, so if you have a better solution for that, I'm open!

 

[DeletedUser110195]

1. Injured units and how they would appear. Since the decision to use a unit might be dependant on the injury state of other units of the same kind, I suggest that all injured units would have to be shown individually, with only fully-healed units being stacked. This somewhat reduces the appeal of the whole idea.
2. Attached units would need to be shown seperately to unattached units, since that, too, can be a deciding factor in whether to use them and the selection of them needs to be distinct.
3. Defending units would have to be seperated because that, too, is a deciding factor in selecting them for attackers.

A way to have our cake and eat it too, would be to have it take units the same way it sorts them now, in regards to health, and if it could be done, have it take attached first, since you can train more if they die. If you click to add something it separates from the stack and you see the individual unit, if what's on top is unattached, injured or both, then you know you've hit the wall and have to decide if you want to risk that unit.

 

[DeletedUser103370]

A way to have our cake and eat it too, would be to have it take units the same way it sorts them now, in regards to health, and if it could be done, have it take attached first, since you can train more if they die. If you click to add something it separates from the stack and you see the individual unit, if what's on top is unattached, injured or both, then you know you've hit the wall and have to decide if you want to risk that unit.

Yeah, somehow practical situations we should keep in mind, for example, as long as you have uninjured units, it's obvious you will use them first, not the injured ones. Keeping the uninjured on top solves the problem of this, though you still won't be able to see how many injured you have.
Another approach, is for example having multiple numbers on the stacks, ie. bottom right corner, number of whole stack, no color. Bottom left corner, number of injured units, color red. Hovering the mouse could show you detailed info on the stack, attached/unattached, and the usual stuff like strength etc.

Oh and of course as usual, I'd make this optional, in other words there could be a button changing how units are displayed, stacked or normal. So you could choose your preference, maybe using the stacked display in general, but expand it in cases you need to check.

 

[DeletedUser110195]

Another approach, is for example having multiple numbers on the stacks

Oh and of course as usual, I'd make this optional, in other words there could be a button changing how units are displayed, stacked or normal. So you could choose your preference, maybe using the stacked display in general, but expand it in cases you need to check.

I don't think that will be necessary, just knowing how many of that unit you have would do, since when you pull one from the stack, you can just put it right back with another click if you're not willing to put in an injured or irreplaceable unit.

 

[Nilopertiso]

Old suggestion. Positive responses previously. Nothing changes.

New Army Management Prototype
New Army Management

 

[DeletedUser110195]

Old suggestion. Positive responses previously. Nothing changes.

This is not the same as Lab21's idea, this is suggesting a compacted display of units with a number somewhere on the unit icon to show how many there are, not an expanded page to show all of them simultaneously individually as it is now.

 

[DeletedUser12400]

[IMG]http://i.imgur.com/SQIjbSW.png[/IMG] ​

+1​

This is not the same as Lab21's idea, this is suggesting a compacted display of units with a number somewhere on the unit icon to show how many there are, not an expanded page to show all of them simultaneously individually as it is now.

A similar, yet different approach. http://forum.en.forgeofempires.com/index.php?threads/new-army-management.33166

 

[Nilopertiso]

This is not the same as Lab21's idea, this is suggesting a compacted display of units with a number somewhere on the unit icon to show how many there are, not an expanded page to show all of them simultaneously individually as it is now.

I didn't say it was, which is why I posted a link to Rosletyne's suggestion first, which was the exact same (it showed a number for however many of that type of unit, including injuries). The 2nd link is simply another army management suggestion to re-enforce my arguement that nothing has been changed.

Unfortunately, Rosletyne's working prototype is no longer accessible, so you can't see how exactly similar it was (unless you remember the posting at the time). FWIW, I totally agree with the approach, though it's a shame FoE don't.

 

[DeletedUser12400]

[IMG]http://i.imgur.com/o5JqqJB.png[/IMG] ​

Unfortunately, Rosletyne's working prototype is no longer accessible, so you can't see how exactly similar it was (unless you remember the posting at the time). FWIW, I totally agree with the approach, though it's a shame FoE don't.

Prototype is not working properly however thread remains: http://forum.en.forgeofempires.com/index.php?threads/new-army-management-prototype.28230/page-2

 

[Prinza the Hunter]

A lot of this stacking concept, however it is implemented, depends on the future direction inno see for units. If there is a long-term thought to expand the attributes so that each might have unique characteristics other than just health (weapon, experience, resilience, training, etc.) then the current, open and individual, display will be necessary. If.

 

[DeletedUser110195]

A lot of this stacking concept, however it is implemented, depends on the future direction inno see for units. If there is a long-term thought to expand the attributes so that each might have unique characteristics other than just health (weapon, experience, resilience, training, etc.) then the current, open and individual, display will be necessary. If.

Unless, they pattern whatever upgrades to a unit there could be, then they could be sorted into stacks according to their stats.

 

[Prinza the Hunter]

Now that I have played a little longer than my earlier posts in this thread, I have just had this pop up for the first time (this is the app):

Spoiler

I should now make something clear: I don't suppose I am unique on this forum but I am a computing professsional, being freelance for many decades and covering a wide range of disciplines. However, I am not expert at this kind of graphics.

So, I am wondering what performance issues there might be. There is not (certainly should not be) an issue with comms, since there is easy and obvious optimisation that should have been in place for years, even if it wasn't coded well originally. There should not be an issue with the graphics, given that even if 3GX widgets (presumably rather old-hat by now) were used, since that also has simple optimisation.

Presumably, then, there is a memory usage issue, with each unit being an object. By cutting down to 20 objects of one type, the developers are utilising object echo techniques but by my reckoning, that would require 28 unit maximum to fulfil each possible variation. So, I presume the defending army is always going to be displayed individually and does not make up part of the 20.

The reason I am trying to fathom what the performance issues are, is to gauge how much any suggested change might help or hinder. The current optimisation that i am presumiing is crude but simple to maintain in code and is effective. Trying to stack units with different levels of injuries would need very different coding, or only affect the visual element without a change to the object handling or improve performance (graphics performance might even drop). What could be done is display the ecohoed units with a 'stack' or even easier with a number overlay, particularly for all uninjured units of the two attachment types:

Spoiler

This is simple, the information is already available, is not confusing for newbies since they won't see it until well into the game (unless they happen to build three spearmen barracks, which I'm guessing is rare) and should be easy to maintain. It could initially wait until there are over 8 units of the same type, then condense all uninjured units over 1.

In short, it would be a cheap and easy change to what is currently done, with the ability to lead on to more complex alterations at a later time.

 

[DeletedUser103370]

I'll be honest, lately (in the past 5-8 years) I haven't done anything in flash, but before that for a couple of years I was coding it myself for shorter projects. The reason why I abandoned it is the same as many others did, because the language is too bulky, slow, and unresponsive. Sadly back in the time the only solution to make high quality cross-browser graphics was flash, so when it was introduced it popped up crazy everywhere. But people quickly realized that using it means a slow, and buggy interaction, so it was reduced for mainly ads and small silly games.

It came a long way since then, and I believe games like FoE are capable to bringing it to it's limits, sadly the bottlenecks are still there, and I don't think that's gonna ever change, I think it's clear that sooner or later (perhaps a decade, who knows) the flash as a programming language will vanish. Especially true now, when the newest standards, for example html5 and the canvas are capable of everything what flash can do, and more importantly in a much faster, cleaner, and responsive way.
Just as an example, when you enable the animations in your village, if you check the memory usage you'll see that flash will use an extra 100-200MB of memory (at least in my city and I'm only in modern), which is absolutely crazy, if you think about it we're talking about a couple of dozen small, basic animations.
Of course a change like this would mean a new game essentially, so it won't happen which we all accepted, given that to make the game enjoyable the devs must (and trying to anyway) do everything they can to reduce lag, loading times etc. That's where I think we could still improve, with changes like this. We can think of smarter ways to display bulk of stuff, like the units in the management. If instead of 20 unattached units we'd display 1 stacked icon with a number indicator, then it's obvious we'd save memory and performance.
Now I'm not saying this exactly is the best way to do it, perhaps you guys could come up with even better solutions, what I'm trying to do is make it more compact, less hogging, and more straightforward at the same time if possible.

Btw. it's very nice to see professionals and enthusiasts here, I think you guys can give a valuable extra feedback, and I hope we can make the game even more slick.

 

[Prinza the Hunter]

On your comments about Flash going out, I think you are right. What many producers are waiting for is the market to develop and settle a little on the cross-platform app developments, some of which already compile for the PC. Fundamentally, this will mean that from a single code base, Android, iOS, Windows and Unix (at least) can be coded. It is a difficult ask and the software able to do it is still quite new and limited in scope.

...If instead of 20 unattached units we'd display 1 stacked icon with a number indicator, then it's obvious we'd save memory and performance.

I'm not convinced that this statement is true. Depending on how all the variations are handled, it could mean worse performance. It could well mean quite a major programming project, rather than just a tweak.

Bunching healthy units of the same type and attachment is likely to be fairly simple and even if it does not help performance, should not make it worse, and would be an improvement for users.

Each unhealthy unit must be a seperate object in memory because of the healing timer. Grouping these graphically is possible but could require more effort, not less.

 

[DeletedUser103370]

On your comments about Flash going out, I think you are right. What many producers are waiting for is the market to develop and settle a little on the cross-platform app developments, some of which already compile for the PC. Fundamentally, this will mean that from a single code base, Android, iOS, Windows and Unix (at least) can be coded. It is a difficult ask and the software able to do it is still quite new and limited in scope.


I'm not convinced that this statement is true. Depending on how all the variations are handled, it could mean worse performance. It could well mean quite a major programming project, rather than just a tweak.

Bunching healthy units of the same type and attachment is likely to be fairly simple and even if it does not help performance, should not make it worse, and would be an improvement for users.

Each unhealthy unit must be a seperate object in memory because of the healing timer. Grouping these graphically is possible but could require more effort, not less.

Yeah that's true, I'm not saying this is a small task, however major changes for example the recent GB overview overhaul gives me hope!
And yeah I'm excited to see a long anticipated final cross-platform solution, everything points in that direction for soooo long...
What I don't get is what you mean that it's not necessarily true that handling a single image instead of 20 would take less resources. Can you explain?

 

[Prinza the Hunter]

What I don't get is what you mean that it's not necessarily true that handling a single image instead of 20 would take less resources. Can you explain?

I'll try to explain. Please bear in mind that I don't know the software being used to code up the two platforms, nor the methodologies used, so I am thinking generically, making some educated guesses about how it probably works.

There are a number of areas where computing resources could be consumed. From a player's viewpoint, these start at the screen, then there is the memory used to know what to put on the screen, holding the data for all the buildings and units, etc. Then there is the communications from your computer to Inno's gateway. Within Inno, there is a minimum of one server your data travels to (the database) but quite possibly a layer in between as well.

To lay it out in an example, one of your units takes a hit in battle:

1. The local (memory) health of the unit in battle is deducted;
2. The deduction is reflected on screen; meanwhile..
   
3. This deduction is sent as a communication to Inno (World, player Id, Battle Id, Unit Id, new health stat);
4. The gateway checks for security, passses the communication to the correct world server;
5. The world server updates the record of health for the unit;
6. The world server writes out a log entry for the damage (possibly skipped unless in beta);
7. The server sends a communication back to your game, which updates the NON-battle version of the unit held in memory (I'm really guessing at this point but it would match what I have observed; I think the unit that goes into battle is a copy of the unit.)

That's just to give you some idea of what is going on, illustrating the various resources.

Most of the graphics effort is probably just what you see. (That might seem obvious but it isn't.) While the memory processing requirement for many of the same item is slightly less, depending on target platform and coding, what you see took some graphical effort while what you don't see probably did not. So, it doesn't really matter if you see one unit in your army or eight, the same(ish) graphics effort was taken.

Each unit is unique. It will have its own internal Id, which identifies (at server) with the barracks it was produced in (if any) and the position within those barracks. It has its own data on its health, along with how long it will take to heal the next unit of health. Things like the image used to display it, the name shown (in your language) that describes it, statistics on its strength and speed etc. are held just once in memory, pointed to by each of the same unit. (I'm making some massive guesses based on best practices and what makes sense - if we were talking of a certain very-large-but-named-as-very-small software company, I would not be guessing at such optimisation.)

So, displaying each unit on screen is simple: start at the first one, go through each unit owned, looking up the graphic image, text and numbers as needed.

Displaying each similar unit on screen that has full health with a number overlay is just one extra step, requiring a pass through the units to count up such units and then hold the quantitiy along with all full-health units. It is made only slightly more complex if attacjhed and unattached units are combined into the count. A little bit more processing but not much for a greatly de-cluttered screen. (That's not the end of it, though, when one considers that the unit may be assigned to an attack or defence army, and that injured units become healthy ones, but these are not insurmountable UI issues.)

Where a potential saving could come would be not to hold healthy units individually in memory. As far as players are concerned, the unit is already random in terms which barracks it comes from (though there are suggestions to make it known), so the server could just send information on one healthy unit, with the count of how many of that one there are. However, when one of them is injured, while the server can randomly assign which one it was, that cannot be communicated from the server to the game so easily (unless my guess is right that what fights is a copy, which can be dicarded after battle in favour of what the server says the current army is).

TLDR;
It is all to do with the way that units are held in memory and manipluated as they are created, go to battle, get injured and die.

 

[DeletedUser103370]

I'll try to explain. Please bear in mind that I don't know the software being used to code up the two platforms, nor the methodologies used, so I am thinking generically, making some educated guesses about how it probably works.

There are a number of areas where computing resources could be consumed. From a player's viewpoint, these start at the screen, then there is the memory used to know what to put on the screen, holding the data for all the buildings and units, etc. Then there is the communications from your computer to Inno's gateway. Within Inno, there is a minimum of one server your data travels to (the database) but quite possibly a layer in between as well.

To lay it out in an example, one of your units takes a hit in battle:

1. The local (memory) health of the unit in battle is deducted;
2. The deduction is reflected on screen; meanwhile..
   
3. This deduction is sent as a communication to Inno (World, player Id, Battle Id, Unit Id, new health stat);
4. The gateway checks for security, passses the communication to the correct world server;
5. The world server updates the record of health for the unit;
6. The world server writes out a log entry for the damage (possibly skipped unless in beta);
7. The server sends a communication back to your game, which updates the NON-battle version of the unit held in memory (I'm really guessing at this point but it would match what I have observed; I think the unit that goes into battle is a copy of the unit.)

That's just to give you some idea of what is going on, illustrating the various resources.

Most of the graphics effort is probably just what you see. (That might seem obvious but it isn't.) While the memory processing requirement for many of the same item is slightly less, depending on target platform and coding, what you see took some graphical effort while what you don't see probably did not. So, it doesn't really matter if you see one unit in your army or eight, the same(ish) graphics effort was taken.

Each unit is unique. It will have its own internal Id, which identifies (at server) with the barracks it was produced in (if any) and the position within those barracks. It has its own data on its health, along with how long it will take to heal the next unit of health. Things like the image used to display it, the name shown (in your language) that describes it, statistics on its strength and speed etc. are held just once in memory, pointed to by each of the same unit. (I'm making some massive guesses based on best practices and what makes sense - if we were talking of a certain very-large-but-named-as-very-small software company, I would not be guessing at such optimisation.)

So, displaying each unit on screen is simple: start at the first one, go through each unit owned, looking up the graphic image, text and numbers as needed.

Displaying each similar unit on screen that has full health with a number overlay is just one extra step, requiring a pass through the units to count up such units and then hold the quantitiy along with all full-health units. It is made only slightly more complex if attacjhed and unattached units are combined into the count. A little bit more processing but not much for a greatly de-cluttered screen. (That's not the end of it, though, when one considers that the unit may be assigned to an attack or defence army, and that injured units become healthy ones, but these are not insurmountable UI issues.)

Where a potential saving could come would be not to hold healthy units individually in memory. As far as players are concerned, the unit is already random in terms which barracks it comes from (though there are suggestions to make it known), so the server could just send information on one healthy unit, with the count of how many of that one there are. However, when one of them is injured, while the server can randomly assign which one it was, that cannot be communicated from the server to the game so easily (unless my guess is right that what fights is a copy, which can be dicarded after battle in favour of what the server says the current army is).

TLDR;
It is all to do with the way that units are held in memory and manipluated as they are created, go to battle, get injured and die.

I think I understand mostly what you saying, and it makes sense. Basically the server only have to transmit the number of units to display, and the client can handle the actual graphical representation. However, as far as I see it with flash that's exactly one of it's bottlenecks. If you check it's resource usage, quickly comes clear that more things it has to display, the more it struggles. I believe the problem lies with the client and it's resource handling, also I believe that's the main reason behind limiting the displayed units, and for example the cap of the friends in the social bar. Because in theory it wouldn't matter how many units it displays, the server should still only need to send a number, ie. instead of 20, it would send 100. 1 byte difference (or not even that), not a biggie. However when it comes to the client handling the display, it slows down extremely as you add more and more things to display. That's why I'm thinking that reducing the elements needed to be rendered could perhaps reduce the lag, and at the same time of course I'd like a cleaner, more sleek management screen, this "I have to scroll the page forever just to look for a specific unit" is a bit outdated I reckon.

Of course as you said it yourself I have no clue how exactly it's done, but most likely in some similar fashion. I wonder if they test stuff like this on the beta server?