   baseball board game - pc 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 2008teams_2008.dat -> holds each team's name, park, and idparks_2008.dat -> each park will have a name, and idAnother 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. :)   
  bump?   ;  Sounds like a good enough starting point. Don't worry about what's fast enough or what's too slow when it comes to sorting statistics until after you've got the program written. File that under premature optimization. As for charts, unless the values stored on the charts can be generated algorithmically, such as with a sine and cosine table, you'll likely have to store the charts in a file similar to your player file.   ;  You need a database.Don't worry, a database is not terribly complex. There are local database applications like Access, but you'll want something that's programmable from a language/environment that can also display pretty graphics. My recommendation is SQLite because it's easy to setup and your entire database is stored in a single file. You're going to have to learn a new skill, SQL. It's not terribly difficult, but it is a little bit arcane. It'll serve you well in the long run, though.Now, having selected a database technology, let's see about structuring your actual data. You need to consider your data model to maximize efficiency. You also have to consider data relations. Database systems like SQLite are relational database systems, meaning that they group data according to common attributes. Your players, for example, all have a number of physical attributes such as height, weight, etc. They also have a slew of performance statistics over their current season and their entire careers, with optional breakdowns over durations with specific teams or arbitrary intervals (for purposes of comparison with other players). Not all statistics apply to all players - ERA only applies to pitchers; pitchers in the AL, who don't hit, don't have an OBP; etc. - so you'll need to take that into consideration. Players are attached to teams, but they change teams from time to time (trades, free agency, getting cut) and at times have no teams. Teams, on the other hand, have a roster that they generally keep full.You're going to need to define a database table for each category of similar data, like players. The table consists of rows of entries or records - in the case of the Players table, each entry/record would be a baseball player - and columns that define the attributes that each player can have. Whether a player actually has that attribute, and to what extent is defined by the value in that player's row at that column. Obviously, not all attributes are of the same type; a player's name is a string, whereas the number of career stolen bases is an integer and the hitting average is a percentage to three significant places. Also note that some things can be computed rather than stored: on base percentage is the number of hits for every 100 at-bats (or number_of_hits / number_of_at_bats * 100). Whether you decide to compute or store such values is a design decision you will need to make.In relational databases, you usually assign each record a unique integer identifier (the identity column). You can then refer to this identifier in a different table in order to associate a specific record with another. This is called a foreign key relationship. So, for example, you can define your Teams table with a fixed number of bullpen slots, batting order slots, fielding slots and substitute slots, and then place the identifiers from the Players table into those slots (and optionally leave slots empty, too). If you use a foreign key relationship, your database system will check that the identifier actually points to a record that exists, helping you maintain data integrity.You can define a theoretically unlimited number of tables in your database, so you can add complexity to your game incrementally. Start out with Players and Teams and get the core of your game simulation running, then begin to add data for Parks and their specific characteristics, Rivalries so that certain teams give a little something extra when facing each other, and even Fanbases to account for the heckling and cheering of certain club supporters (which is separated from Parks because some fans will travel with their team more than others).That's a very, very cursory introduction to databases that was designed not to overwhelm you. I hope you look into the technology and see all the opportunities it affords you to create something truly spectacular.Cheers!   ;  Thanks so much for the helpful replies!I am looking into sqlite right now, and it looks perfect for what I'm trying to do. Originally, I was going to use Visual Basic for the game (I wanted to be able to focus least on the design, in case I needed to go back and change something later), and generally VB is more forgiving in this area. I also wanted to display some simple static graphics during gameplay (just a stadium image or something), and this can easily be achieved in VB, also. However, after taking a look at sqlite, it looks like I'll be using c++. :)Expect a report soon. :);Quote:Original post by sbrundage81Thanks so much for the helpful replies!Glad to help.Quote:I am looking into sqlite right now, and it looks perfect for what I'm trying to do. Originally, I was going to use Visual Basic for the game (I wanted to be able to focus least on the design, in case I needed to go back and change something later), and generally VB is more forgiving in this area. I also wanted to display some simple static graphics during gameplay (just a stadium image or something), and this can easily be achieved in VB, also. However, after taking a look at sqlite, it looks like I'll be using c++. :)Keep in mind that SQLite is usable from a lot of languages, and many of them make it easier to display graphics and play sounds than C++. For example, you can use Python with the popular PyGame library to handle your multimedia, and still interact with SQLite via the pysqlite library that is in the Python Standard Library.Just mentioning this so you don't feel like your only choice for SQLite is C or C++.Quote:Expect a report soon. :)Will be looking forward to it. [smile]   