Update Update 1.41

[Rosletyne]

It is not simply army management as I have already stated, ultimately the game itself will not load. It is also puzzling why anyone would feel the need for an ever increasing amount of units which you never intend to use.

Maybe that is what the developers said, but they either lied or are too incompetent to know any better. The problem causing army management to be slow and loading issues both is that every unit is handled and stored in memory individually. The solution to the problem is obvious - army management needs to be redesigned for stacked units, which should not only be much faster but also require much less memory.

As Starzaan mentioned, the main reason the devs are doing this is because army management and the game performance will slow. If they could find a fix for this, I would assume they would lift this limit.

Where have you been for the past year?

I lost my faith in the developers completely over the months it took them to implement that indicator for unattached units. We still don't have the filter that we wanted. This is the sort of problem that you could give to an undergraduate programmer as an assignment and expect a working solution the next week. The fact that InnoGames took as long as they did, despite the issue supposedly having top priority, raises some serious questions whether they have any idea what they are doing. If you ask me, they are either incompetent oafs not worthy of their paycheck, or lazy bums not worthy of their paycheck. Or both.

 

[DeletedUser97590]

Maybe that is what the developers said, but they either lied or are too incompetent to know any better. The problem causing army management to be slow and loading issues both is that every unit is handled and stored in memory individually. The solution to the problem is obvious - army management needs to be redesigned for stacked units, which should not only be much faster but also require much less memory.

Where have you been for the past year?

I lost my faith in the developers completely over the months it took them to implement that indicator for unattached units. We still don't have the filter that we wanted. This is the sort of problem that you could give to an undergraduate programmer as an assignment and expect a working solution the next week. The fact that InnoGames took as long as they did, despite the issue supposedly having top priority, raises some serious questions whether they have any idea what they are doing. If you ask me, they are either incompetent oafs not worthy of their paycheck, or lazy bums not worthy of their paycheck. Or both.

It's simpler then that, they just don't give a hoot about what the end user wants.

 

[DeletedUser14394]

I could only assume the following reason on why the unit cap is going to be Implemented. Since I'm a programmer, so I can guess like this.

None of the units are not just counted as 26 CE tanks, 255 roghues, blah, blah, blah.. Each "individual" unit has its own unique code to differentiate it from other units to keep track of the healths as well as to monitor the logs if something happens wrong. In a long period of time, you'll be "gradually" increasing the counter on each units. So this "gradually" becomes to "exponential" due to further stacking up of units also players building new Alcatraz as well as levelling it up. It may be automatically designed to delete the unique code of a unit once it's destroyed (either by manual deletion or losing it in a battle). I dont have any idea on how they'll keep track of attached troops, since it's periodically lost in a battle and then trained again. So attached units may belong to the unique code of a military building along with its constant unchanging unique unit code. IF they're storing the codes in a database, itsn't not a problem on storing huge count of values coz each lost unit will lead to be deleting its unique code from database, but the problem is when the lost units doesn't able to compensate with the new created units count. This will be a much bigger problem to their storage space when adding up all the available servers and exponential increase of troops count. So they may've thought that this can be controlled by limiting the max troops count. But, this is not a standard way that can be forced upon the players who never expected anything like this from Inno.

Even after the bitter movements of GvG, changing the outcome of Goods GB, changing the boost values of military GB's, we get an alternate way like building current age Goods buildings, none of it forces a player to do a particular thing. But this unit cap limit, forces a player to either delete his unit or just suspending his levelling up of Alcatraz and lot more. It can be easily handled if the devs "can" think in a priority of solving it. But simple forcing it on players is not at all a good idea. I've a long way to get to that limit coz of various reasons, but it'll definitely affect 1/~(5-8) of current CE players. Suggesting an idea and waiting for it to receive enough support and then forwarding it to devs is not at all a suggestion. It's a big issue which have to be solved by the devs and not by flooding the forum.

Regards,

Naveen

 

[DeletedUser2989]

Being able to move units out of army management to inventory would require changes to the coding of the army management window anyhow. I don't see how stacking the units in the army management could require any more coding than stacking the units in inventory. Stacking them in inventory would also require the additional coding for the process of moving the units back and forth from one game element to the other. Depending on the existing coding in place I would think that moving units back and forth between army management and inventory would perhaps be the most difficult part to code.

I guess the difference between the two is that to me one way can be coded as an "add-on" to the existing system and the other needs to completely redo the army management coding. Your right though, it's hard to know exactly which would be harder without knowing the coding side of it. I think I'm still more favorable to the idea of storing unattached units in the inventory than straight up stacking them.

 

[DeletedUser97349]

I will discuss the issue of the cap on units on Monday and post again when I have some feedback on the concerns raised.

 

[DeletedUser96867]

I guess the difference between the two is that to me one way can be coded as an "add-on" to the existing system and the other needs to completely redo the army management coding.

It wouldn't be completely redoing the army management coding. 95% of the coding would remain unchanged. It's something I would expect to be able to code in just a few hours.

This is the sort of problem that you could give to an undergraduate programmer as an assignment and expect a working solution the next week.

More like the sort of assignment you give a 2nd year computer science student and expect a working solution the next day.

 

[DeletedUser12778]

Do you guys know that this will only increase the amount of ghost guild right?

Someone who as a lot of units and don't want to waste alcatraz production, will create a guild collect their atomium and observatories do a lot of fights in autocombat then release sectors and repeat it again and do a lot of battle points and medals in the process

Well i don't understand programming but would it be easier to divide the units by stacks, using age, type, health and attached/unattached? that way you'll have the max of 9x2=18 stacks for each unit since you have 6 types of units per age plus rouges and 11 ages 11x6+1= 67 units multiply by 18 you have the max of 1206 stacks of units shown in the interface, but for that max to be shown you much have at least 9 unattached 9 attached of each units and the amount damage suffered by those units must be diferent, so the chances of that happening and winning the lottery must be close

So this is a solution if i didn't get the math wrong, but even if i did, the idea seems viable. I don't know if in terms of programming is difficult or not, but to players this plus the filters we already have would probably will solve most of the armies interface problems

Wha do you think guys?

 

[DeletedUser96867]

Well i don't understand programming but would it be easier to divide the units by stacks, using age, type, health and attached/unattached? that way you'll have the max of 9x2=18 stacks for each unit since you have 6 types of units per age plus rouges and 11 ages 11x6+1= 67 units multiply by 18 you have the max of 1206 stacks of units shown in the interface, but for that max to be shown you much have at least 9 unattached 9 attached of each units and the amount damage suffered by those units must be diferent, so the chances of that happening and winning the lottery must be close

There is no point in stacking the attached units as the max number of attached units a player will have is going to be well below the max number of attached stacks you are talking about. As well attached units are individually linked to specific military building slots so even stacked they would always have to exist individually anyhow.

Any damaged unattached unit would also always have to exist as an individual element as even a stack of damaged units currently at the same health is going to have units damaged at different times so at a different point in their healing.

The main advantage of the unit stack idea is when all the units in that stack no longer have to exist as their own entity. In essence they would be handled just as 1 unit is now, with no additionally aspects other than a counter. I doubt the issue is merely a matter of displaying the very large number of units, but the tracking and compiling of thousands of units for display.

 

[DeletedUser5647]

The main advantage of the unit stack idea is when all the units in that stack no longer have to exist as their own entity. In essence they would be handled just as 1 unit is now, with no additionally aspects other than a counter. I doubt the issue is merely a matter of displaying the very large number of units, but the tracking and compiling of thousands of units for display.

(bold by me)
You have hit the nail on the head. The tracking of (potentially millions of) individual units is a server-side issue. It is InnoGames' servers that are bearing the brunt of this and it is clear they are running out of capacity to a relatively small part of the game coding/database becoming far larger than they had planned for.

In another game I play, (I won't say which, but involves millions of spaceships on a single shard server) the devs of that game have learnt to their cost that players will ALWAYS find a way to stretch the limits of the equipment. As such they have had to keep a close eye on how the players use and take advantage of the game mechanics introduced earlier in the development cycle. They are constantly re-coding to accommodate the needs of the previously introduced code as used by the players. A few years ago a cap solution was mooted for a difficulty found in that game and the player feedback was so heated even before it was implemented on the test server that the cap solution was abandoned and a re-coding solution found in short order.

As ever in database design, it is the boundary cases that make or break a system.

 

[Rosletyne]

Since this discussion has gotten increasingly technical, perhaps we would need a different topic for it?

For someone who claims not to understand programming, Zezinho got it exactly right. His idea is viable, not particularly difficult to implement, and would solve multiple issues at once. Having a working army management is absolutely critical for this game, and the developers should be ashamed if they thought they could solve anything with a cap, since all it does is place a limit on how bad things can get without fixing any of the many problems.

There is no point in stacking the attached units as the max number of attached units a player will have is going to be well below the max number of attached stacks you are talking about. As well attached units are individually linked to specific military building slots so even stacked they would always have to exist individually anyhow.

I have to disagree on this. It will only be confusing if there are two different systems in use, one for attached and another for unattached units, so they should both be converted to stackable even though the apparent benefit for attached units is insignificant. If one type of unit has to be handled individually while another does not, this would lead to a confusing user interface and needless complexity in the code.

I realize that attached units are linked to individual slots in buildings. So what? Get rid of them. Instead of providing individual slots, buildings should simply increase the number of attached units that can be built. This would have the added benefit that since attached units would no longer be linked to specific buildings, they could be trained in any building when lost. Players have complained about how annoying it is to suffer many casualties in one building and none in another for ages, and this would finally solve that issue.

Any damaged unattached unit would also always have to exist as an individual element as even a stack of damaged units currently at the same health is going to have units damaged at different times so at a different point in their healing.

True, but this only applies on the server side, not the client where the problem is. There is no reason why the client would ever need to track the healing time of all wounded units, all the client needs to know is when the first unit recovers a hit point, at which point the client asks the server for an update. Like this all units with the same health could be stacked, and the client would never need to know when each of them heals.

You have hit the nail on the head. The tracking of (potentially millions of) individual units is a server-side issue.

Sorry, but you got it exactly wrong. Maybe InnoGames has trouble with their database capacity too, but that is not what is causing these problems. If it was, everyone would be having the same issues regardless of how many units they had. The problem is handling thousands of individual units in the client side Flash application, that is what makes the game slow and may cause the game to fail to load.

I have been thinking about a radical idea for solving the many problems the game suffers from. The developers should consider outsourcing part of the work to us players. It has become painfully obvious that they have neither the commitment or the expertise to deliver good quality. From these discussions I've understood that many players understand the problems far better than they do, and have the technical knowhow to solve them. This army management problem would be a good example. The developers seem to have given up, while it took me fifteen minutes to design the necessary database changes, and I bet I could code the entire new interface in a few weeks in my spare time. Simply put, let the players help in fixing the problems, and let the developers focus solely on new content. Though I doubt they would accept this offer, since if they did and were outdone by the players, what exactly would they be paid for?

 

[DeletedUser96867]

I have to disagree on this. It will only be confusing if there are two different systems in use, one for attached and another for unattached units, so they should both be converted to stackable even though the apparent benefit for attached units is insignificant. If one type of unit has to be handled individually while another does not, this would lead to a confusing user interface and needless complexity in the code.

I wouldn't find it confusing in the least. And it isn't that the apparent benefit for the attached units is insignificant it's that for the attached units it would involve more process (--->slow things down). Handling the attached units(with building assignment) and damaged units by placing them on a stack completely unlike the healthy unattached unit stack would greatly greatly increase the complexity of the code and the amount of coding needing to be changed.

While from the players interface side you might find it more convenient it turns a programming ant hill, into a mountain of a chore. It's hard enough to get INNO to do a 5 minute fix on something, or change anything for that matter. Now you are asking them to completely change how attached units are linked(not linked) to the military buildings as well, and multiplying the size of coding problem. The chances of getting INNO to consider this matter is already slim to none, lets not lower our chances.

 

[Rosletyne]

Handling the attached units (with building assignment) and damaged units by placing them on a stack completely unlike the healthy unattached unit stack would greatly greatly increase the complexity of the code and the amount of coding needing to be changed.

What the hell are you talking about?

You are proposing that all attached units, healthy or otherwise, should be kept separate, completely unlike unattached units, which should be stacked. Potentially confusing and needlessly complicated, since attached and unattached units must be handled separately.

What I am proposing is that all units should be stacked. Healthy attached, one stack. Healthy unattached, another stack. Attached with 9 health, third stack. Unattached with 9 health, fourth stack. And so on. Very clear, very simple to code, identical treatment for attached and unattached units.

 

[DeletedUser96867]

What I am proposing is that all units should be stacked. Healthy attached, one stack. Healthy unattached, another stack. Attached with 9 health, third stack. Unattached with 9 health, fourth stack. And so on. Very clear, very simple to code, identical treatment for attached and unattached units.

I've been thinking about this for the better part of an hour and can't get my head around the best way to implement it. The best I can come up with is that all 10 possible stack(health 1-10) for each type of unit which a player has would have to be in existence at all times. For example if you have 1 attached slinger it would actually require 11 individually tracked states. You'd have to have a stack for each health from 1 -10 as well as track the individual unit itself. This is NOT a step in the right direction. As a unit heals from a health state of 1, it would have to be shuffled from one stack to another 9 times. Unless full health unattached stacks are handled differently than all the other stacks you suggest nothing has been accomplished other than greatly increasing the amount of processing involved in handling units, and improving the visual state of the army management screen.

 

[Rosletyne]

and when do units move from stack with 8 health to the stack with 9 health ?

The client application only has one timer for the shortest healing time of any unit. When that timer expires, the client sends an update request to the server, which responds with the next shortest healing time.

For example, the player could have hundreds of wounded units, but all the client knows is that the first one to recover a hit point is a Universal Tank with 3 health. When that timer expires, the counter for 3-health Universal Tanks is decremented by one, the counter for 4-health Universal Tanks is incremented by one, and the client asks the server which unit is going to heal next and when. In fact the game already does something like this every time army management is opened. Of course the player may have up to 8 different units that were wounded at the same time at the same battle (if the timers start when the battle ends) but it is still much easier to keep track of a maximum 8 stacks with a shared timer than potentially hundreds of units with separate timers.

 

[DeletedUser96867]

Of course the player may have up to 8 different units that were wounded at the same time at the same battle (if the timers start when the battle ends) but it is still much easier to keep track of a maximum 8 stacks with a shared timer than potentially hundreds of units with separate timers.

It would be a maximum of 9(damaged) stacks for each unit type, and each individual damaged unit would still have to have it's own separate timer.

 

[Rosletyne]

It would be a maximum of 9 (damaged) stacks for each unit type, and each individual damaged unit would still have to have it's own separate timer.

No. You can only take 8 units to battle at once, so you can never have more than 8 units that would heal at the same time. And like I said, only the server needs to know when every unit heals, the client only needs to know the next one.

 

[DeletedUser14394]

Like I said before, every unit will be having its unique code which is used to keep track of its health, last used time, last damaged time for every individual unit. Shared timer is not at all a good option. Lets make an assumption, one of my tanks were damaged right now, another one 10 mins later. Lets say both have 5 health bars. If you're going to keep it commonly in a shared timer, how will you keep track of that 10 mins diff..? By your shared timer suggestion opinion, it will only add "unnecessary" complexity to the code and very irrititating feeling for regualar attackers when seeing the complex army management screen. Although I support to add a feature to move the highest damaged unit to last and undamaged unit in first to make the army selection much easier, but its not yet implemented.

Did you ever noticed on why the damaged and undamaged troops are always in a mix and not in the order of the health, I can only assume that it's aligned in the order of its unique code. Whatever the feature is going to come, I can be sure that devs have to maintain each unit have its unique code to keep track of more stats. After all from my "assumptions", I can only say that the army cap limit is to stop their database from growing "exponentially", but maybe also due to slow movements in army management screen coz of large no of units. Maybe I'm completely wrong about that database part, since no one knows about it except the Inno team. But I've a feeling that I'm correct about those unique codes and tracking health using unique codes.

Coming to the original Issue,

If Inno worried about the slow performance of games due to large no of units in army pool, then they can simply overcome it. Even I've lot of suggestions to overcome that. But it's not the problem like we think. It's something that relates to the management of their resources like database size. But If they announced this units cap limit solely due to the fact of slow game performance, I've "nothing" to say. They've the knowledge to create this awesome game and introducing this only due to the fact of slow performance even it can be simple overcomed..? Think from the scratch. It "maybe" something that relates to their resources.

Note: "maybe"

 

[Rosletyne]

Shared timer is not at all a good option. Lets make an assumption, one of my tanks were damaged right now, another one 10 mins later. Lets say both have 5 health bars. If you're going to keep it commonly in a shared timer, how will you keep track of that 10 mins diff?

Did you even bother to read what I wrote? Only the server needs to know when every unit heals, the client only needs to know the next one.

In your example, the client would only know when the first tank heals. When that timer expires, the client asks the server which unit heals next and when, and the server responds that another tank heals 10 minutes later.

Your assumption that the units would be organized according to their unique code is also incorrect, since if that was the case, they would not be shuffled every time a unit is selected or deselected. And what stats are you talking about? The only stats any unit has are its type, whether it is attached and its health. Unique codes are not actually needed for anything, not even on the server side.

 

[DeletedUser14394]

And what stats are you talking about?

The status I'm talking about is every unit's creation date and time, last used time, last damage time and remaining health slots since it can be covered within last damaged time. If they dont have unique codes to each and every unit, it's the worst case since nothing can be checked on the logs if a bug appears or something unexpected happens. There are hundreds of roghues in a pool and how will check a particular roghue. None of the units would be counted as 55 tanks, 255 roghues and so on. Everything in here is controlled by the server since the client is just an UI version to it. That's why none of the server games are practically impossible to get hacked unless it's poor.

About your thought of - "client needs to know only about next healing time", damage all your attached units and open up your respective military building. You can see the exact time for all the damaged units to be healed also in accurate seconds. According to your case of "useless" unique codes, I dont have any other alternate way to keep track of every unit. Since the issue is only relating to the unit cap limit, but this is going on somewhere else. My assumptions are only told to make some clarification to others on it's not only due to slow game performance, but it's related to something big which is out of our box thinking.

Your assumption that the units would be organized according to their unique code is also incorrect, since if that was the case, they would not be shuffled every time a unit is selected or deselected.

I can only say that you didnt take a closer look at your unit pool. Take one particular pool of units, (eg: roghues or tanks or anything else).. Go to a fight and atleast injure your one troop intentioanally. Then after the battle, go to army management screen and deselect everything from attack army pool to total army pool. Now note down the position of your injured unit. Next select that injured unit which will take it to the attack army pool. Now deselect it which brings it back to total army pool. Now count the position of that injured unit. It'll exactly match with the previous position. It's not just randomy shuffled. It's aligned in some manner, which is by the unique code by my assumption.

 

[Rosletyne]

The status I'm talking about is every unit's creation date and time, last used time, last damage time and remaining health slots since it can be covered within last damaged time. If they dont have unique codes to each and every unit, it's the worst case since nothing can be checked on the logs if a bug appears or something unexpected happens.

I can't think of any use for that kind of metadata, even for logging purposes. Certainly not on the client side, where there is no logging.

It's not just randomly shuffled. It's aligned in some manner, which is by the unique code by my assumption.

You are still not correct. Your example works with one injured unit yes, but what about two? If you have two injured units in the pool and select one, the other one changes its position, proving that the units are not sorted based on anything. There may be a pattern to how they are shuffled, but there is no apparent logic to it, so it might as well be random.