I’m creating a game in Java with slick2d library and I would like to implement a design pattern related to game settings (video, sound), so that you can implement all this methods that are needed to load, save settings… However, I would like someone to suggest me a design-pattern and if possible to make me a short concept of classes, so that I can start from something. For begin, settings will have the following attributes:
Video - resolution, full screen, fps
Sound - is sound on/off, volume
Have you looked at one of the existing solutions such as Java’s Properties class, or a 3rd arty option like ini4j. Going with the latter option allows you to have individual sections in your settings file for each aspect of your engine that you want to store (such as sound, video, input, etc). There’s always the option of using Java’s serialization functionality. It all comes down to what your requirements are and what solution best meets them. 8)
Thanks for that, I’ve seen that already. Any other suggestions ? I was thinking about Observer or Strategy.
Observer Pattern makes sense to me.
Quick Thoughts:
Having the subject be the Module that handles configuration of the video\audio settings, then the appropriate subsystems can register themselves to that module and reflect observed changes. Additionally, you could write a another observer for that module and have it save the configurations to file that you can load up when you restart the game.
So have your render subsystem observe the configuration module\window, when settings have been changed simply reflect them by observation in your rendering subsystem. Same with audio etc…
I wouldn’t make the GUI used by the user which configures the game settings the subject. I would definitely abstract the actual storing of configurations etc out (maybe into a singleton, I hate singletons, you could try the service provider which is slightly better) then have the GUI configure that. When the GUI configures that, the observers to that subject will be notified etc…
The observer pattern doesn’t really make sense for this. This doesn’t need a pattern at all. Don’t try and use a pattern just for the sake of using a pattern. That’s bad practice. Game settings are simple, and you are just trying to complicate it. The Properties class as CodeHead suggested does a great job of maintaining your game settings.
The only “pattern” that I think would be useful (contrary to Jeremy’s suggestion) is a Singleton. You don’t really want 2 instances of your property manager floating around. And it doesn’t integrate with your program at all. You simply send it info to store, and you request info for use in your game.
Saying it doesn’t make sense without any justification isn’t going to convince me, and it isn’t going to convince him either. I provided a full-detailed description for implementation, you just said it won’t work because ‘we shouldn’t use design patterns to solve out problems if they’re really simple.’ (or something to that effect) Patterns don’t complicate anything, they simplify them. Patterns are used to prevent creating tightly coupled and difficult to maintain code. It isn’t a valid argument for them to not be applied to a simple module because like all things in a program, simple things grow, simple things must be maintained and simple things will be extended to become more complex.
The Observer pattern is meant to create a loosely couple form of communication between one to many modules.
Global game settings is a subject, one module.
The various subsystems the configurations distributed to are observers, and are the many module.
It makes perfect sense.
You want to add a new setting later down the road for a newly installed subsytem? Easy, just add an observer. Job done. You want to change the way the configurations are stored? No problem, that code is well isolated from the actual configuration module. Since the modules are loosely coupled, there is very little maintenance headache.
I’m not saying you’re wrong, but I am saying you haven’t done anything to try and convince me.
The observer pattern is a one to many relationship (technically it could be many to many). So, every time you change a setting you are notifying ever registered listener of the change. That is several more method calls than are needed to adjust a single value. Sure, you could use a condition block to send the notice to a single observer, but at that point, you are doing what you would have without the pattern anyway, and defeating the purpose of the observer pattern.
And I have to disagree. Patterns don’t make anything simpler. They are used to organize code in an efficient manner and allow for easy maintenance and upgrade. That doesn’t necessarily make the actual code less or less complicated.
Anyway. My post wasn’t to say you are wrong. Besides a Singleton, what you posted may be the only thing that even sounds reasonable. I’m saying he has the wrong approach. You shouldn’t use pattern if you can’t (yourself) recognize a pattern that would fit your problem. Think about cutting a square peg in half to fit it in a round hole. It works, but that doesn’t make it a good solution. He’ll use the first pattern suggested and likely won’t even understand it or why it should be used. And patterns definitely make things more complicated if you use them where they aren’t needed or use them in the wrong situation.
@Troncoso I mostly agree with what you have said.
You could do what Java’s util Observable class does (I’m not advocating it’s use I am just saying that it solves this by only notifying observers when something significant happens, i.e the configurations are applied etc.) with setChanged() - if invoking ~10 configuration observers ones or twice when the game is running turns into some sort of bottle-neck your code must be doing something very absurd.
It simplifies one’s ability to interpret the code (since the pattern is usually universally understood, at least by the team.) Arguably, it also makes it easier to write if you’ve already got a pattern in mind to solve the problem.
I agree with this point that they should be implemented upon one’s own discovery. Patterns are a guide-line (like you suggest) not a concrete solution you can throw anywhere you find it works.
Is it just me or most Java coders are “pattern-philes”?
I’ve been on a lot of non-java boards and only in java-centric boards do I see these pattern-first problem solving procedures.
Opposed to the “make up your own and hope it works” pattern?
If you know a proved pattern is applicable to your solution, why in god’s name would you not use it?
You can go to your co-working and say “I used the observer pattern to… I used the strategy pattern to… I used the adapter pattern to…” and immediately they get a very well illustrated idea of what the solution might be.
Opposed to “I created this method, I’ve never seen anyone use it before and I hope it works. Sit down with me while we discuss the nitty-gritty details of my implementation instead of moving on to what really matters.”
You can’t compete with design patterns unless you want to trust your solution against these other well known patterns that have been implemented in a variety of solutions universally because they are known to very well comply to OO design principals and aid in the design of very modular and easily extensible systems. The key is that good design patterns aren’t created, they’re discovered & proven through the evolution of a complex system.
Any decent program on computer software development will go into at least some basics design patterns.
It’s better to use XML now but if you are going to try INI files, please check out my INI parser called JINI
Example usage:
JINI ini = new JINI("file-name");
// Reading properties
String property = ini.readProperty("Section-Name", "Property-Name");
// Writing properties
ini.setProperty("Section-Name", "Property-Name", "Property-Value");
// Renaming property
ini.renameProperty("Section-Name", "Old-Property-Name", "New-Property-Name");
// Renaming section
ini.renameSection("Old-Section-Name", "New-Section-Name");
// Saving INI file
BufferedWriter writer = new BufferedWriter(new FileWriter(new File("File-Name")));
writer.write(ini.populate("\n"));
writer.flush();
writer.close();
Hope you find this useful.
I suspect it’s more to do with Java being used as a teaching language.
At the same time students are learning the language, they’re being taught about patterns; it’s only natural to try and combine the two.
Sigh…
Missed my point. 
Abuse apparently did get it spot on. :point:
First of all, thank you guys on quick and constructive replies.
I want to point this out,
However,
[quote]You shouldn’t use pattern if you can’t (yourself) recognize a pattern that would fit your problem.
[/quote]
I’m not mean to be rude, but I have already first suggested above, in order to get an opinions about it.
However, I’ve already watched like 2x design pattern tutorials, and I really really got seek of using duplicate codes and many arrays… I haven’t ever used them before in a serious projects, but that’s the reason now I want to. I would like to recommend Derek Banas Design Pattern Tutorials http://www.youtube.com/watch?v=vNHpsC5ng_E&list=PLF206E906175C7E07.
Also, thank you SHC, I will take a look at that.
To be fair, you didn’t make your point very clear at all. You asked a question and stated an observation. That is probably why I missed it? If it was there, it was very poorly made.
These design patterns are used all over the JDK, in fact you can find them in most libraries. They aren’t used because Java is a very good OO learning language and people just picked it up there.
Java makes excessive use of the observer pattern in Swing, Decorators for IO etc… They’re used because they work.
Outside of Java, and in .Net you’ll find them everywhere too.
Don’t get me wrong, I’ve used patterns extensively in all the languages I code with. But I use them when I need to not when I want to.
I am not a very pro coder. However, I think you are complicating things a bit much. Settings are really trivial. May not be the most “elegant” way of doing things but it works, can be done fast, and has never bitten me in the ass.
Have some class that holds settings. On start up load settings into class. In the game if the user changes things (volume, graphics stuff) and said things do not need a restart, have your code do something like.
if(settingsClass.useWeatherEffects)
{
//do weather effects
}
What you want may apply here, it also may be over kill. If you only ever have 30 collidable objects, there is no need for spatial partitioning. Simple code seems to work the best.
Anyways, good luck on it.
If you take a class on design patterns, they will tell you the same thing I did. Just because you learn about patterns, or learn a new one doesn’t mean you should go out and try to use it in your next project. Sure, go find some example problems that are meant specifically for a pattern. Just don’t force them where they aren’t needed. You make it clear that you are trying to do that here.
The first step to solving any design problem:
No it shouldn’t be forced, but it should be identified if it resolves the problem.
The problem was to distribute configurations centralized at one module to many modules without tightly coupling. The Observer pattern does that for you.
I’d add some earlier:
-3) Is this the best problem (in the long term, project wide) that I could be dealing with at this moment?
-2) Is this really worth wasting time over vs. doing it the stupidest way possible…hopeful that me or someone else has already written and I can locate faster than wasting any more brain/time power over?
-1) If I’m think about solving a wider problem than I really need…kick myself in the shins.
0) Understand the problem
…
Protip: Don’t ever take a class on Design Patterns. Stick to Data structures and Algorithms. A nice compiler course wouldn’t be a bad idea. Oh…and if you only know one major programming paradigm, then spend time really learning the basics of some other one… preferable one as different as possible from what you know.