Is this a logical way to handle data?

Newbie & Debugging Questions
#1

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 menu
Main 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)

http://sixtygig.com/junk/designconcept1.png

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. :smiley:

EDIT:
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

#2

I don’t think its worth doing stuff like this if you’re working alone.

So you basically made a “Global” class that has all the game data you would need to do stuff. That way any guy on the dev team can create content independently without others devs work.

I don’t think you need this functionality if you’re working all by yourself :stuck_out_tongue:

#3

So overall though, assuming I want to keep it this way anyway, it isn’t that big of a deal to basically make a master “GameParser” that stores all the common data that most all the classes will want access to?

I feel like I’m picking up Java programming itself extremely quickly, but some of the “OO Principals” get a little gray sometimes, like in ths case. :confused:

#4

So far, so good. In terms of how best to structure data, that is totally up to the “style” of programming that people have. OOP is very good for these concepts in general, because you can actually improve on and fix things that are broken later on. The more broken up a program is, the better. (Well, unless you go overboard… :persecutioncomplex: )

Moving on…

In terms of how you split things up, well I’d say do what you are comfortable with. I always love to just keep the “hardware” side of things separate from the “game” side of things. So, in my games, I usually split music, input, and image drawing into its own modules and have the game use those modules. As for the game items themselves, I usually think that having one class per game object is good enough, and if they share some common functionality then I bind them together through implements.

However, each programmer has their own philosophy on these things, and I don’t think it is wise to just curb your style, especially since you need to be able to know where everything is in the future. What you have works and it breaks things up enough for you to make your game. The only thing I’d recommend is to find a way to not have the input in each class (it is very useful when you want a key configure screen).

Yeah, the big key is just doing what you are comfortable with. Programming a game is a little bit more artsy… each game has its own needs. Sometimes you need to break design patterns to get the speed of functionality you want. Don’t let a style confine you into making a lifeless game. You can think outside the box sometimes…

#5

Thanks for the input! I’m glad I’m on the right track. That makes me feel a lot better about the direction I’m going. :wink:

With my input setup as it is now, it’s a bit confusing (thus the need to rewrite).

Basically, every single interactive “area” of the game has it’s own controls, for example, all the menus have almost exact copies of the same control methods, but it fetches those controls from a SettingsParser (that happens to function a lot like my GameParser, but it’s specific for settings and has a few more checks/safeguards).

For example, instead of putting in the specific key for every single class file that shares the same basic controls (example, WASD controls are pretty much universal everywhere) each class that has controls, has a setup like this:


	if (input.isKeyPressed(SettingsParser.getKeyUseObject())){
	//Do stuff
	input.clearKeyPressedRecord();
	return;
}

Then, I have 2 parts to my SettingsParser, one that takes in all the data from the settings page when the player updates the controls, the other detects what keys are attached to what and sends them to the getStatement related to that get (like the getKeyUseObject above)

Basically this is asking SettingsParser what key useObject is assigned to in the properties file. Every time the game is launched it runs a check to make sure all the keys are assigned to something, and if one doesn’t exist, inject the default key and saves the file. (In case someone breaks their settings file manually messing with it, it will just replace whats missing on request instead of rewriting it all)

The getstatement for that key above:


public static int getKeyUseObject(){return KEY_USE_OBJECT;}

When settings is activated, it runs a series of checks like this one below to make sure the settings are valid, and fixes errors.


try {
	KEY_USE_OBJECT = Keyboard.getKeyIndex(properties.getProperty("key_useObject").toUpperCase());
} catch (NullPointerException npe) {
	properties.setProperty("key_useObject", "space");
	KEY_USE_OBJECT = Keyboard.getKeyIndex(properties.getProperty("key_useObject").toUpperCase());
}

But overall, I need to rewrite it. Every single class that has controls right now has it’s own independent (and crazy redundant) controls. I need to fix that. :slight_smile:

#6

About the keys part… Doesn’t that make is so that when for example there is a player updated at the start of the loop and you clear keypressedrecord, if there is another place where you check if key is pressed after player has been updated that wouldn’t get executed, because you turned it off?

#7

oh no, it just clears the buffer. (From how I understand it). The main reason I have it there is for my custom fades, while the game is “fading” from map to map, or menu to menu, or map to menu, the controls are locked out (Via a boolean) while it runs a fade-out method so you can’t do anything during the transition. But for some reason, without clearKeyPressedRecord(); if you click any keys during the fadeout (when a boolean has locked out all controls and nothing should work) as soon as the boolean to lock the controls is set to false and the controls come back online, whatever buttons you pressed during the time the controls were locked all fire all once. It’s rather odd. But running clearKeyPressedRecord(); after every key press fixed that.

Another example is if I had something like my “up” key assigned to isDown, and I was holding it, while I was holding it the other keys could be pressed (and work) but for some odd reason if I pressed a key while holding “up” the key would also fire after up was released.i Example: I’m holing the up key, while holding up I hit my useObject button (spacebar), since I’m moving up and there’s no objects in front of me so it works as intended and does nothing. but if I keep moving up and run into an object that CAN be used and release the up key, the useObject key fires and uses the object even though I pressed the key a long time ago.

For whatever reason, clearKeyPressedRecord(); fixes both of those issue completely. I honestly don’t know why. But it does. :wink:

…now to make it real confusing, like I said in my other reply, my input controls need completely rewritten… when crossing between say, the gameplay and the inventory screen the entire input controller gets dumped and recreated. But if I say, press the “I” key (triggering a fadeout that locks the controls) and then quickly hit another key before the fade is complete and the controls unlock, that next key is fired even though I pressed the key before the old input handler was dumped and a new one completely recreates it in a totally new class file. So yeah, no idea. :smiley: