Hi everyone,
I started using JME some weeks ago so this is my first post (applause etc :D). Thanks for this piece of software which looks promising…
Maybe I am a little late since RC1 is here but to begin with the beginning, I use StandardGame and I implemented my own GameSettings class: why all the methods getInt, setInt, and the like are in the interface ? I couldn't find any reference to them in the code…
Thanks
DD
First, welcome to the forum. 
Second, the reason they are there is to make those methods available to games that want to make use of those common data types. If you're going to create a custom GameSettings implementation and expect anyone else to use you'll want to implement all those methods. However, if you are only doing something for your own purposes or just don't like to share, then you can just make them bogus methods that don't do anything.
Just out of curiosity, how are you implementing GameSettings? What is your backing storage?
Hi darkfrog,
darkfrog said:
Second, the reason they are there is to make those methods available to games that want to make use of those common data types. If you're going to create a custom GameSettings implementation and expect anyone else to use you'll want to implement all those methods. However, if you are only doing something for your own purposes or just don't like to share, then you can just make them bogus methods that don't do anything.
First of all, i am planning to share when i will have something useful i already have some useful camera actions i did some time ago, but i need to polish them a little and see if no one has done the same in between... and i was planning to propose to port the build system to maven (if someone ever care about).
And yes i have plenty methods with
throw new UnsupportedOperationException()
:(
But i still don't see why this has to be in the interface: the current code doesn't need it and a custom game can work with its own implementation directly. I know that using interface is GOOD (i do it all the time) but we are talking about a datamodel class here. But it is not a big deal anyway (i carre to much about details)
darkfrog said:
Just out of curiosity, how are you implementing GameSettings? What is your backing storage?
i currently have my settings persisted in XML using Jibx and my object model looks like:
Options
+ Profile
+ VideoSettings
+ AudioSettings
+ SavedGame (todo)
with one file for options and several profile files with each containing (profile + VS + AS)
And i am a total noob in game dev :D
DD
c_inconnu said:
But i still don't see why this has to be in the interface: the current code doesn't need it and a custom game can work with its own implementation directly. I know that using interface is GOOD (i do it all the time) but we are talking about a datamodel class here.
I think that's the point, you don't even want your own code dealing with the concrete implementation due to the nature of game development.
To (hopefully) be more precise you are much more likely to want to save all your settings out using a readable text format (like XML) during development so things are easy to debug. But when you finally release your game you are more likely to want to save out to some kind of binary file. If your code is using the interface this becomes a simple one line change as opposed to changing all the concrete usages.
Gentleman Hal said:
To (hopefully) be more precise you are much more likely to want to save all your settings out using a readable text format (like XML) during development so things are easy to debug. But when you finally release your game you are more likely to want to save out to some kind of binary file.
maybe...
Gentleman Hal said:
If your code is using the interface this becomes a simple one line change as opposed to changing all the concrete usages.
from my point of view, it is the role of another layer (DAO if you ask) to abstract the persistent storage... but maybe i am too much "J2EE-centric" :P
c_inconnu said:
but maybe i am too much "J2EE-centric" :P
I can cure you of that... :wink:
The idea here is to simplify the process of putting values in and getting values back out. If you simply have single method like:
void set(String key, String value)
and the getter:
String get(String key)
Then if you want to put a int into your GameSettings you have to do:
set("MyInteger", String.valueOf(myInt));
But with setInt you can do:
setInt("MyInteger", myInt);
And to get it back out:
String s = get("MyInteger");
int myInt = -1;
if (s != null) myInt = Integer.parseInt(s);
Alternative:
int myInt = getInt("MyInteger");
It's more of a convenience than anything. BTW, one feature the PreferencesGameSettings has that is pretty hard to reproduce in most other persistence models is serialization of objects.
darkfrog said:
one feature the PreferencesGameSettings has that is pretty hard to reproduce in most other persistence models is serialization of objects.
:? Now I'm really confused - isn't object serialization what persistence models are all about?
hevee said:
:? Now I'm really confused - isn't object serialization what persistence models are all about?
Yes, but object serialization is a binary format (native to java). If you want to serialize objects to xml or database, you cannot just consider all data as being java.lang.object : you must define somewhere a mapping between your object model and your XML/DB schema. Just as Preferences does...
It seems to me that it is a better approach to define settings in a class specific to your game, with field that fit to your particular game. This class must implement GameSettings which should not contains other getter/setter that those which are needed by the game engine. The point here is that PreferencesGameSettings is the data model AND the persister... :evil:
:D :D :D
Not true…GameSettings is the model and PreferencesGameSettings implements and provides persistence. 