sheishmaster
asked on
How to build a football management simulation game in J#
Hi, I am a University graduate in Software Development and I have decided I want to try something less boring than information systems. I am a big fan of football management games and have always been interested to know how to develop a game like this. I am also a big fan of software development and I like to make mini-projects in my spare time therefore I have decided the best way to understand the internal workings of a game like this would be to attempt to develop one.
I have recently begun learning Microsoft.NET and in order to kill 2 birds with one stone I was considering developing the game using J#. My main reasons for this was it will help me learn the J# language in more depth and at the same time help me build a game which is platform independant.
I know just be reviewing games similar to this that there must be a fair amount of classes to be coded, which in turn will require a similar amount of controllers. However, I would like help on what is the best possible plan of action to underake a project like this. I want to keep graphics, I.M. to a minimum at the moment. However, I do want to have forms as I do not want to program using the console as it is then easier to add graphics etc.
I also realise that there will be a fair amount of information that must be stored therefore I was wondering if there was a database which I could integrate with the J# language?
Can anyone help?
Thanks.
I have recently begun learning Microsoft.NET and in order to kill 2 birds with one stone I was considering developing the game using J#. My main reasons for this was it will help me learn the J# language in more depth and at the same time help me build a game which is platform independant.
I know just be reviewing games similar to this that there must be a fair amount of classes to be coded, which in turn will require a similar amount of controllers. However, I would like help on what is the best possible plan of action to underake a project like this. I want to keep graphics, I.M. to a minimum at the moment. However, I do want to have forms as I do not want to program using the console as it is then easier to add graphics etc.
I also realise that there will be a fair amount of information that must be stored therefore I was wondering if there was a database which I could integrate with the J# language?
Can anyone help?
Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The answer to the "is this good enough" question, generally, is answered by "which database did you settle on using"?
Also, which IDE are you using? Is it the Express edition of J#?
If you go with mySQL, there are some freeware tools to help with the design/layout of the database; if you go with a different database, then you'll need some other tools.
The reason I suggested starting with the integration with the database, is that most of your problems with a game are interactions with external storage/external devices.
The hard parts that are in your code are really not all that hard to work thru; you can use your debugger and some elbow grease and generally make progress or find work arounds; the inteface to the database is pretty much 'all or nothing'... it will either work or it will not. Also, the bulk of your work, initially, will be getting data about the players/teams into the database for the simulation to run against... and you'll need data entry forms to make that easier.
You can put that part off until later, but it's been my experience that once I do that, the mechanism for loading/unloading/persisti
Yes, I have experience writing game engines; I worked for Sierra On-Line for 7 years.
I personally wouldn't start with someone else's code; you stated your goal was primarily learning... it's best to learn via trial and error, using a design of your own... uh... design.
-john
Also, which IDE are you using? Is it the Express edition of J#?
If you go with mySQL, there are some freeware tools to help with the design/layout of the database; if you go with a different database, then you'll need some other tools.
The reason I suggested starting with the integration with the database, is that most of your problems with a game are interactions with external storage/external devices.
The hard parts that are in your code are really not all that hard to work thru; you can use your debugger and some elbow grease and generally make progress or find work arounds; the inteface to the database is pretty much 'all or nothing'... it will either work or it will not. Also, the bulk of your work, initially, will be getting data about the players/teams into the database for the simulation to run against... and you'll need data entry forms to make that easier.
You can put that part off until later, but it's been my experience that once I do that, the mechanism for loading/unloading/persisti
Yes, I have experience writing game engines; I worked for Sierra On-Line for 7 years.
I personally wouldn't start with someone else's code; you stated your goal was primarily learning... it's best to learn via trial and error, using a design of your own... uh... design.
-john
ASKER
Hi John, I been busy at work this week therefore I havent had a chance to decide on which DB I will go with.
However, I dont think you understood what I meant with my question "is this good enough". What I was refering to was, I was trying to ask if loading is driver enough to manipulate the DB. By this I mean, is all the creating/editing in the DB done during runtime. Or is there external applications that allow you to edit the DB outwith my J# solution?
As I mentioned before I used Borland C++ and there was an external package shipped with this called Paradox, and this was linked in with the Borland IDE which made DB creation very simple and easy. So, for example, say I was to chose an SQL or ORACLE DB....is there packages available that will integrate this into Visual Studio 2003 and make it easy to build pre-built forms with links to the DB?
One more question if its not too much to ask, how do you suggest I go about programming the actual engine? Could you give me some advice on what fundamental classes/objects should be in place to have a basic management simulation engine to work?
Thanks,
James.
However, I dont think you understood what I meant with my question "is this good enough". What I was refering to was, I was trying to ask if loading is driver enough to manipulate the DB. By this I mean, is all the creating/editing in the DB done during runtime. Or is there external applications that allow you to edit the DB outwith my J# solution?
As I mentioned before I used Borland C++ and there was an external package shipped with this called Paradox, and this was linked in with the Borland IDE which made DB creation very simple and easy. So, for example, say I was to chose an SQL or ORACLE DB....is there packages available that will integrate this into Visual Studio 2003 and make it easy to build pre-built forms with links to the DB?
One more question if its not too much to ask, how do you suggest I go about programming the actual engine? Could you give me some advice on what fundamental classes/objects should be in place to have a basic management simulation engine to work?
Thanks,
James.
Which version of Visual Studio are you using?
Free? Enterprise? 2008? 2005?
These all matter....
-j
Free? Enterprise? 2008? 2005?
These all matter....
-j
ASKER
Hi I mentioned before in one of the comments the version I have is Visual Studio.NET 2003, I checked the build version incase that mattered it is 7.1.3. It didnt mention anything like Enterprise or Professional.
Hope this helps :)
Hope this helps :)
I don't know of a "build me a form from this db table" sort of stuff for J#; If you find one, let me know :-)
There are some nice tools for the microsoft sql server express edition; you can use all this stuff with impunity.
http://msdn2.microsoft.com/en-us/express/bb410792.aspx
The layout of the data/class library hierarchy is really hard to recommend; you'll need to decide fundamental issues like 'what is a team'? 'what is a roster'? 'what's a player?' 'what stats are relevant to the simulation'? etc...
However, what i do strongly recommend is that you keep the simulation data (ie the intermediate values in the compuations, as well as the results) in a data structure of some kind that you can persist to the database. Then you save each step you went through, and persist all of the data to the database.
Add a "heartbeat"/"tick" to the data, too.
This will allow you to replay/reverse/review each intermediate step of the simulation at your whim.
You can examine the model, and tweak /revise the simulation easier.
then you get cool "replay" modes for free, too.
btw, this tick/heartbeat is not a timestamp; don't depend on a clock... it makes comparisons and such much too messy.
-john
There are some nice tools for the microsoft sql server express edition; you can use all this stuff with impunity.
http://msdn2.microsoft.com/en-us/express/bb410792.aspx
The layout of the data/class library hierarchy is really hard to recommend; you'll need to decide fundamental issues like 'what is a team'? 'what is a roster'? 'what's a player?' 'what stats are relevant to the simulation'? etc...
However, what i do strongly recommend is that you keep the simulation data (ie the intermediate values in the compuations, as well as the results) in a data structure of some kind that you can persist to the database. Then you save each step you went through, and persist all of the data to the database.
Add a "heartbeat"/"tick" to the data, too.
This will allow you to replay/reverse/review each intermediate step of the simulation at your whim.
You can examine the model, and tweak /revise the simulation easier.
then you get cool "replay" modes for free, too.
btw, this tick/heartbeat is not a timestamp; don't depend on a clock... it makes comparisons and such much too messy.
-john
ASKER
Well my idea was to actually develop some sort of Editor before making the simulation so I can begin creating all the potential players/clubs/stadiums etc through a visual interface rather than manually entering them into the DB.
Once I have established a fully working Editor my next step was going to be developing classes such as Match, Transfer etc which will handle each "instance" of these particular objects within the game. This way it is handled in a more controlled manner rather than hardcoding them behind buttons. These classes will persist the associated data to the DB which I believe was what you were kind of suggesting. However, could you explain the "tick/heartbeat" in some more detail? I think I get the idea about not relying on a clock but how would you implement something like this without some sort of counter?
Once I have established a fully working Editor my next step was going to be developing classes such as Match, Transfer etc which will handle each "instance" of these particular objects within the game. This way it is handled in a more controlled manner rather than hardcoding them behind buttons. These classes will persist the associated data to the DB which I believe was what you were kind of suggesting. However, could you explain the "tick/heartbeat" in some more detail? I think I get the idea about not relying on a clock but how would you implement something like this without some sort of counter?
Sounds like you're heading down the right path to me, regarding a visual editor, and yes, those classes need to handle the persistence to the database.
The "tick/heartbeat" is used to indicate "one step" in the simulation of the season/game.
Let's look at a season:
There's the offseason
There's the preseason
The season
Each of these have 'events' associated with them... signing rookie players, trades, position/coaching changes, whatever.
The simulation you're writing needs to be able to "do many things" all at once.
For instance, Team A might buy a player from Team B.
This means, move compensation from team A to team B; move players from team B to team A.
If you assign a heartbeat (a monotonically increasing integer value of some kind) then you would give each of these updates the same heartbeat. This would indicate to your simulation engine that these things happened "simultaneously".
Or, let's say we're running a game simulation...
You need to play all the games that are on a given day, that start at the same time, in parallel. But really, your simulation engine can't do that. It can run match A then match B.
But the expectation of the player, watching the 'in game' feed, for instance, would be to see continuous updates from the other games, on major events that might occur... Scoring updates LIVE, etc.
What you are really doing is running all the simulations in parallel, with no graphical capabilities, but you're giving events in match A a heartbeat. Then, when you run match B, you restart the heartbeat and mark the events in match B, etc.
Let's say the simulator is running, and we're into the playing season.
And further, let's say that Wednesday, August 6th, is heartbeat 10000 for the league simulation.
Match A and Match B are both scheduled to start play at 1:00pm.
The heartbeat for the start of Match A is now, for this example, 10000.
Each "second" of the match, in the simulation of match play, we can assign a heartbeat counter.. so 10001, 10002, 10003, etc.
Suddenly, in second 15 of Match A, player22 scores! Woot!
The rest of the game is dead dull, and we end with a 1-0 final score.
The heartbeat now, though, is 13600 (10000 + 60*60).
When we simulate match B, we start the heartbeat over at 10,000 the value it had at the start of the day.
So now, someone "viewing" match B can see a live update (crawl at the bottom of the screen) showing Player22's score at second 15 of Match A.
This is an illustrative example; you might not support "live" viewing of the game. But hopefully the example shows why you can't use an actual timestamp, because sometimes you need things to happen "simultaneously".
-john
The "tick/heartbeat" is used to indicate "one step" in the simulation of the season/game.
Let's look at a season:
There's the offseason
There's the preseason
The season
Each of these have 'events' associated with them... signing rookie players, trades, position/coaching changes, whatever.
The simulation you're writing needs to be able to "do many things" all at once.
For instance, Team A might buy a player from Team B.
This means, move compensation from team A to team B; move players from team B to team A.
If you assign a heartbeat (a monotonically increasing integer value of some kind) then you would give each of these updates the same heartbeat. This would indicate to your simulation engine that these things happened "simultaneously".
Or, let's say we're running a game simulation...
You need to play all the games that are on a given day, that start at the same time, in parallel. But really, your simulation engine can't do that. It can run match A then match B.
But the expectation of the player, watching the 'in game' feed, for instance, would be to see continuous updates from the other games, on major events that might occur... Scoring updates LIVE, etc.
What you are really doing is running all the simulations in parallel, with no graphical capabilities, but you're giving events in match A a heartbeat. Then, when you run match B, you restart the heartbeat and mark the events in match B, etc.
Let's say the simulator is running, and we're into the playing season.
And further, let's say that Wednesday, August 6th, is heartbeat 10000 for the league simulation.
Match A and Match B are both scheduled to start play at 1:00pm.
The heartbeat for the start of Match A is now, for this example, 10000.
Each "second" of the match, in the simulation of match play, we can assign a heartbeat counter.. so 10001, 10002, 10003, etc.
Suddenly, in second 15 of Match A, player22 scores! Woot!
The rest of the game is dead dull, and we end with a 1-0 final score.
The heartbeat now, though, is 13600 (10000 + 60*60).
When we simulate match B, we start the heartbeat over at 10,000 the value it had at the start of the day.
So now, someone "viewing" match B can see a live update (crawl at the bottom of the screen) showing Player22's score at second 15 of Match A.
This is an illustrative example; you might not support "live" viewing of the game. But hopefully the example shows why you can't use an actual timestamp, because sometimes you need things to happen "simultaneously".
-john
ASKER
I think I get what you are explaining however, I am not 100% so I will give you my understanding and you can correct if need be....
The heartbeat represents a "day" in the season....and you could probably enhance this by having separate heartbeats to represent certain "hours" in that day as events can occur at different times (which will be reset after day ends) and this heartbeat is just an incremental counter?
The match heartbeat takes the "day/hour" heartbeat as the "kick-off" time, and then has its own incremental counter that represents "minutes" in the match which again is reset after the match ends?
But I must persist the heartbeat counter in order to retrieve the data associated wth the Events. So really the heartbeat is a way of controlling the simulation and gives you a numeric reference to events throughout the game?
Finally, you mentioned you cannot process the games simultaenously but can you not simply run the "Match" events concurrently by multi-threading?
Thanks, this is a really big help
The heartbeat represents a "day" in the season....and you could probably enhance this by having separate heartbeats to represent certain "hours" in that day as events can occur at different times (which will be reset after day ends) and this heartbeat is just an incremental counter?
The match heartbeat takes the "day/hour" heartbeat as the "kick-off" time, and then has its own incremental counter that represents "minutes" in the match which again is reset after the match ends?
But I must persist the heartbeat counter in order to retrieve the data associated wth the Events. So really the heartbeat is a way of controlling the simulation and gives you a numeric reference to events throughout the game?
Finally, you mentioned you cannot process the games simultaenously but can you not simply run the "Match" events concurrently by multi-threading?
Thanks, this is a really big help
Yes, you've got the core idea correct. the granularity of the heartbeat (year, month, day, hour, whatever) is really a convention, and it's up to you to manage it.
Yes, multitthreading can do it "all at once" but syncronization of the threads is a pain... especially if you dealing with sports where a game "clock" needs to be kept in sync.
And yes, you need to persist the heartbeat for exactly the reasons you gave.
Yes, multitthreading can do it "all at once" but syncronization of the threads is a pain... especially if you dealing with sports where a game "clock" needs to be kept in sync.
And yes, you need to persist the heartbeat for exactly the reasons you gave.
ASKER
Thanks John I believe I am in the right frame of mind to tackle this game now! I will let you know how I get on or I will contact you if I have anymore questions if that would be ok
Thanks again!!
Thanks again!!
great! have fun!
-j
-j
ASKER
I have another couple of questions for you. So the first thing you suggest I should focus on is linking my application with a DB? Do I need any external software for this? (when I used Borland C++ I also used an external package called Paradox which allowed creating/editing of the DB manually) or is loading the driver good enough to achieve this?
After I have achieved a connection with my DB, what would you suggest would be my next step? Do you have any experience in developing a game engine at all? for a management simulation? I have been informed that I could download ESMS+ and simply edit it as it is OS but I would rather build my own as it would be more of an achievement.