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

[Bradley Arsenault]

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.

> > 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.


>
> > 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.


>
> > 6) In the endgame statistics, you should know what graph your
> > examining. If I click "Total Attack", at the top of the graph, it
> > should be labbelled "Total Attack", and if I click "All Buildings", it
> > should say so. I Should also be able to disable the showing of various
> > graphs by clicking a checkmark placed beside the names of the players
> > and their colors. The menu should contain a link to a help menu that
> > describes each of the graphs with little detail (to be short for slow
> > readers). This menu can be as simple as a popup with a scroll bar, on
> > the left will give indexes for each of the graph information, (So it
> > lists "Total Attack" and "Total Buildings", and "Conversions Per
> > Minute" etc..), and on the right side, it should contain the
> > information. Clicking on one of the menu objects on the left hand side
> > should automatically scroll the right hand text window to the
> > appropriette location. The last item should not be scrolled at the
> > bottom, infact, extra empty lines may have to be placed in the text to
> > garuntee that when you click on an item on the left hand side, it
> > always scrolls to the *top* of the right hand text menu.
>
> Mostly agreed. Data from about the last hour of play are saved in a circular
> buffer to ease the code. Given the time we have, I think it is good for now.
> Otherwise ok.

Again, in the grand scheme of things, it would be better to compress
the statistics, as it looks more natural for longer games, a new
person may feel bad that they can't see the statistics for the first
part of the game, a continuous line looks better, and is easier to
read and understand.



>
> > 7) The campaign system sucks bad. It should not be map based, and you
> > definitly should not get the feeling that what you are seeing when you
> > select a map is simply the contents of a folder. Instead, you should
> > select a "campaign". You are told that you can either load a campaign
> > or start a new campaign. Should you start a new one, you will be given
> > a list of playable maps, but only the ones that you have "unlocked".
> > When you select a map on this screen, its description should come up
> > on the right hand side. When you beat a game in a campaign, your
> > progress should be automatically saved in the campaign. If you save a
> > game in a campaign, it should save the campaign its accocciatted with.
> > When you load a saved campaign game, it should automatically load the
> > campaign as well. When inside the campaign selection menu, you should
> > get a list of saved games from that campaign, bassically, this is the
> > global saved game lists filtered for ones that are for the campaign
> > the user has loaded. The user should be congradulated for beating the
> > campaign. When this system is done, the tutorial should be integrated
> > into a campaign. Campaign games should have "hints" that can be
> > retrieved from the menu. You should not be able to change alliances in
> > campaign games.
>
> Well, let's wait for a real campaign...

Not so. A real campaign is easier to make with a real campaign
*system*. If one sees that the game possesses the ability for good
campaigns, they would probably be better inspired to make one, or
else, they may be waiting for you to "make a real campaign system".

>
> As you can see, I mostly agree with you. But the thing we lack most is work
> force. Redoing the GUI of the map edit is the next thing on my todo-list. I
> will also update widgets so they can be linked to any Text widget to display
> help on mouse over, which should ease the creation of help text.
>
> Have a nice day,
>
> Steph


Overrall, you have to entirely ignore how much of a work force we
have, which seems to be what your not doing, because when you do that,
you don't get out what you want to do correctly. We want to do all of
the above. Who cares how much work force we have. We should want all
of the above. Releasing a half ass job because we have this
set-in-nothing deadline of 2006 won't do us any good. We should
release when we think the games ready, when its of a very high
quality, not when we think the time is right.