immortius wrote:The fundamental point is I dislike the way that suggestions are being treated on the suggestion forum at the moment. Sure, say how the existing interface can let you achieve something, maybe provide some constructive criticism -
What's your definition for constructive criticism? Asking a person to justify his suggestion by demonstrating a problem and showing how the suggestion is an improvement seems constructive to me. First passes of many suggestions too often take the form "here's how I think this should work" or "this is how things work in another game". Devil's advocate can help improve those suggestions, too.
I trust Generic Container will exercise judgement when reading the suggestions.
He has largely kept his own counsel, but that doesn't mean we need to let suggestions here go without feedback. Presumably they are submitted here to be discussed.
Walker wrote:That's precisely the point. Why make things more difficult? Currently, if you want to move wood from one stockpile to another, you allow wood for the second, and dismantle the first.
Those two processes aren't equivalent. The first is totally destroying a stockpile to move all its contents elsewhere. The second moves part of the contents while the original stockpile still exists.
They are when you want to move all the contents elsewhere. The question arises which use cases are typical. And an even better question "what is the player trying to accomplish"?
Actually I mean usability, of which learnability is a subset and accessibility is related. I wasn't trying to be technically correct and honestly I wasted too much time writing that post anyway. And this one. Takes hours and then someone nitpicks through the whole thing.
Did you really mean to say that you want us to discuss things, but think participating in a discussion is a waste of time? Or am I nitpicking again?
This isn't about claiming that the game needs to be learned instantly on first glance, or achieving perfection. It is about suggesting incremental improvements to mechanics and UI to make the game more usable/learnable.
If it is possible to make it easier to handle certain aspects, why not do so?
If it is counterproductive to wider aims it shouldn't be done. If SMB came with a button to auto-complete a level, it would make things easier, and pointless. The backrest on my chair is comfortable, but a backless chair would spare me a lot of back pain in the future.
Why do people want to move things between stockpiles? I almost never do that, and it seems an indication of failed planning. If, and I don't assert it is, the reason for the feature request is to cope with the results of failed planning, having to tear a failed stockpile down and build a new one sends a stronger signal that mistake was made, and may thus facilitate faster learning of good design principles. I think game should steer players towards good habits.
That is, UI should make it easy for people to do things they should be doing, but it is not necessary to make it easy to do things they shouldn't be doing. Simply suggesting an interface change without explaining what use case is being served is not most useful thing.
We certainly don't want things moving in the opposite direction, do we?
Depends on things. Games are something of a special case in UI design, as it is often not desirable to make things too easy to player. Interface in a strategy game, granted, rarely falls in that category.
Intuitiveness is overrated, it is enough that things are learnable.
Things which are intuitive are easy to learn though. This is one of the reasons physics games are popular to make, because the mechanics line up nicely with our expectations of how things should behave.
Yes. First placing a container and then putting items in it fits my expectations. You don't first fill a warehouse and then try to add shelves. It's good when game mechanics line up with the real world, but I'm not sure they need to line up with expectations formed by other games, for example.
My problem with many of the supposed fixes suggested on this forum is that they don't actually propose a clearly superior system, or at all address the underlying learnability issue: they merely swap one set of expectations for another.
Then please participate in discussion in a constructive manner and perhaps we can come up with a system that does.
If you think I'm not, I'm not sure I can be a lot of help.
Surely their suggestions are open to criticism.
Constructive criticism, not telling them the current system is fine and their problem is non-existent. Or that it isn't worth developing the changes to the UI. Or they should read the forums to learn how to play.
Has anyone actually said any of those things?
It needs to be made more obvious, but that doesn't necessarily mean introducing a new way of doing it. Pointing out that the current way to do it is the way to do it would also work.
That would also be fine, but the destroy->recreate stockpiles mechanism may also just be a work around rather than a proper way of doing it. It seems very heavy handed and generates more jobs than necessary if you only want to move some items.
Orcs should be heavy-handed, so it fits the game. But we come again to the question why players would want to move things from container to another. That should be answered before considering UI solutions.
I can think of two scenarios right now:
1) Recovering from failed stockpile allocation. In this case I think game should signal the player they have failed, and current system does that well. Also, there's no reason to move decaying items, as they will rot away on their own, and items in use will be removed eventually. That's not obviously slower than goblins removing them as low priority jobs, and if the player needs this done ASAP, he'll probably end up blowing the stockpile anyway.
2) Moving things from a remote stockpile to one closer to point of use. This is a thing I often wish I could do with charcoal. Currently there's a trade-off between fire safety and efficiency. Ability to feed items from one stockpile to another would reduce the efficiency penalty, but that would make the problem less interesting, and so the game a little more boring. I'm not sure supporting this functionality, much as I'd want it, would be an overall benefit to the game, especially if it made stockpiles more complex.
True, but an interface change to afford one's preferred style of play doesn't automatically make a game better. And some of the suggestions here end up with every item in every stockpile surrounded by checkboxes and sliders, and I don't think that would contribute to gradual learning. On that front, I think, GC is doing well, with every tier opening new constructions, and every new construction introducing new items, though the tier progression may still be a little fast.
True, so suggest how these ideas can be improved! What I like about the Accept/Hold/Refuse system is it merely adds an extra state to the existing system, minimizing the change to UI and not adding any clutter. And it is also a proven mechanism in Caesar 3. But I guess the check box needs to make obvious what those states are and mean somehow.
Okay, here's a suggestion: if 'hold' is merely 'don't accept', why is it a separate check box? Just have the check boxes for 'accept', like now, and 'remove'. There's even a case for checking both: sending things from a stockpile close to point of production to one closer to point of use.
But that doesn't necessarily make things more learnable than things are now; player would still need to learn what 'remove' does. Lack of documentation is currently the biggest problem, IMO.
But really, I'd like a convincing case made for including the functionality before planning an interface for it.