While I am learning java very quickly (at a much faster rate than most, I feel), I keep running into design problems that while I can solve, I am unsure if the way I am solving them is acceptable. I'm more or less curious what your opinions are on my current design scheme, because it involves using a single class (that's basically almost completely static) to handle a large amount of the game's data.
This is an RPG, so there's tons and tons of data that has to be stored in a save file and recalled later, so I came up with this method of saving/recalling my data and I am curious what your inputs are on it.
Here's a breakdown of my design plan, basically each class has to talk "through" a single static GameParser class file, that file handles many variables within the game like the player's X/Y coordinates, the map the player is currently on, the time of day, items in their inventory, etc.. It also handles the save/load functions.Main
- Launches the app, and goes into the main menuMain Menu
- Asks the GameParser for very basic information, like a list of the save game titles.GameParser
- Holds all critical data all the states would want to access, all states can fetch anything in the GameParser with a simple getProperty. It also handles saving the game to a .property file when requested. Basically all data that needs to be shared between classes *or* serialized is stored in a Properties() *but* only output to a file on request.InputHandler
- Asks the GameParser what the control settings are. (technically right now
each of my classes have their own Input handlers, I need to change this)PlayState
- Handles playerX/Y and map coordinates internally, but sends the data to the GameParser in the update() loop to keep the GameParser up to date.Menus
- An example would be the Character Data menu, it would ask GameParser for basic stats like STR, DEX, Agility, etc.Map Screen
- Would ask GameParser for the player's X/Y coords and what map he is on *NOT
* the PlayState that is currently sending the data to GameParser, the Map Screen has no idea PlayState even exists.Dialog
- Would request statistical information, for example, it may need to know your INT stat to determine what responses you can give to an NPC.
A simple example of this in-work right now would be my Clock and LightingController classes. They can not see each other at all. The Clock itself runs on internal variables, but also sends updates to the GameParser in it's update loop, keeping the data in the GameParser up to date. Then, the LightingController is what controls the time of day and if the streetlights in game should come on. It does this by checking what the current time is. So it asks GameParser to send it it's property values for Hour/Minute/Day.
(Note I only included main parts of the game, no point listing all the subclasses/objects/etc)
So my overall question is, what do you think of this design concept? Is this a good way of handling variables that are mostly intended to be serializable and static? An example of what GameParser handles:
- Time of day, character inventory, character stats, reputations with NPCs, what map the player is currently on, name of the character, where the character is on the map, difficulty level, etc.
It should also be noted that NONE of the class files directly use the data in GameParser, they all handle/manipulate their own data internally, and just send a copy of the results that should be shared with other classes, like the clock sending the time.
Thanks for putting in the time for the long read.
Here's a pastebin of my Clock.class as an example, as you can see, every time clockTicker is called to update the clock time, at the end it sends the changes directly to GameParser:http://pastebin.java-gaming.org/506e87f4984
..and here's GameParser itself:http://pastebin.java-gaming.org/06e8f894488