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

[Stéphane Magnenat]

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.

> 2) Jackit audio support.          """ JACK is a low-latency audio
> server, written for POSIX conformant operating systems such as
> GNU/Linux and Apple's OS X. It can connect a number of different
> applications to an audio device, as well as allowing them to share
> audio between themselves. Its clients can run in their own processes
> (ie. as normal applications), or can they can run within the JACK
> server (ie. as a "plugin"). """          Support for Jackit should be
> optional, as a compile flag. Configure should automatically enable
> jackit supprt if jackit is installed on the system, and it should
> disable support if jackit is not. Use of Jackit should not entirely
> replace SDL sound support, only if the jackd server is running (at
> runtime) should Jackit be used. Otherwise, SDL sound should be used.
> This means either system could be used, it is runtime determinable.

I do not agree. This is the problem of the audio backend. We use SDL for audio 
backend. If you want jack, fix SDL audio to get jack.

> 3) Units should not enter clearing or defense zones if there is also
> forbidden zone on that area. Currently, Appleboy notes that units will
> ignore forbidden zoning if there is overlayed clearing zone. Instead,
> the forbidden zone should take priority.

This is a bug. Agreed, please fill a bug report so we keep it in mind, thanks.

> 4) Appleboy desires the functionality to filter maps, allowing you to
> see maps of only a specific size. This is a difficult to implement
> problem, as the gui structure will have to be reanrranged for the
> filter settings to be do-able. If one filter setting is achieved,
> perhaps more could be implemented. Special live search filtering
> should be done (if the above is done). As you type in your entry, the
> list of maps is automatically filtered, rather than filtering at the
> end of typing (when you click enter). This does result in allot of
> filters, but it makes it easier to tell if the map your typing
> actually exists, and if you misspelled something.

That would be nice. It should be doable as map are already parsed to extract 
names.

> 5) If the user tries to quit a game, he/she should be presented with
> "Would you like to save?" message. When saving, the save filename
> should automatically default to any previous filename save.

This is extracted from unimplemented usability issues. It is unimplemented 
because of lack of work force. Agreed if someone do it.

> Saves-default filenames should be done by a formatted date string as
> well, something like "Big Pond - Wed / March 22" would do very well.
> Although its long, length doesn't really matter, as long as its quick
> and easy to read, where as something like "Big Pond 22/03/06" makes
> you think more about what your reading, and indeed, it may confuse
> some of those dummer people. 

Agreed.

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

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

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

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

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