• Dear forum visitor,

    It looks as though you have not registered for a forum account, or are not signed in. In order to participate in current discussions or create new threads, you will need to register for a forum account by clicking on the link below.

    Click here to register for a forum account!

    If you already have a forum account, you can simply click on the 'Log in' button at the top right of your forum screen.

    Your Elvenar Team

Behind the Scenes: The Spire of Eternity Feedback

Socrates28

Well-Known Member
I think what is more likely than a deliberate nerf, is that the Elvenar staff do not know whether they can fix the problem with the system they have in place.
One of the realities of modern day programming is that some (most or all) programming is sub-contracted to outside code writers. Depending on the extent of this reality, those doing the coding may not be totally familiar with what has been done before. There is also the reality of employee turnover which would also account for a lack of familiarity with what is already in place. It usually takes 2 times (or more) the time for a new person to pick up what has been dropped in their laps. Not only must they understand the goal to be reached, but how the previous person was attempting to get there. That is not always easy to figure out. Been there and done that a few times in my programming experience.
 
Last edited:

Ashrem

Oh Wise One
One of the realities of modern day programming is that some (most or all) programming is sub-contracted to outside cose writers. Depending on the extent of this reality, those doing the coding may not be totally familiar with what has been done before. There is also the reality of employee turnover which would also account for a lack of familiarity with what is already in place. It usually takes 2 times (or more) the time for a new person to pick up what has been dropped in their laps. Not only must they understand the goal to be reached, but how the previous person was attempting to get there. That is not always easy to figure out. Been there and done that a few times in my programming experience.
That is often the case for legacy code, but not common in a not-yet-feature-complete beta.

The failure of the magic building prizes is symptomatic of a software industry that clings too tightly to a rapid development cycle and prizes new features over stability. I'm not asserting that they decided the buildings were too generous, I'm saying that this early in the development of the code for the spire, they shouldn't be uncertain whether they can fix deploying something that they deploy in other ways with no problem. People buy those buildings every day. they managed to give one to every city on every server when they nerfed buildings. There's really no excuse for not being sure if they can fix it.
 

Socrates28

Well-Known Member
That is often the case for legacy code, but not common in a not-yet-feature-complete beta.
In my experience I was not speaking of legacy code at all. I was looking at current development on a project that would impact the entire company. I could read what was there and not understand why they did it that way or even what they were thinking it would accomplish. This is sometimes the problem when one person looks over another's coding.

The failure of the magic building prizes is symptomatic of a software industry that clings too tightly to a rapid development cycle and prizes new features over stability.
On the other hand I agree with you totally on the "need for speed" mentality in not only the software industry, it is pandemic in industry after industry. Some people only look at return on investment and want to maximize the return and minimize the investment. In many cases it just ensures failure.
 

Ashrem

Oh Wise One
In my experience I was not speaking of legacy code at all. I was looking at current development on a project that would impact the entire company. I could read what was there and not understand why they did it that way or even what they were thinking it would accomplish. This is sometimes the problem when one person looks over another's coding.
In a feature that is not yet complete, contract coders should be irrelevant. The contract isn't fulfilled until the code is delivered as agreed to. In code that is being taken over because someone else left, that is far more than half the time, code that has been around for years. They can't have working on this feature for more than a year, and it is far from complete, so problems disseminating a single category of prize should not be buried deep in ancient code that no-one around understands. If they suddenly lost the development team for a new feature before it is finished, they shouldn't be deploying any of it until they have a new team familiar with the code.
 

Deborah M

Oh Wise One
Along those lines, I saw a company have to shut down a game when they closed a regional office and going forward there apparently was not anybody who could figure out how to fix a cascade of problems with all the original people gone. That brings to mind Timon moving to another game. Surely they would bring him into the loop if he could help with an Elvenar problem. Or maybe not?
 

Socrates28

Well-Known Member
They can't have working on this feature for more than a year, and it is far from complete, so problems disseminating a single category of prize should not be buried deep in ancient code that no-one around understands. If they suddenly lost the development team for a new feature before it is finished, they shouldn't be deploying any of it until they have a new team familiar with the code.
Two points: They may have indeed tried to use legacy code by copying and pasteing it in to the new feature and it did not work because something downstream, so to speak, has changed.
Second: I agree with you about not deploying it until it was finished. Please see my previous comment on "Need for speed."

New thought: Perhaps they put it out purposely before it was finished to get the community really involved in a new aspect of the game? Especially the Beta group as they as the most invested in exactly how the game plays and its "feel", so to speak.

Over all I do not think we disagree on anything but small points of view.
 

Ashrem

Oh Wise One
Well, given that that neither Coke or Pepsi are fit for human consumption, I have no problem with Coke being "better" than Pepsi. And as long as we understand that any colour of smarties is better than any colour of m&m, I'm willing to agree Yellow are better than the others. The rest is all a given. So we're fine so far.
 

Jackluyt

Platinum Leaf -FB
News from Beta about the Spire of Eternity

Dear Humans and Elves,

This is a short update to the state of the Spire of Eternity to inform you that we have activated the Manual Battle in the Spire of Eternity. You will be able to choose between either using the Manual Battle, where you can decide the next moves of your troops, and the already available Auto Battle, in which the game's AI will fight on your behalf.

Head over to the Spire of Eternity now, and see if you are able to beat those fights a bit more easily now, especially in the later encounters and the wave battles that you told us were difficult to complete with Auto Battle! :)

And as before, please let us know your feedback by posting in the discussion thread, and reports any bugs you find in the Report a Bug section of the forums.

Thanks to everyone who has played the Spire so far, to everyone who gave their feedback, and for all the bug reports!

Kind regards,
Your Elvenar Team

MarindorSig02.png
 

DeletedUser23463

Guest
I keep looking for someone to explain how Spire enemy squad sizes are calculated. Are they punishing those who have researched all the squad size upgrades - like in tournaments? Or is enemy squad size calculated from player's chapter or some other means?
 
Top