[STRATEGIC] Brainstorming

Some ideas:

• Compressed game packages in .tar.gz archive
• Administrator interface via console
• Functions for creating game packages
• Game packages as uncompressed directory
• multiple simultaneus game sessions on the same server instance
• multiple game packages on the same server instance
• support for play-by-email
• multiple players on the same client (hotseat)
• managing different map types (hex, squares, coordinates)
• generation of HTML reports
• internal http server for web interface (play & admin)
• managing terrains (height, type, etc)
• admin console with DBMS style commands
• XML descriptor for game packages
• Dice generator
• internal mail server
• user profile management
• manage game packages version & checksum
• standard interface for third party tools and clients
• support for games with predefined units (chess, dama, monopoli) and for custom units (miniature games)
• implementation of an event subsystem for units and entity
• support for remote control via telnet
• XML based server configuration
• support for game saves
• validation of armies (warhammer)
• user folder with profile, saved games, custom armies, etc
• various reports of current games running on the server
• creation of matches by non-admin users
• rights-management for users
• invite system
• user message servicemanagement of complex game flow (not simple "you-me-you" turns)
• option to automatically manage other players events in une player's turn (ex.automatic fire response)
• local application combining server and client functions for single player games
• definition of multiple visualization for units and entities for different clients(text, 2d low, 2d high, 3d)
• the console should be easy to reuse (ie.independent from current implementation)

[STRATEGIC] Problem Statement

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.
• Playtesting armies can be a long and tedious task.
• Developing new games system or modifying existing ones it's difficult.

Affects:

• Miniature and tabletop games Players
• Computer games Players
• Miniature and tabletop games developers
• Trademarks owners

The result of which:

• Players cannot optimize spendings, and sometimes buys useless models, or create a non effective army, wasting
• money
• Players wich 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 playtesting, and doing this "manually" can be tedious

Benefits of:

• Players can create "virtual" armies, and playtest 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 playtest new rulesets, without expenses.

About XUL: defining SWING interfaces using XUL

I've found this Java library, which enable a Java application to build a SWING interface reading it's definition from a XUL file. It could be a useful alternative for the implementation of GUIs.

XUL for the user interface.

When the time will come, XUL will probably be my choice for defining the user interface.
XUL is a markup language specific for the description of user interface, even complex one. It's basically a mozilla tecnology, based on the gecko engine, but there are some projects wich allows XUL to be used to define language specific GUIs. For example, there are some project wich enable Java and Python programs to use XUL files to create GUI.
I'll give a try, one day.

Let's start...

Ok, here we are.
For some reasons, I've created this blog to write out ideas. Sourceforge homepage is not suitable for many reasons, first of all I cannot access it from the office, cos some firewall issue (ssh not allowed).
So, fast changing ideas and informations will be posted here, and the sourceforge homepage will be more slowchanging.

About the project.

After an initial haste to do things, and write code, I've stopped for a moment, reflecting about how a project should be managed. I'm falling back to initial positions, from the basics of project management, following the right process.

So, first of all, there is the requirements analisys.

The order of things should be:

• Specifications gathering
  
• Requirements analisys
• Writing use cases
• Software design
• implementation

By now, I'm focused on specifications gathering and requirements analisys. I'm reading some books on the topic.