Its clear the developers don't care

[Yttrill]

And I'm a coder too. I just don't consider people with a partial understanding of any complex system offering advice or opinions on the devs. .

I know you are. So lets be clear, I was taking exception to your assertion "bugs are ALWAYS there.". This is simply NOT true.

Here is an article about the reward for finding bugs in TeX: https://tex.stackexchange.com/questi...h-reward-check
This is quite famous. It is for the whole of TeX, which was originally literate programmed Pascal published in a book so it is no small piece of software.

There are people such as these: https://ts.data61.csiro.au/ who develop systems such as this: http://ts.data61.csiro.au/projects/seL4/ which is an operating system microkernel that not only has no bugs but also meets certain performance guarantees as well. Proven, and the proofs are not paper proofs, but proof validated by Isabelle proof assistant.

There are components of complex systems which have no bugs, a LOT more than you might think. For example Ocaml's map data and set data structures were analysed by Coq proof assistant and actually a single failure was found, the tree not being perfectly balanced, which was corrected and only impacted performance not correctness: the analysis proved the code was correct.

My point again is that in environments where it matters, typically mission critical embedded applications, software is often entirely bug free, either by being proven correct, being very thoroughly tested, or simply being written by a really good programmer. I can't claim there were no bugs in the Apollo II software, but it was certainly complex enough and it worked as expected. Here is a picture of the author Margaret Hamilton standing with a listing of the program: https://commons.wikimedia.org/wiki/F...t_Hamilton.gif

Its true, I made a comment about the situation the devs are in and that is a generalisation and assumption. It could be incorrect. It is a guess that they have the same financial problems as most small dev teams in this market and that explains why so many bugs in the rushed AnB. So my guess is that it is not that the devs don't care, but that there is actually a reason for the poor delivery. Perhaps you are right, it was not my place to make such judgements.

[lmcelhiney]

There are clearly as many different programming languages as there have been bugs in Eternium... (The quest for the perfect programming language is similar to my wife searching for the "perfect" purse. :-)

None of our discourse on the best coding language; the best ways of ensuring perfect code; the best ways of alpha/beta testing; the design life cycle; the number of resources needed to ensure "mission critical" success; etc. are based on any knowledge of the Eternium programming team; their goals; their priorities or their resources.

Hopefully, the return of the programmers to their workstations will result in the necessary improvements to this highly entertaining game!

[duckel]

still wouldnt be asked too much to open the stupid eboxes before starting anb... or give the whole crafting exploits a thorough thought before not-fixing it.

[Shilien]

Devs should have told a word themselves about bugged jewelry and behave respectively that word. Instead it turns out Travis said A, devs did B and sh.t finally happened. All their work seems from my point of view like shutting many holes at house wall with old rags instead of thoughful recovery when a stone couldn't have a chance to fall on your or your neighbor's head.

[LodWig]

My point again is that in environments where it matters, typically mission critical embedded applications, software is often entirely bug free, either by being proven correct, being very thoroughly tested, or simply being written by a really good programmer.

Case in point: the ATP of Paris Metro lines 14 and 1, proven correct with a formal method (the B Method), proofs being done automatically, or manually then checked by a prover software. The ATP is the part of the automatic train software that is in charge of avoiding collision, overspeed and other hazards. Lifes are at risk.

[TerryDarc]

I know you are. So lets be clear, I was taking exception to your assertion "bugs are ALWAYS there.". This is simply NOT true.

Here is an article about the reward for finding bugs in TeX: https://tex.stackexchange.com/questi...h-reward-check
This is quite famous. It is for the whole of TeX, which was originally literate programmed Pascal published in a book so it is no small piece of software.

There are people such as these: https://ts.data61.csiro.au/ who develop systems such as this: http://ts.data61.csiro.au/projects/seL4/ which is an operating system microkernel that not only has no bugs but also meets certain performance guarantees as well. Proven, and the proofs are not paper proofs, but proof validated by Isabelle proof assistant.

There are components of complex systems which have no bugs, a LOT more than you might think. For example Ocaml's map data and set data structures were analysed by Coq proof assistant and actually a single failure was found, the tree not being perfectly balanced, which was corrected and only impacted performance not correctness: the analysis proved the code was correct.

My point again is that in environments where it matters, typically mission critical embedded applications, software is often entirely bug free, either by being proven correct, being very thoroughly tested, or simply being written by a really good programmer. I can't claim there were no bugs in the Apollo II software, but it was certainly complex enough and it worked as expected. Here is a picture of the author Margaret Hamilton standing with a listing of the program: https://commons.wikimedia.org/wiki/F...t_Hamilton.gif

Its true, I made a comment about the situation the devs are in and that is a generalisation and assumption. It could be incorrect. It is a guess that they have the same financial problems as most small dev teams in this market and that explains why so many bugs in the rushed AnB. So my guess is that it is not that the devs don't care, but that there is actually a reason for the poor delivery. Perhaps you are right, it was not my place to make such judgements.

To the point: no one is a) going to prove the correctness of Eternium. I suggest that that is impossible and b) no one is going to re-write the whole thing. I would guess that there are layers and packages of code involved as well, making any proof something that would take until the heat-death of the universe to be able to assert correctness. Let me correct my assertion: in a significant body of code, say 100k lines, which is to say peanuts, none are error free, least of all our game of choice.

Lord knows I'm all for clean, reliable code. I doubt that a proof analyzer is going to help Eternium esp. since much of the code (I suspect) was not written in house but purchased as a package, maybe from sources we are not familiar with. Wonder if there are trap doors or other Trojan horses that help the current level of cheaters entry?

That is hardly controversial. My real point was that there is a culture + body of code supporting Eternium that is unknown + development team + management + the publisher. All of them can have their fingerprints on the game we play.

However, the game seems pretty reliable from Google play, beta to me. Assertions about whether the devs really care or are working hard to make the game more bug-free is unknown and unknowable. We know of only two devs and the probable number of bugs is probably in the hundreds or thousands. They are surely prioritized most likely and are all not going away. What we as users can do is write the clearest bug statements/reports we can. I don't see that here, nor in your original post. My sympathies are always with the devs and not their mgt. team who can make fixing bugs nearly impossible as you probably know.

[LodWig]

ATP of Paris metro line 14 : 86K loc. You win i guess 8-)

[Yttrill]

Case in point: the ATP of Paris Metro lines 14 and 1, proven correct with a formal method (the B Method), proofs being done automatically, or manually then checked by a prover software. The ATP is the part of the automatic train software that is in charge of avoiding collision, overspeed and other hazards. Lifes are at risk.

heh .. the programmers are coming out of the woodwork now .. :-)

[Yttrill]

To the point: no one is a) going to prove the correctness of Eternium. I suggest that that is impossible and b) no one is going to re-write the whole thing. I would guess that there are layers and packages of code involved as well, making any proof something that would take until the heat-death of the universe to be able to assert correctness. Let me correct my assertion: in a significant body of code, say 100k lines, which is to say peanuts, none are error free, least of all our game of choice.

My point is that it is likely a matter of economics. I haven't seen a reasonably complex game advertised in mystery boxes that i checked out, that is not slammed by reviewers for the huge number of bugs, especially in updates and events. I agree with little evidence that Eternium is actually quite good. However it is not a matter of the code size. Reliable bug free complex large scale code can and is written, by building it with reliable components, and well considered designs. I worked on telephony systems which were 1-2 million lines of C++ which took over 24 hours to build in the '90s and whilst surely not bug free, well, you just can't have telephones not working! They also had around 40 programmers working on that system, all with electrical engineering backgrounds, and thousands of pages of both general and detailed specifications including IEEE and IEC standards documents. The price tag on a copy matched the investment in the product development.

The economics of free phone games doesn't support that well. To be fair I haven't found a single bug in SimCity Buildit, but its a much simpler game.

Generally, I agree with you, I think you were just too unconditional in your claim.

What actually annoys me is that some of the recent bugs were trivial logic errors. I expect bugs in complex graphics and interactive battle logic, but leaderboards? It sure would be nice if my AnB hero was ranked 293 with 6 hours play time left :-)

[Yttrill]

I also think some of the design faults need to fixed. These aren't bugs in the coding.

1. The targeting system is crap on a phone. Heroes running into packs, etc. It needs to be fixed urgently. I don't know exactly how, but the game is unplayable on a phone otherwise. I even run sometimes when trying to draw a rune. Drawing runes when moving is impossible so I have to actually make my hero stand still by attacking, just to draw the rune, and I need to be at max distance from the closest approaching skeleton to have time to draw runes (Shatter requires two runes FFS!).

2. Garm needs to be fixed. If he spawns near a rock, there's no way to run around to the blue circle in time. Also on my phone if I'm above or below him sometimes I can't draw a rune at all. I have to run to the sides. I can't fight from above or below. (Also I can't see Kara's knives if I'm above or below, so again, I have to run to the side. Its true for Elban and Magroth too but they're small so it doesn't take much time to reposition, nor much precision since they run up to attack at close range) Both dragons suffer the kiddy bug that if you tap to move and the graphics get in the way eg by wings flapping, you attack instead of moving. The camera elevation with Garm needs to be higher on a phone. TBD is tough if he spawns in the wrong place but its tough not impossible. Garm is plain impossible. His attack range could be reduced and he could follow much faster. He's a lazy sod. I don't know the answer.

3, Switching primary attacks by using two fingers for the second slot is unusable.

4. Firebolt needs to be buffed. Also burn damage from FB should stack but doesn't seem to, for thermal shock it should stack temporaly not by intensity, but either would be good. Maybe it does, but it doesn't seem to to me. It does less damage the frostbolt because it affects an area, but frost bolt at level 10 slows targets, meteor just doesn't do enough damage even with 500% buff to compensate.

5. When fighting the bosses an area is cleared nearby, but it isn't big enough if you're using shatter. I get killed by stray skeletons more often than the boss. Its fine for Elban and Magroth because you can move and they follow, but the dragons (despite having wings) don't follow. Well .. TBD is broken so he can't fly. The dragons are just too big.

It's up to the dev play testers to try to play to a high trial level on a phone. Not a pad, a phone. Having verified the issues some solution needs to be found and tested. The game currently needs both precision and speed and that isn't available on a phone. IMHO it would be boring if it weren't fast so the need for precision needs to be removed.