Its clear the developers don't care

[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.

[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]

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 .. :-)

[LodWig]

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

[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]

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.

[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.

[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.

[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!

[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.

[TerryDarc]

TeX is a lot longer than 76 lines :-)

Sorry but this is not from outside, i'm a software developer, in fact I helped design C++, so I know a bit about it. Its not good. Java is worse tho :-) And no, Linux i refer to is the kernel and there is exactly one (for each released version I mean). True, there's lots of stuff on top of the kernel you'd call an OS, including device drivers (which are often bugged). Supporting any software on multiple platforms is always an issue due to the need to work around bugs in them. I know, I have a developed a complete multiplatform programming language. Actually designed for games (among other applications). So I dare say I know a bit about this subject. Having been doing it for almost half a century. So I think the laugh may be on you :-)

And Tex is not the "perfect code" - that was a tiny piece of code. 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. Sugest you watch the promo video on the main menu. You may learn something.

[Yttrill]

I'd take Java over C++ any day for non-game, non-low-level development.

It has advantages, certainly. Probably if you work in an environment it is suitable then you should use Scala instead, since its Java compatible. Scala is not bad, given the constraints. Many systems actually use both, in particular Android uses a Linux kernel written in a restricted subset of C, but the application Api is Java. If you're doing apps on a Mac you have to use Swift, which is actually a decent language on replacing ObjC. If you're doing browser client software you have to use Javascript. If you stuck with performance and interfacing requirement that dictates C/C++ compat, then you probably should use the language I developed, Felix.

Games generally have to use whatever API is chosen to run the core engine, eg Unreal, to quote from their website: "Unreal is a pure C++ engine designed for high performance. Its advanced CPU/GPU profiling tools and flexible renderer equips developers to efficiently achieve quality VR experiences." No one these days develops games from scratch, so you have to build on top of something that provides multi-platform support. Gone are the days Doom, assembler for one platform, the PC, which owned the market.

But my point is also that the market dictates software quality. I've written bug free software in assembler, running embedded devices that controlled safety critical devices (lighting), and which were bolted to the walls of buildings, an environment where a bug leading to a product recall would probably break the vendor. Even more critical software like aviation control .. well Boeing found out what a design fault can cost (not a bug). In the free game environment that Eternium lives, software gets rushed out without much testing because no one is paying for it directly. You just let the clients test it and hope you've done a good enough job that you will retain and gain users that will buy in game speedups and/or watch ads.

Eternium, in my opinion, has great potential, but the devs have to be worried because for such a great game, the number of players is very small. So they're rushing out AnB, War Spoils, Season passes and other things to try to capture more income. And so there are bugs because of the rush. You can call it greed but there's a minimum number of people required to run this kind of product, and they all want their wages at the end of the day. So the problem is really that small companies just dont have the financial resources to take the time to build a user base and monetise their product later. IMHO of course.

[Terranisaur]

TeX is a lot longer than 76 lines :-)

Sorry but this is not from outside, i'm a software developer, in fact I helped design C++, so I know a bit about it. Its not good. Java is worse tho :-) And no, Linux i refer to is the kernel and there is exactly one (for each released version I mean). True, there's lots of stuff on top of the kernel you'd call an OS, including device drivers (which are often bugged). Supporting any software on multiple platforms is always an issue due to the need to work around bugs in them. I know, I have a developed a complete multiplatform programming language. Actually designed for games (among other applications). So I dare say I know a bit about this subject. Having been doing it for almost half a century. So I think the laugh may be on you :-)

I'd take Java over C++ any day for non-game, non-low-level development.

[Yttrill]

Horsefeathers! Software is never "free of bugs". I suspect that supporting E on multiple platforms - 4 at least - is a source of difficulty. Maybe a small dev staff contributes. Could be management issues. Devs may not speak the same language as the marketers. C++ and Java are "garbage"? They are just languages. Linux is just a name for a family of OS's upon which you would build things including gaming/video/graphics platforms. It comes in flavors. It makes me laugh to read sw reviews from the outside.

Knuth's bugfree code was IIRC 76 lines long.

TeX is a lot longer than 76 lines :-)

Sorry but this is not from outside, i'm a software developer, in fact I helped design C++, so I know a bit about it. Its not good. Java is worse tho :-) And no, Linux i refer to is the kernel and there is exactly one (for each released version I mean). True, there's lots of stuff on top of the kernel you'd call an OS, including device drivers (which are often bugged). Supporting any software on multiple platforms is always an issue due to the need to work around bugs in them. I know, I have a developed a complete multiplatform programming language. Actually designed for games (among other applications). So I dare say I know a bit about this subject. Having been doing it for almost half a century. So I think the laugh may be on you :-)

[Oldandslow]

Tend to agree with TerryDarc on this subject, as someone who grew up coding, actual assembly on Amigas the more code you write the greater the chance of a totally unexpected bug increases. Even with modern languages and tools to develop the scale of the coding in a game is huge and bugs will crop up.

The hardest thing about removing buggy code is that what would appear a simple patch or remove of the offending code often leads to much bigger or many more errors cropping up.

I've nothing but respect for people who code software with the intention of doing it for nothing or next to nothing, it's a thankless task.