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 _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
