You're answering something nebulous-and-unquoted from a month ago, before the idea got tweaked and I said I might even support it (and did when the vote was conducted, which has been over for a couple of days and the idea is already forwarded), by listing a single example of where it might prove useful, while ignoring that my primary objection is that it might be deemed "sufficient" to cause them to never deliver a feature that many people want (Manual combat option on mobile).
Followed up by:
- throwing out low-ball code predictions out which ignore
that besides delivering details about the new map (because clients aren't allowed to know details until they are presented, let alone create them locally), mobile device and browser clients will need code to deal with the map
- that art will be needed and an unknown but large number of devices will need to fetch the art either
1) a minimum of once per tournament (while having even more code to adapt the display to the ensuing battles) or
2) receive a new graphic asset for every single combat.
- failing to factor that either:
1) it needs yet more code to be able to disable it (in which case a large number of people will disable it) or
2) it will generate complaints because people who don't want it can't disable it.
Currently all that needs to be sent is the list of enemies, then a return of the selected enemies, then the result. Now data has to flow for details of the combat even though we don't get to actually fight the combat, instead of just implementing manual fighting.
Was your sole intention to cause yet another in a long line of arguments (about something that is already finished), or did you actually feel like there was a point to dredging up a completed suggestion where nothing we discuss can have any affect on the result?
Code predictions are based on 30 years of coding. If I have managed to achieve anything in my 30 years as a program designer, it's a solid ability to envision what it would take. As for "ignoring" that browsers clients and mobile devices will have to "deal with the map" shows a bit of a confusion over what a map would be in the code. Since it's not an active component, it can be treated just like the icons for the type of troops against whom you will be fighting. The window is populated with those icons, the active components are added, then the window is displayed and activated. The coding would simply add one more displayed item -- a small picture of the terrain-map. It need not be a large thing, maybe the size of one of the enemies. The only real overhead would be making the map icons, and adding code to pick the correct one to populate the screen. Since the various maps already exist in active form, you can produce them pretty easily as representative icons. The code to call and populate the fighting screen is, perhaps a couple to 10 lines. As for the mobile device the same procedure, though, of course, the screen may be too small to actually see anything....not a problem with coding but with screen size.
The fetching of the art is the least of the overhead since it's likely buried in a sub-routine to populate the fight screen. Adding a few lines to check what terrain map is going to be used and then picking that map to display in the window, is trivial.
As for people complaining that they have more information at their fingertips, I'm not sure why anybody would care. If it doesn't slow down things (and it wouldn't to any appreciable or probably detectable degree), they might complain, but why? Thus, no need to "turn off or turn on" though that would be a nice thing to have. Personally I wish I could disable a lot of things in the game, but I never complain because I recognize that others may like those things. The game is not my personal toy and if I really don't like some little thing like "my fight window has a map where it didn't before" I don't have to play. I do think your estimate of the complaints to be higher than what would likely occur.
As for you final point about "dredging up a completed suggestion" being my intention, I do wonder why and who makes the final determination that the subject is "closed" or, in your words, "finished?" Remember, if you think the subject is closed, why respond to my out of date comments at all? It's sort of like a football game having completed, you get bent out of shape because somebody is trying to run another play. Who cares?! It isn't going to change the outcome. The subject is closed, finished, kaput, and done and nobody in the stands is going to sit around watching a bunch of foolish people run more plays. But since you did include some response to my points it is pretty obvious that you felt you had not had your last word on the subject and that my comments needed a (new?) reply.
Finally, I might suggest if you've already said everything that can be said about a subject you should let the other guy ramble on foolishly. Since the subject has been finished and everyone interested in the subject has already heard all the arguments anything the poor guy says will appear as a lot of hot air. Those who know the subject can see for themselves that that is the case. No need for a assist in the matter, right?
AJ
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
