Unless I hit some other roadblock, I'll be implementing a java.util.prefs-based Config implementation, instead of jME's .properties-based system. Those of you who have used java.util.prefs will know that it is a very close match to the jME config goals, and isn't limited by Properties' primitive design.
Just posting this here to get an idea if there is any general demand for this. If it's just for me, I don't want to waste time even discussing whether or how to integrate it into the jME code baseline.
Hi Blaine,
Check out com.jme.system.PreferencesGameSettings, I think that's what you're looking for.
Thanks so much, nymon. Obviously my fault for not searching the API spec better. I expected that if there were a Preferences implementation, that would have been the default used by at least the newer samples and tutorials.
nymon said:
Hi Blaine,
Check out com.jme.system.PreferencesGameSettings, I think that's what you're looking for.
blaine said:
I expected that if there were a Preferences implementation, that would have been the default used by at least the newer samples and tutorials.
Yeah, but I don't know how I feel about that. When testing stuff out it's quite convenient to be able to just delete the file and start over. I beleive preferences is the way to go beyond testing though.
GameSettings has a .clear() method doesn't it? :-p
nymon said:
blaine said:
I expected that if there were a Preferences implementation, that would have been the default used by at least the newer samples and tutorials.
Yeah, but I don't know how I feel about that. When testing stuff out it's quite convenient to be able to just delete the file and start over. I beleive preferences is the way to go beyond testing though.
If it were only a matter of ease of resetting preferences, I'd still say that consistency across all environments would be worth providing a simple utility program (5 lines of code) which would .clear() or .removeNode() the specified preferences node. This utility would work for all jME and other programs which use Preferences, and would in fact be more platform-independent than del/rm. However, I still agree on your conclusion because it is very useful to be able to view and edit config files directly.
I get this direct-editing ability with Preferences because I develop on UNIX, but unfortunately, the API spec doesn't specify where the prefs file will be persisted to, and I don't even know where it's persisted to on Windows. So we're in agreement that .properties is easiest for generalized hands-on manipulation.
You and I, at least, are agreed that Properties impl. is well suited for samples, and Preferences for real products. However, the jME API looks to very much encourage Properties for all games, since AbstractGame manages a PropertiesIO*. I think the paradigm used for configShowMode is great: Generalized classes set the defaults to what you want to encourage in real games (incl. very simple real games), and sample classes override the defaults to be appropriate for samples. So, I'd suggest first that AbstractGame should not be wedded to a config persistence strategy to begin with (code to the interface); and secondly, default it to Preferences.
FOOTNOTE:
* I have not studied or played with this, it's based on a quick peek into AbstractGame.java. Looks very much not like coding to the interface, but correct me if I'm wrong.
darkfrog said:
GameSettings has a .clear() method doesn't it? :-p
But using an API method requires Java coding and compiling. For samples, it's very convenient for users to be able to manipulate their configs without needing to know Java or to build anything.
darkfrog said:
GameSettings has a .clear() method doesn't it? :-p
Didn't notice that, thanks. But being able to see whats in it is what I was getting at for testing.
nymon said:
darkfrog said:
GameSettings has a .clear() method doesn't it? :-p
Didn't notice that, thanks. But being able to see whats in it is what I was getting at for testing.
Ah. :)
blaine said:
I get this direct-editing ability with Preferences because I develop on UNIX, but unfortunately, the API spec doesn't specify where the prefs file will be persisted to, and I don't even know where it's persisted to on Windows.
If I'm not mistaken they get written to the Registry under Windows :|
You are correct, in HKEY_CURRENT_USERSoftwareJavaSoftPrefs
blaine said:
So, I'd suggest first that AbstractGame should not be wedded to a config persistence strategy to begin with (code to the interface); and secondly, default it to Preferences.
The *Game classes in jME should be seen as example classes only and give a quick start. Any production-ready game made with jME will have an own application implementation. Probably StandardGame is suited for production use (or near that), and it is not restricted (or even defaults to PropertiesIO).
irrisor said:
blaine said:
So, I'd suggest first that AbstractGame should not be wedded to a config persistence strategy to begin with (code to the interface); and secondly, default it to Preferences.
The *Game classes in jME should be seen as example classes only and give a quick start.
That doesn't make sense. StandardGame is not only a *Game class, but is an AbstractGame in the OO sense. I.e., StandardGame extends AbstractGame, and therefore has a PropertiesIO-specific field.
Any production-ready game made with jME will have an own application implementation. Probably StandardGame is suited for production use (or near that), and it is not restricted (or even defaults to PropertiesIO).
StandardGame has a "properties" field which is a PropertiesIO, since it extends AbstractGame. Not only does it default to PropertiesIO, but subclasses may not override it with a different type.
I realize that abstractGame.properties and abstractGame.getAttributes() do not need to be used by subclasses, that getAttributes() can be overridden, and that the "properties" pointer defaults to null, but it's misleading at best to provide subclasses with a field named "properties" which some subclasses should not use. If my subclass is provided with a "properties", it sure looks like I should use that field for my properties. The properties-IO-specific stuff should either be moved to the direct subclasses of AbstractGame which should provide a PropertiesIO, or (if several directs need the same behavior), a new abstract should be inserted between them.
A look at the API spec doc shows pretty clearly that the config/settings system was not designed for flexibility. I'm not criticizing the developer-- you do what you have time to do. I'm just suggesting a way to improve it. The current system encourages use of PropertiesIO in all Games, and people who want to subclass AbstractGame with a PreferencesGameSettings must use bad OOD. This discussion has been proceeding as if PreferencesGameSettings can be swapped in to function as PropertiesIO, but it was not designed like that. If it were, PreferencesGameSettings and PropertiesIO would implement a common interface, and it would be a simple matter for AbstractGame to use that interface in getAttributes() and provide abstract methods to require subclasses to instantiate a specific properties/settings interface. It sure looks to me like the GameSettings interface was provided exactly for this use case-- to isolate implementations of settings/properties systems, but PropertiesIO doesn't implement it.
Perhaps Matthew Hicks, who wrote GameSettings, never got around to implementing the extra PropertiesIO methods so that it can implement GameSettings, or didn't have the time to re-design the persistence code to get it out of AbstractGame, or perhaps you wanted to keep PropertiesIO simple and not implement all of those properties in GameSettings. For the first two cases, it just needs the time of any developer who understands OOD and interface implementation plugging. For the last case, the GameSettings interface could just be split up to EssentialGameSettings and AdvancedGameSettings, where AbstractGame would only use the first (which PropertiesIO would implement), and anybody who needs the extra properties would need to use an AdvancedGameSettings implementation.
blaine said:
Perhaps Matthew Hicks, who wrote GameSettings, never got around to implementing the extra PropertiesIO methods so that it can implement GameSettings
uh, ok, I thought he did. I didn't have a look at the code, sorry. (I even thought StandardGame would not extend AbstractGame, but that's wrong, obviously)
So at least for StandardGame changing that properties stuff to a more general solution makes much sense...
I don't know who that Matthew Hicks guy is, but it seems to me the design of GameSettings was pretty impressive. :roll:
Unfortunately PropertiesIO could not be excluded because of its connection directly in AbstractGame, which is unfortunate because it creates some complexity to people trying to use StandardGame.
The reason GameSettings doesn't touch PropertiesIO is because ideally PropertiesIO should be deprecated as it does have many flaws and hopefully will be removed in 2.0 in favor of a more pluggable system like GameSettings. This is actually something that was discussed by the developers when GameSettings was written by that awesome developer. 
GameSettings IS intended to be the more general solution…
darkfrog said:
I don't know who that Matthew Hicks guy is, but it seems to me the design of GameSettings was pretty impressive. :roll:
Unfortunately PropertiesIO could not be excluded because of its connection directly in AbstractGame, which is unfortunate because it creates some complexity to people trying to use StandardGame.
The reason GameSettings doesn't touch PropertiesIO is because ideally PropertiesIO should be deprecated as it does have many flaws and hopefully will be removed in 2.0 in favor of a more pluggable system like GameSettings. This is actually something that was discussed by the developers when GameSettings was written by that awesome developer. :)
GameSettings *IS* intended to be the more general solution...
According to what has been written about the compatibility goals of 2.0, now would be the perfect time to fix this in 2.0.
Well, you've got me convinced, just convince the other developers.
I don't care much about the old prop impl - just change it. I like it going to file by default, though. And if it works like before (only changed API and impl) I don't think that someone would be opposed to changin it in AbstractGame.
irrisor said:
I don't care much about the old prop impl - just change it. I like it going to file by default, though. And if it works like before (only changed API and impl) I don't think that someone would be opposed to changin it in AbstractGame.
Preferences is not going to go to file by default (on Windows). To achieve this, I propose defaulting AbstractGame to a GameSettings implementation of PreferencesGameSettings, and override this with a PropertiesIO (which will then implement GameSettings) in BaseGame. This way, anybody using StandardGame will get a PreferencesGameSettings, and all SimpleGames (incl. all of our sample games) will continue to get a PropertiesIO which will persist to file. BaseHeadless..., FixedFramerate..., etc. would default exactly the same as StandardGame, and I think that's what they should do.
To minimize impact to our own sample game code, and to all users of SimpleGame, we could modify GameSettings a little to accommodate the most common current PropertiesIO usage. Otherwise, all cases of properties.get() and properties.set(), for example, would have to be updated.
At the other extreme, we could name things to alleviate the misleading field name of "properties" (and any related methods) for an object which will now be a GameSettings, not a *Properties. This would obviously mandate code changes for anybody using "properties" directly.
my two cents: It just needs to work and be simple to understand (I personally feel the one used in standard game is too overwhelming for our demos/test cases.) I think most people writing a serious game/app are probably doing their own approach/implementation for game prefs.