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

[Othniel Graichen]

We don't want to confuse distributions which include glob2 and end up dropping this game just Because it is too hard to build for their distro.

On Mon, Dec 30, 2019, 2:00 PM <address@hidden> wrote:

On 2019-12-30 17:53, Stéphane Magnenat wrote:
> Hi,
>
> I see your point in term of readability Dryad and I agree with it.
>
> What about a mixed solution:
> - HP and food: a bar each at the bottom with a width proportional to
> the building width that shows the percentage of remaining, as you
> proposed. Maybe the bar should have a maximum width so than it remains
> not too large for huge buildings but that's a detail.
> - Units working and units using: for each a small icon along with two
> numbers (current / requested or max), like Starcraft 2 is doing for
> the workers assigned to the mineral or gas collection.
>
> This approach splits the two types of information, the overall one
> focusing on ratios on the one hand, and the precise numbers on the
> other and. Also, it is extensible to additional counters.
>
> What do you think?
>
> cheers,
>
> Stephane
>
Ye that's perfect I think.
By the way, I don't remember if the game already has it, but what about
a key to show/hide buildings overlays?
This way you can either enjoy the full graphic and having everything
under control.

Oh, a last idea: What about moving the control panel from right to
bottom?
I know that's a big interface change but I guess it would look better
and also improve playability.
(Maybe it can be made later... I mean, let's start with the important
in-game graphics :))

> On 29 December 2019 16:39:26 CET, 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
>
> --
> http://stephane.magnenat.net
> _______________________________________________
> glob2-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/glob2-devel

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