Thread: baseball game

Hello,

I'm in the design phase of creating a computer version of my favorite baseball board game. Before I plunge in and find out I've done something wrong half way through, I thought I'd post my ideas here, and see what you guys think.

The game, (maybe someone here is familiar with it), is called Pursue the Pennant. Three ten sided dice are rolled, a number from 000-999 is generated, and the play result is then read from a player's card. I'd really like to create a computer version to make stat keeping and overall game flow easier. So, each player has a card that reflects their real performance. I'm thinking a simple comma delimited text file holding all players and all their ratings/play results would suffice. Also, it would hold a "team id" for each player, and when their team is selected to play a game, they would be loaded from the file. I also believe having all players pooled together (rather than each team having a separate file) would make things like drafting easier.

This gives a general idea of my thought process. Storing players, teams, league, and park information in big comma delimited files. Is this a good approach? (something like below):

players_2008.dat -> holds all players and their "cards" from 2008
teams_2008.dat -> holds each team's name, park, and id
parks_2008.dat -> each park will have a name, and id

Another problem is statistics. I'd like to be able to accumulate them over a period of games. Should another file be created to just hold them, and reference the id's held in the initial files? Would this be too slow when sorting statistics?

The game also uses some charts, where certain results are read from if the player card result calls for it. Should these be hard coded or stored in the same way as the others? Is there an easier way to create something like this?

Thanks so much for reading, and I hope to hear your thoughts.

Generally you appear to be on the right track.

I'm not a fan of comma delimited data storage, but there's nothing invalid about it. For flat file storage, I tend toward XML, because there are libraries for I/O, it's standardized, can be used for web enabled transfer, etc.

On the other hand, I'd even consider embedded SQL or a more generic server oriented SQL, because there are libraries to abstract the data storage, and it can be expanded into an online implementation and it handles your design points well.

The underlying theme, here, is that I'm recommending you think in terms of abstraction, so your application code isn't tied to a specific data storage method, such that you can switch to alternate forms at will without changing the application code.

This has some implications to your question about statistics. It is a valid notion to store a separate flat file of statistics which are indexed by a player's id, and sorting in modern hardware is fast enough that millions can be sorted in a second.

However, one reason SQL comes to mind is the fact that you have defined a relational database with this 'word problem' - the concept of a collection of records (or rows in SQL parlance) is 'owned' by a record from another database. SQL does that as a basic means of it's function.

So, to, does XML. It's generally known as hierarchical data storage, and that is the underlying data structure for tree controls.

I can't recommend hard coded data, with rare exceptions. I do, for example, find it useful to create global constants for values like PI, Radian/degree conversion ratio and similar important values, but very little else.

Thanks so much.

I'm looking into the SQL approach right now.

I forgot to mention - I'm using Visual Basic as my development language. Do you know of any good controls/libraries for dealing with SQL in VB?

Thanks again.

You may be interested in SQLite if you want to use SQL but don't want to have to set up a full-blown database. Not sure if it has VB binding, though.