Wallstreet Simulation 32 Bit

Wallstreet Simulation will be a Linux-Economy-Simulation game (first stock companies will be available) -- It'll be as realistic as possible.

Currently it is developed with Kylix OE. Currently code works with Delphi PE, but the Delphi PE license isn't GPL. I don't know, if it fits Delphi PE license, if code is maintenanced for Delphi PE also, it maybe could be instutional or indirect profit?

Readme-File for Wallstreet-Simulation Developers

by Stephan Struckmann

Wallstreet Simulation will be a simulation game. Project master is Stephan Struckmann (my humple self) so far. I had written a similar game in the 1990ies with Delphi 1.0. Also this old one was modular (better became modular), which means that Plugins and additional game-modes could be installed. The word "became" is the characteristic term for the spaghetti-code of that old project - I started it to learn programming Windows under TurboPascal 1.0 for Windows, because I had no development tool for my favorite operating system OS/2. I tried to make a shareware-version around my matriculation. Then at the university I didn't find enough time for the far necessary re-engineering (porting to at least 32-Bit-Windows maybe to Linux and OS/2, interation of net-abilities, recode the application kernel, etc.)

Now I've nearly finished my first studies - probably I'll do another more mathematical. And Borland came up with Kylix OE. So I decided to iniate a new open source project - maybe some enthuasiastic programmer will join me.

Ok -- The specification of the game so far:

Look at bplFormmanager.so / Formmanager.bpl for the Framework's kernel (it is inspired by an article in the great programers magazine "toolbox": http://www.toolbox-mag.de/). bplStruckFrame.so / StruckFrame.bpl contains framework and Plugins should put an entry in the main menu or whereever the want to hook.

I would be happy, if someone joins, who knows more about the forecast-methods for economical facts. Someone with skills in designing the shell of the game would be great. Also porting the whole thing to other OS and writing interfaces for other programing-languages should be thought about. Translation to other languages (I speak natively German as You can see; my spelling is terrific and my style ...) could help.

There are many similar games but less OpenSource. And I try to make it realistic. A friend of mine doesn't use Linux because he likes simluation games like Alpha Centauri or Civ. I think there should be more games for Linux (and not only more action games).

Kylix could help; it is GPL - so I think it is ok to use it. Unfortunately the IDE is really instable. The Free Pascal Lazarus project will bring another RAD-IDE for Linux, OS/2, AmigaOS, many others and even Win. A little WYSIWYG can improve CASE as we could see with Delphi. Of course it seduces people to write dirty programs but that is no reason not to use it for writing proper programs. And: As I mentioned in introduction: spaghetti code is also possible with Turbo Pascal for Windows 1.0!

So if You like the idea of the game and don't hate pascal programmers or Borland (in case You do: Feel free to port it to GNU!):

Everybody is welcome!

Stephan Struckmann
ICQ: 129576343


(so far)

TComponent      ---        TPerson        ---        TGesellschaft        --- TAG
                                                                          --- TBank
                                          ---        TEinzelperson        --- TSpieler
                                          ---        TStaat
                ---        TWertstueck

Translation of the (German) classnames: (SORRY!!)

TPerson obvious
TGesellschaft TCompany
TAG TStockCompany
TBank obvious
TEinzelperson TSingle_person
TSpieler TPlayer
TSaat TSate / TCountry

If objects need to relate to other classes, they should define a ClassType:

        TPersonClass        =        class of TPerson;

Later they may create instances like following:

var        aClass : TPersonClass;

proceudre PersonFactory;
var        aPerson: TPerson;

        aPerson := aClass.Create
        { ... }

Which brings the advantage that the Class for TPerson can inherit to TGreatPerson and the code aPerson := aClass.Create mustn't be changed:

unit GreatPersonUnit;


uses Person;

type         TGreatPerson = class(TPerson)
                // some changes against parentclass


// ...

        aClass := TGreatPerson;

Now it's enough only to "use" GreatPersonUnit and the rest of the Codeunit will work with TGreatPerson instead of TPerson.

About the Framework:

All Plugins / Modules must be coded as (borland) packages BPL (DLL's or SO's with certain interface routines, that are automatically inserted by the Compiler) so far. These provide easier data interchange between modules (even Classes can be defined in modules - used extensively by Compiletime-Packages: All Components come in packages but can also be compiled as the here used runtime packages).

These must dynamically use the runtime package FormManager.bpl and register in Initialization part with RegForm. They also must deregister with DeRegForm on removal. Take a look at PluginTemplate for more information that can be used as a template for plugins in the Delphi object repository. They must contain a Form derived from TMyForm (FormManagerUnit), which should be hidden all the time. Probably TMyForm will be in future a child of TComponent or so instead of TForm. Please code, if You like!

That's it so far. Thank You for Your interest,

Stephan Struckmann

Finally the current TODO:


targets, that must be implemented soon

Reorganize the Sources: Parts that don't depend on CLX/VCL shouldn't be
stored twice (in Kylix AND Delphi tree).  This I consider important, because
else WllClasses-develpment may split; at the moment they exist twice but
are nearly the same for Kylix and Delphi.

Error on leaving program (exception in CLX -- well, probably my fault ;-)
	---- fixed
Build something like the COFF-component for ELF to
  recognize loadable packages. (Maybe they should be CRC'ed first, at least
  under Windows - under Linux it should be more complicated to replace them,
  but - of course - not impossible)
Package manager has to be completed in Linux
Versionnumbers in Linux files

What about DragAndDock under Linux/CLX?
	Obviously missing, think about implementing this...

When it works under Linux, it should be re-ported to Windows
using great FreeCLX for better code consistency.

"Real" programing
Complete chart component (currently X/Y/Z-function plot - works under
Linux and Win)

Complete COFF component (many ideas; first: does it work with all
DLL's / EXE's?)

Storing interface, persistant VarListe (File / maybe Registry?)
Net interface for these globals

a lot of testing, especially the cleanup

Replace TMyForm by TMyPackage or so

writing a tool, that generates raw package-sources - an assistant
for developers
Interface in C++ to enable developers writing packages in that
language (currently only Kylix is supported)


targets, that may be implemented in future


Projektseite bei SourceForge.Net SourceForge Logo Meine Homepage