Re: [glob2-devel] Thats it, we need a plan

[Martin Voelkle]

On 3/28/06, Bradley Arsenault <address@hidden> wrote:
> On 3/25/06, Stéphane Magnenat <address@hidden> wrote:
> > Hi,
> >
> > > 1) The ability to set teams in custom games. Teams can be set via a
> > > team number. Every tesam has a team number. By default, human players
> > > have a team number of 1 and AI players have at eam number of 2. Team
> > > number selector can go right beside the colour selector in the custom
> > > game menu and in the yog game setup menu. People on the same team are
> > > allianced in all manners, except Inn View. People on different teams
> > > have the standard 0 alliance settings.
> >
> > This violates the concept of team vs player as it is in glob2. A Team is a
> > color, a player is a controller. Teams (color) can be set in custom game.
>
> To be honest with you, having multiple teams as the same colour is a
> bad idea. You don't start with any more workers or swarms, and you
> don't have full control over your base. Its not really a team effort
> at all. Its also more confusing to someone who is new, as most other
> games seperate teaming from colours, where as this game does not. Its
> also funner to have full control over your base, because you directly
> affect what happens. Working in a team, when soemthing goes wrong, you
> have someone to blame, and will feel worse, perhaps even angry.
>
> You can be abstract and different all you want, but when it comes down
> to it, there are simply some things you have to do to make your game
> easier to play by the general public.

I guess you where referring to setting up alliances before the game,
probably allowing to lock them. This is quite different from melee
teams that nct suggests. Obviously, concept naming clashes is no
argument to invalidate the idea.

> > > Auto saves should be done by map name
> > > *and* date, so "Big Pond - Wed / March 22 - Autosave", rather than
> > > using one generic name of Autosave. Again, length isn't important,
> > > because one can read it all very quickly, without having to "think"
> > > about what their reading, which slows them down.
> >
> > Bad idea. Using a single name prevent disk being filled by autosave. If
> > someone has any suggestion to solve both issues, discussion welcome.
>
> Well, it has to be sorted somehow. The abstract save game is rarely
> used, and there is no way to know what map its on, what date, or
> anything. Its just "Autosave", it quickly gets old. You can keep one
> autosave only, but atleast suffix its name with the map name so you
> know when you played that game.

Here is a working scheme:
Use the original saved game name with ' - autosave' appended
(obviously, only if the game name doesn't have it already).
For new games, use the map name with the date as the default name. If
that game already exists, add the time.

> >
> > > When quitting, one
> > > should not be presented with the "You Lost" screen, as the person has
> > > quit, and it only makes them feel unhappy. They want to get to the
> > > main menu, they don't want to be told that they suck. It should only
> > > tell them they lost when they actually lost. So, another question
> > > should be presented, (this one should have a checkmark saying "Don't
> > > ask me again", because it will get annoying after a while, and that
> > > option should also be changeable in the options menu), and this one
> > > should say "Would you like to see the games statistics?". If the user
> > > says yes, then the game should go into the end game statistics, and
> > > then it can tell them they lost.
> >
> > This is extracted from unimplemented usability issues. It is unimplemented
> > because of lack of work force. Agreed if someone do it.
> >
> > I think the stats should be mandatory. Keeping GUI simple is important,
> > excessive number of datapath may disturb the player and make the code less
> > readable.
>
> Mandatory is a bad idea. The user hit quit. They expect the main menu
> to come up. They don't want to see the statistics. They want to quit.
> They don't want to be shown how bad their ass was whooped, and if they
> do, they probably know that they do, and could suffer clicking an
> alternate menu button like "Show Statistics" before they quit.

An I think the stats should be prohibited unless the game has been
finished (as in won or lost). They give you important data you
shouldn't know. Either resign (and look at the stats) or quit
(optionally save, but no look at the stats).

Martin