glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] Is this project dead?


From: Kyle L
Subject: Re: [glob2-devel] Is this project dead?
Date: Sun, 29 Dec 2019 11:50:55 -0600

I think this is one of the trickier parts of glob2 and keeping a good user experience. On some parts of this argument I agree with Stephane, on others I agree with Dryad. All of these ideas have their pros and cons and none are necessarily bad. I think this is a situation where we really need to gain more player feedback before we start making changes. If we were a gaming studio, this is where I would start doing A/B testing and player interviews to determine the best choice.

Kyle


On Sun, Dec 29, 2019 at 9:39 AM <address@hidden> wrote:
On 2019-12-29 11:51, Stéphane Magnenat wrote:
> On 28.12.19 17:35, address@hidden wrote:
>>> Regarding bars, what do you mean proportional? Currently a bar of
>>> length N represents N * k elements, with k being proportional to the
>>> width, respectively the height of the bar for vertical, respectively
>>> horizontal bars.
>>
>> http://www.winterdryad.co.uk/bars.png
>>
>> I mean something like this. What do you think?
> Personally I prefer having bars at different locations to denote
> different statistics (bottom: HP, left: food capacity/current, top:
> unit assigned/working, right: unit capacity/inside), but I would be
> curious what others would think. Anyone has opinion on that?
Problem is, this system is also not really scalable. What if we need a
fifth bar?
A beautiful solution would be to add the capacity as a graphic element
that is different for each building BUT you would need to change the
graphic every time you modify the stats. That would be a mess. It
creates a dependency that is not really needed.
It also feels a little boxed to have all sides occupied. What do you
think?

>> I have just used random colors for the bars, but the idea is to keep
>> them closer together and having a width that is proportional to the
>> element's one. This way it scales smoothly, because in the end we
>> don't have many different "sizes". Just multiples of 32 if I remember
>> correctly.
>
> I am not sure I understand what you mean by "having a width that is
> proportional to the element's one". Somewhat several statistics, such
> as number of units assigned/working, are precise at one unit and it
> somewhat matters for the player to see that.
>
> But maybe there is a design that allows to have bars more together, if
> we think it is better, and still have this precision?
>
Problem is, as long as it is up to 4 your eyes can actually
differentiate the number, but, can you differentiate 2 pixel dots
between 7 and 8 on a straight line? I cannot really tell at a glance if
there are 7 or 8 dots on top of the buildings, but I can say there are 5
on the right, bottom is full (even if I cannot say how many are there)
and left is almost full.
Fact is sometimes you need precision (you are right on the capacity),
sometimes you need an overview.
If I see a set of buildings on the map, I need to see which one of them
has or not units assigned to, but I don't really care if it has 123 or
124 HP on 200. It is important to see that "hey, it has already lost
almost half of its hp, let's repair it!".
And you don't really want to select each building to read the single
stats.
Why not going for precise stats top and overview stats bot?

By proportional I mean:
  Unit occupied space: 1 square
  pixels per space: 32x32
  full health bar length: 24 pixels (4 pixels from left, 4 pixels from
bottom)

  Unit occupied space: 2 square
  pixels per space: 64x64
  full health bar length: 48 pixels (8 pixels from left, 8 pixels from
bottom)

  Unit occupied space: 3 square
  pixels per space: 96x96
  full health bar length: 72 pixels (12 pixels from left, 12 pixels from
bottom)

  Unit occupied space: 2 square
  pixels per space: 128x128
  full health bar length: 96 pixels (16 pixels from left, 16 pixels from
bottom)

It should scale pretty nicely. It is independent from gameplay, since
you can set the health (or any other arbitrary length value) of a unit
to 1200 without covering other units.

>> I was also thinking at some very nice animation that can be adapted to
>> every building to differentiate between working ones and idle ones.
>
> You mean whether the building is currently doing something, such as
> training unit? It seems cool indeed!
>
yes, that is what I was thinking. It doesn't have to be complex, but
just to understand if something is idle or not.

> cheers,
>
> Stéphane

_______________________________________________
glob2-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/glob2-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]