[Rails-devel] RE: Project goals

[Christian B. <chr...@co...>]

Hi Brett, hi all others,

may I introduce myself:

- first of all: I'm not an english native speaker, but will try my best -

I started my private 18xx-project 7-8 years ago and  - as I said in the Yahoo-18xx-Group
a few months ago - I will need another 7 years of coding until the first version will be
released... 
Main reason for this is lack of time ...

Due to my experience and preferences I'm using Delphi 5 (Turbo Pascal in the very 
beginnig) to code the UI. I'm using the open-source database Interbase V6 to store
the data. Many ideas I had were born during the whole development phase and not in
the beginning.

I don't want to discuss about the programming language and I think java will be ok
(even if I have no experiences in it), because it allows OS-independent development.

But maybe I can help with my thougths about the needed (data) structures:

---

I agree to all "Project goals" section published by Brett, no doubts !


In my project I thought about 3 different UIs: 

1. game-UI for the _player_:
   import rulesets, creat games and play games
2. develober-UI for the _18xx-developer_ who hasn't any programming experiences
   create rulesets, export rulesets
3. kernel-UI
   define basic game-mechanisms to the 18xx-system

Advantage of this is the possibility for people that aren't in the project to develop
18xx-games to the system.

> 1. Create generic object framework for 18xx game mechanics.
> [...]
> 3. Determine what format the rulesets will be stored in, and code support for this.

To realize the different UIs, I created different "databases" (let me use this expression - in
my project they _are_ databases, but it doesn't matter how the data will be realized in
the Rails-project).

1. The kernel-database (KDB).
-----------------------------
The kernel-database contains all _basic_ stuff needed for a 18xx-game:
a. all used objects
   "player", "company", "train", "tile" 
b. properties of all used objects
   "cash", "value", "shares", etc
c. changing of objectproperties
   "increase cash", "decrease cash", "increase value", etc
d. definition of all possible game-actions (object-relationships) by combinig changes of object-properties:
   "player/buys/share" 
   = "player-cash decrease"/"player shares increase"/"company cash increase"/"company shares decrease"
   "company/pays out/dividend/full"
   = "company cash decrease"/"player cash increase"
e. generic tile-definitions (routes, stations, costs, track type, etc.)

Part a.-d seems to me as the most difficult part, because it needs analyzation of the whole
game mechanism into "atomic" parts. But on the other side it best reflects the object-
programming model!

The KDB should be created/altered with the kernel-UI

2. The 18XX-database (18DB)
---------------------------
It depends on the KDB and holds the "ruleset" for each single 18xx-title. Data in the
18DB is constructed by 18xx-developers via the developer-UI. Only that rules can be 
defined, that can be build out of the basic game-mechanisms defined in the KDB. 

Every set of 18xx-data could be seperated by the developer as a file and provided to
gameplayers. The gameplayers themselve can import the seperated file into their own 18DB.

3. The game-database (GDB)
--------------------------
Each player can create a "game-file" fromout their 18DB (just defining number of players)
with the game-ui. Providing this file to all players they can import it into their GDB and
play the game. GDB depends on 18DB - each player needs to have the ruleset imported! - and
on KDB.

Conclusion
----------
So things to do concernig data-definig are

1. define the atomic game mechanism of one 18xx-title (i started with 1835) into KDB "Version 1",
   this should be done by the project
2. define the ruleset "18xx" the 18DB and create game-files out of it
   this _could_ be done by a "normal" 18xx-developer
3. import the game-file into GDB and enjoy ...
   this _could_ be done by every player...

If a basic set of game-mechanism is created maybe the rulesets of some 18xx-title could be created.

If there is a title that needs further game-mechanisms, the KDB could easily be expanded with 
new objects / object-relationships (to Version 2). To handle new object-relationships the UIs
too has to be altered (to Version 2).

So far, these are my initial thought to the project. Maybe my realization seem to be too abstract
and that may be another reason for my long development time until a first game can be played.

But maybe it helps to construct a 18xx-system that, once released, can easily be expanded to new 
titles without coding "the whole thing again".

Regards,

Christian Bach