Here, everyone can list useful or interesting ideas about this project.
Strategic_GRAILS : An alternative approach at Strategic
- Better define the analysis of existing modules structure
- Discuss and refine the modules structure
- Discuss and find priorities
- Write down sample working code for each of the areas of interest (at the level of exercises and examples)
Obsolete stuff, to be revised ASAP. --Aragorn 83 18:04, 25 July 2006 (UTC)
Compressed game packages in .zip archive Ruleset are stored inside .zip compressed archives. Each archive will contain all files needed for the functioning of the specified ruleset.
Administrator interface via console The administration of the game server can be done using a character console. (crf.FreeCiv Server)
Functions for creating game packages The system should supply tools for creating and validating packages
Game packages as uncompressed directory There will be the option to use uncompressed game packages. This will provide facilitation to game developers, and better performance with game systems which uses large data. (ie.images, video, 3d models, music)
multiple simultaneous game sessions on the same server instance The same server instance will be able to run multiple game sessions in a multithreaded approach. Optionally the server will be able to run a game as a separate process, mainly for performance issues
multiple game packages on the same server instance The same server will be able to lead different game packages during the same session.
support for play-by-email The server will offer support for game system based on mail gaming, and the option to implement a PBM system for those which are not originally intended to be played by e-mail.
multiple players on the same client (hot-seat) There will be the option to swap turns on the same client, whatever the interface (ie.GUI, CLI, Web)
managing different map types (hex, squares, coordinates) The core will implement methods, classes, algorithms and data structures for the most used types of map.
generation of HTML reports The server will be able to generate reports about it's status: games running, game systems supported, players connected, and so on.
internal http server for web interface (play & admin) There will be a simple http server embedded in the game server, that will serve html pages for web based administration and gaming, and to publish statistics and reports
managing terrains (height, type, etc) Support description of terrain attributes, for example it's height, or if it's difficult, if it's not passable, if it's dangerous, etc, and also support for terrain entities, such rocks, rivers, etc.
admin console with DBMS style commands The administration console will use commands similar to those used in DBMS admin console. For example, "use warhammer40k3.0" will change the current game package to "warhammer40k3.0", "show packages" will list all game packages available, "show sessions" will list all active sessions, and so on for user management, session creations, etc
XML descriptor for game packages Game packages will use XML as main language for the description of rules and data. Optionally also for the description of vector graphics. The purpose is to maintain maximum portability, and to facilitate the creation of third party tools for the manipulation of packages.
Dice generator Of course, almost games uses dices as consistent part of game mechanics, so the core will provide a complete set of dice facilities. Optionally it will be a separate library, for reuse of code. Dice roll generation can be client-side for simple games, or server-side (ie.web service) for more serious (tournaments?) games.
internal mail server Depending on the implementation of the Play-by-mail feature, it will be needed an internal email server able to receive and send mails. It should support basic list management.
user profile management There will be a user authentication system.
manage game packages version & checksum For security reasons, and in order to avoid cheating, there will be a security system able to verify the integrity of client-side packages.
standard interface for third party tools and clients All main function of the server will be exposed in a way that will allow the implementation of third party tools and clients.
support for games with predefined units (chess, dama, monopoly) and for custom units (miniature games) There will be the support for "closed" games, like chess, which have a limited and fixed set of units, and for "open" games, such as "warhammer". In this case the players have the opportunity to build their own armies, and so there must be a mechanism to upload and distribute those armies sets, and to validate them against the rules defined bye the game package.
implementation of an event subsystem for units and entity Many game systems includes automatic reactions for units, and events which affects many units at the same times, whatever the player/owner. So there must be a system able to react to changes in units and environment changes, and react with predefined, or game system defined, actions.
support for remote control via telnet The console will be available to a telnet client.
XML based server configuration As well as the game packages, also the server configuration is based on XML files (ex.Tomcat)
support for game saves Support for save and restore of game sessions.
validation of armies (warhammer) On "open" games, those which allows players to create custom armies, there must be a validation system.
user folder with profile, saved games, custom armies, etc Each player will have it's own folder on the server, where will be stored profile description, save-games, custom armies, personal messages, and so on.
various reports of current games running on the server Players logged in, game types, history of past sessions, high scores, etc.
creation of game sessions by non-admin users Privileged users may create game sessions autonomously
rights-management for users Manage a user management system, to define what users can and cannot do. Some user may start sessions, or invite other players, etc etc
invite system The administrator, or a player with a specific permission, can invite other player to join a game session.
user message service A player, or the admin, can send messages to other players, which will be displayed or notified in various optional manners.
management of complex game flow (not simple "you-me-you" turns) Many games use a simple turn system, like chess or go!, where each player has exclusive control on his turn. There also more complex games, such as tabletop and miniature games, where some events can trigger a "reaction" from the other player.
option to automatically manage other players events in une player's turn (ex.automatic fire response) There must be the option to define at least two way to handle. Simple events, which require for example the launch of a dice by the other player, can be optionally executed automatically by the server, or by the client, without suspending current player turn. More complex events, which requires an action or a decision from the other player, should start a "sub-turn", which will go on between the players until the generating event is resolved.
local application combining server and client functions for single player games For single player games, there should be the option to run the entire game as a single application, with administration and gaming section integrated in an homogeneous interface.
definition of multiple visualization for units and entities for different clients(text, 2d low, 2d high, 3d) There should be a way to define multiple visualization for maps, units, etc. For example, there will be the option to assign to the same unit both a 2d sprite sequence and a 3d model. Different clients will then show it in a 3d environment, or as a 2d map, depending from the capabilities of the client. This will allow players to play the same identical session using different clients, different visualization, and different class of processor.
the console should be easy to reuse (ie.independent from current implementation) The console should not be project specific, so that it can be used in different project. There will be two tiers: the console interface and the command interpreter. The console will manage all user input relate issues, such as history, auto-completion, etc. The command interpreter will be the interface between the user input and the classes of the engine and the scripts of the packages. It will be the entry point for user interfaces, remote control, etc.
chat subsystem There will be a chat between players, for example using an embedded IRC server. Each session will have it's own channel, and there will be a common channel.
- Artificial Intelligence (AI)
The problem of:
- Building a warhammer army is an expensive and difficult operation.
- Playing tabletop and miniature games needs player to be in the same place, at the same time.
- Playing different armies and game systems is VERY expensive.
- Play-testing armies can be a long and tedious task.
- Developing new games system or modifying existing ones it's difficult.
- Miniature and tabletop games Players, computer games Players, miniature and tabletop games developers, trademarks owners
The result of which:
- Players cannot optimize spending, and sometimes buys useless models, or create a non effective army, wasting money
- Players which are far from gaming community cannot play their favourite games, or can play them only with few peoples
- Players often cannot buy more than a single army, and sometimes neither that.
- Testing and improve an army is a long, difficult and expensive task, and requires the player to play against many different armies
- New game systems requires a lot of play-testing, and doing this "manually" can be tedious
- Players can create "virtual" armies, and play-test them against other players, or against the computer
- Players can play their favourite games over the network, against distant people.
- Game systems designers can create and play-test new rulesets, without expenses.