which goon placed the countdown?

2»

Comments

  • ichijuan wrote:
    I think usually is the one with more health.

    But i think is fair we dont know who put it there. That would make it way too easy, c'mon.
    This is needs to be challenging, right?
    When you fight goons with 2x health compared to your heroes and abilities that can KO your entire team it's not fair at all. When you have the broken scaling determine that you can handle them with your 2* or your 85-100 level 3* it is even less unfair. Once again I am puzzled by the design decisions in the game. Here we have a change that should be easy to make since the devs are able to choose the starting levels of the enemies, but so far nothing has been done. This reminds me of the respec system. It was so easy and simple to create, yet it took months to introduce. Why? No idea. Maybe they like making everyone's life difficult. It's a hard acquired skill which they have honed to perfection.
  • Thanos
    Thanos Posts: 722 Critical Contributor
    I've had good luck choosing the goon closest to the first position. They tend to place CD tiles in order, goon 1-2-3.
  • Verno5x wrote:
    pasa_ wrote:
    Nemesis wrote:
    tinnykitty those tinnykitty goons....... icon_mad.gif

    I say <censored> devs -- they had time for all irrelevant work like slanted tabs and animating HP but indicating counter ownership we asked hundred times over since day one is still sitting. Sure some excel sheet guy calculated it would drop the health pack use by some amount so it's red light. icon_evil.gif

    You don't actually think that the same people who do the design work for the game are the ones who program the systems, right? A game studio (in general) is composed of designers, developers, product managers/producers, and QA at a very basic level. They also likely have 2+ smaller teams of these people if they use the Agile project management method, which a lot do. The bulk of the work for the "slanted tabs" and "animated HP" would have been done by a designer(s) with a much smaller amount of work from a developer to plug in the new graphics and animations. This allows the designers to make visual improvements while developers can focus their work on improving other systems in the game.

    Is that technoblabla supposed to reveal or conceal? Look, my first game was put on the market exactly 30 years ago, and though I moved to other areas keep fielding working stuff ever since. And in all that time I saw how stuff is created for good and bad. And have a good idea on work allocation, departments, chain of command, and all the other aspect covering both the structure and the life cycle.

    The task we're talking about would go on sprint with a 4 hour estimate tops. Whoever voting a bigger figure would have really hard time to explain where he intends to spend more really. And I'd expect half the team voting for half. And the related core change is 10 minutes tops. The tile already has a text displayed. All you need is to change one word in that text -- like Soldier -> 'Soldier #1' if they are multiple. Plus smuggle the #1 info to the panel you open clicking the goon.

    If the process has any trace of actual 'agile' then it would go with the incremental approach that just provide the useful info with minimum effort applied. It can be improved later. Or made nicer, etc. Practice clearly shows that just a brainstorming session on how to provide the said info would consume more time than having the minimal but perfectly useful Mark I. But all that only shows the broken process that fails to concentrate on VALUES let alone the customer satisfaction.

    And yes, I keep whining about it, and pointing out the bad ways, and assign the shame to devs. You know why? Not JUST because they deserve it icon_e_wink.gif.

    The main reason is most teams actually has people like me, those who feel the pain of the users, those who feel the shame for these things despite others are responsible, and would actually deploy the improvements if just were allowed to. And they do the same whining sessions inside the gates. Exactly as futile as ours here. For the time being at least. But they at least gain same ammo and support for their trouble.

    The most common phrase to kill a change request is saying the users don't really want it, or "we had no user complaints" in the area. That keeps coming even if thousands of bug tickets are open just the mapping is not that clear. If we just post the request once and hope it gets ever processed someone will very likely say it is no longer hot. And can be safely buried.

    TL;DR: Whining is not what we like at all but is the only practical way to push for changes to actually happen