Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (579)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Game design patterns, any pointers?  (Read 9404 times)
0 Members and 1 Guest are viewing this topic.
Offline f.l.x

Senior Member


Projects: 3


there is no place like 127.0.0.1


« Posted 2006-06-24 23:58:53 »

It's not the first time that it happens to me that when my project grow big enough, or if i retake it after some time, i get lost into it really easy, not knowing why whas i doing the things that way or what was i doing here aor there in the code. It has happened to me right now, i've finished finals and i'm retaking my litle worms clone, but i don't know how to handle it.

That's definetly because my designs are very thin, i mean, i only do a couple of scraps on paper and then begin coding, changin the desing on the fly to fit the part of the game i'm working on each moment, ending with a very complicated thing to work with.

I haven't had any luck on my recently finished exams so there could be a couple of years until i study something about software enginering, so i need some pointers on desing paterns, and if there is any particularity on game desing.

Thanks Smiley

Litterarum radices amaras, fructus dulces
http://flx.proyectoanonimo.com
figth spam!
Offline CommanderKeith
« Reply #1 - Posted 2006-06-25 06:44:46 »

Shawn Kendall's blog had some stuff on this and a good link to http://www.gamearchitect.net/Articles/GameObjects1.html
which talks about component vs inheritance architecture.

I'm having the same  problem too.  The bigger & more fleshed out my game gets, the more I find myself re-engineering my game engine to be more simple & flexible.  The best thing I read was to program to an interface, not an implementation.  ie, only call methods of interfaces, not methods specific to classes. 

A recent problem I was having is trying to get access to, say, the GameWorld from its member Rock object.  I ended up just making the current GameWorld a static member of the Main class so that I can always get access to it without having every Rock keep a reference to its GameWorld.

Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #2 - Posted 2006-06-25 12:46:17 »

A recent problem I was having is trying to get access to, say, the GameWorld from its member Rock object.  I ended up just making the current GameWorld a static member of the Main class so that I can always get access to it without having every Rock keep a reference to its GameWorld.
I've done this (in fact Quix still does this) but long term it'll cause more problems that it solves. I've been slowly refactoring Quix away from using it and the code has definately got better as a result.

Globals? Just say no. And don't even think about using a singleton, that's just sweeping it under the rug. Angry

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline f.l.x

Senior Member


Projects: 3


there is no place like 127.0.0.1


« Reply #3 - Posted 2006-06-25 12:48:31 »

that's exactly what happens to me, i allways find myself coding for the implementation and not for the interface.
I'll try to do what the article says
Quote
(1) program to an interface and not to an implementation and (2) favor object composition over class inheritance


i've also been looking at some design documents templates on gamedev.net and gamasutra and they are all oriented to the market instead of giving some gidelines for the implementation.

Litterarum radices amaras, fructus dulces
http://flx.proyectoanonimo.com
figth spam!
Offline f.l.x

Senior Member


Projects: 3


there is no place like 127.0.0.1


« Reply #4 - Posted 2006-06-25 12:52:54 »

here is a pointer http://www.gamasutra.com/features/20040510/adams_01.shtml

sorry for the double posting Wink

Litterarum radices amaras, fructus dulces
http://flx.proyectoanonimo.com
figth spam!
Offline purpleguitar

Junior Member





« Reply #5 - Posted 2006-06-25 13:52:50 »

I have just recently begun studying the intersection of game programming and design patterns.  I welcome any links that others may provide.  My results are preliminary, but thus far, I have found the State and Visitor patterns to be easily applicable to game programming:  State to maintain sprite and game status and Visitor to encapsulate class-specific behavior outside of the inheritance hierarchy.  These two patterns are defined in the classic GoF book (Design Patterns, Gamma et al.), although I highly recommend the presentation in Holub on Patterns (Allen Holub).  Depending on how the rest of the summer goes, I'm hoping to start writing a paper on this subject, and I'll try to remember to post a followup then.  In the meantime, feel free to check out my eeclone game, which was designed specifically to explore some design patterns in game programming: http://www.cs.bsu.edu/~pvg/games/eeclone.

Regardless of how well one does on tests, I believe that it is never to early to study design patterns.  Don't put it off until an undergraduate course on software engineering -- it is one of the most interesting and applicable aspects of modern computer science, and it is generally not given its due in education.  (In fact, I will be teaching our introductory computer science course next semester with an early emphasis on OO principles and patterns.)

The "program to interfaces" concept is central to design patterns.  Even if you don't have the opportunity to delve into design patterns now, keep that idiom in mind, and you will probably trip across patterns without knowing it.

It is also worth noting that "design patterns" has a wider usage than I am discussing here.  My interest is in design patterns for software engineering, specifically for software design.  This seems to be the domain of your question.  Others have discussed design patterns for game design, which has little or nothing to do with game implementation.  For example, one could apply good game design patterns to create a board game, since they deal with game flow, keeping player interest, fun, etc. 

Also, there is nothing wrong with singletons if they are used correctly.  Like any pattern, it should only be used when applicable.  A misuse of any programming idiom or pattern will lead to headaches!  For example, the sound engine in EEClone is a singleton.  There is only one interface to the sound card that I use, and I need to manage what sounds have started or stopped, the number of pooled threads, etc.  Singleton is a natural fit.


Cheers!
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #6 - Posted 2006-06-25 16:48:22 »


Also, there is nothing wrong with singletons if they are used correctly.  Like any pattern, it should only be used when applicable.  A misuse of any programming idiom or pattern will lead to headaches!  For example, the sound engine in EEClone is a singleton.  There is only one interface to the sound card that I use, and I need to manage what sounds have started or stopped, the number of pooled threads, etc.  Singleton is a natural fit.

I have yet seen a use of a singleton that was justified other than someone being lazy. Singletons are 'sexy' in that they're an easy pattern to understand (at least trivally) and implement, and they provide a way for people to revert to procedural programming, except they can claim to be doing OOP because "look, it's got classes and everything!".


On to your example:

1. The fact that you have one sound card is irrelevant. Thats an implementation detail that is managed by the OS, not your code.

2. Without knowing what your sound 'engine' does I still bet there will be usages which will require more than one. Even if you only use one, that doesn't mean you should enforce it.

3. Everyone forgets the proper definition of singleton, it's not "only one instance", it's "only one instance, which is accessible everywhere". I don't know what your crazy code is doing, but I sure as hell don't want (eg) my low level controller code touching the sound output. Or my networking. Or 90% of my code which doesn't care about sounds. But suddenly with a singleton I can no longer make that assumption, because anyone, anywhere can mess with it's state without my knowing. That makes for hard to debug code.

4. Singletons make unit testing a whole heap more difficult, even if you managed to work them in somehow you end up only testing a small amount of the possible code paths that you could of done otherwise. What if I'm testing some code on a machine without a sound card? I could use a mock sound engine which does nothing, but because you've welded your code so tightly I can't easily do that.


You want only one sound engine? Fine - Just Create One.

See also: Singletons Are Evil and Singleton Considered Stupid

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #7 - Posted 2006-06-25 19:16:34 »

Pragmatic programming says that any fixed rule like "Singletons are Stupid" is probably wrong Wink. If it works for your situation - then great - if proved to be a problem just refactor it out - and thats where singletons are useful (well sorta not these days with modern IDESs):

 At first you think its a bunch of utility methods - so you make it a bunch of static methods. Later you realise you want some state in there and multiple versions of that state. Now you get to go round everywhere you use the static methods replacing them with calls to an object to be passed in. Part of this problem goes away if you'd been using an instance (albeit a single instance) of the class all along (i.e. the singleton) - some of the assumptions still hold true.

Note sure when the last time I read the GOF book was, but I don't remember anything about a singleton being "accessible everywhere"? This http://en.wikipedia.org/wiki/Singleton_pattern doesn't seem to mention it - but like I said its been a while. I don't see anything wrong with limiting the scope of the accessor to a singleton. Unit testing, maybe you could make the constructor package level access instead of private - then unit test it locally to the package. Yes this would break the mould a bit - but heh, pragmatism.

Note: I'm not "for" singletons - I just think the main problem with designs most of the time is that people sit there worrying about what "rules" there are, and which "patterns" they can abuse - instead of just thinking, what works here. Stick the patterns in your head - and they'll just sort of pop up when needed Smiley

Re: GameObjects in GameWorld. I had this problem with every game I started for ages - and it came down to me learning to break a rule that I'd got stuck in my head. When you're designing a tree structure outside of games - you tend towards not letting the children know the root of the tree (at least not directly). This is generally so nodes can be moved about and put in other structures without pain. Game's code is far less transient and far less likely to be reused (at least game objects are). I just took the step that you can't create a game object without the world in which it lives - the game object can always just use its reference to the world. Saves me a whole lot of hassle and hasn't added any headaches.

Kev

Offline g666

Junior Member





« Reply #8 - Posted 2006-06-25 21:52:11 »

I use this   Smiley

http://www.laputan.org/mud/

desperately seeking sanity
Offline Breakfast

Senior Member




for great justice!


« Reply #9 - Posted 2006-06-25 22:07:07 »

I'm totally with kevglass on the "no rule is absolute" side of things. There are times when a Singleton is less convoluted than the alternatives and the more readable your code is the more likely it is to get finished.

I do kind of agree with the Steve Yegge article linked above- there are a lot of ways to misuse any tool, and the world is full of "when you only have a hammer every problem looks like a nail" situations, especially when you're newly graduated and know about 1/100th of what you think you know. However I've just realised I  don't hold with the "you can't do this because it's a bit like procedural programming" argument. As I understand it, your processor is going to be running procedural code no matter whether you write it in an Object Oriented, Functional or procedural way. I think if SteveY is going to criticise slipping bits of the procedural paradigm into object-oriented programming he may be on shaky ground when he goes on about slipping bits of functional programming into the object-oriented paradigm, which happens a lot in his other articles...

I think clean, efficient, human-readable code is more important than tying yourself into any single paradigm, model or specialisation. I also think that doesn't really relate to the actual topic of the thread, so maybe I'll stop typing now...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline CommanderKeith
« Reply #10 - Posted 2006-06-26 10:24:30 »

Globals? Just say no. And don't even think about using a singleton, that's just sweeping it under the rug. Angry

Re: GameObjects in GameWorld. I had this problem with every game I started for ages - and it came down to me learning to break a rule that I'd got stuck in my head. When you're designing a tree structure outside of games - you tend towards not letting the children know the root of the tree (at least not directly). This is generally so nodes can be moved about and put in other structures without pain. Game's code is far less transient and far less likely to be reused (at least game objects are). I just took the step that you can't create a game object without the world in which it lives - the game object can always just use its reference to the world. Saves me a whole lot of hassle and hasn't added any headaches.

So how are each of you letting the GameObjects have access to their GameWorld?  I changed to having a global static GameWorld reference because I'm sick of having to pass around GameWorld references to all GameObjects.  Having a centralised GameWorld seems to make sense.  I can see 3 options:

use a static global reference/singleton, ie Main.getGameWorld();
give every GameObject a reference to its GameWorld in the constructor, ie new GameObject(gameWorld);
pass the GameWorld reference as a method parameter like: gameObject.update(gameWorld);

Cheers  Smiley,
Keith



Offline f.l.x

Senior Member


Projects: 3


there is no place like 127.0.0.1


« Reply #11 - Posted 2006-06-26 10:49:14 »

At first view the second way seems more oo than the two others to me. I was using globals too, but i'm thinking of refactoring now

[edit] it comes to my mind that swing and awt components work in  a fourth way, all of them have a getParent method, so they save a reference to their container, we should just create a GameObject and  add it to the world GameWorld.add(new GameObject()) and that add method could set the "parent" for this GameObject[/edit]

Litterarum radices amaras, fructus dulces
http://flx.proyectoanonimo.com
figth spam!
Offline Mr_Light

Senior Member




shiny.


« Reply #12 - Posted 2006-06-26 13:25:54 »

Do you really interact with the whole Gameworld? or is it part of the gameworld? I don't think it's as much defining global var beeing as bad, and defining states 'globaly' well in a sence that you should evaluate if the state or stuff your sticking in gameworld is really that global/genetric should the scope perhaps be smaller.

on a side note every interaction pattern has to do with references, but we don't call them reference patterns because they are about interaction(next from the name 'reference pattern will be come confusing 'these are the reference patterns for the reference patterns xD) The need for reference comes forth out of the need for interaction.

ps. There is also the wiring 'option' (IoC / DI / aop - approch of things)

I don't think there are specific game patterns, well to a degree, if you disect it you'll probebly end up with a 'normal' pattern.

something interesting to look at is perhaps the immutable pattern. but I think that most if not all could well be used in a game but as outlined before 'use wenn needed'

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #13 - Posted 2006-06-26 13:51:22 »

So how are each of you letting the GameObjects have access to their GameWorld?  I changed to having a global static GameWorld reference because I'm sick of having to pass around GameWorld references to all GameObjects.  Having a centralised GameWorld seems to make sense.

This is the typical singleton argument: "But I really do need this everywhere! I can't be bothered passing it around all the time!". It's also usually wrong.

Firstly (as with the sound engine example) you don't actually want to use the object everywhere, you just think you do. Start passing it around and you should find that it doesn't need to be shared quite as much as you think. If your code is using it everywhere then your code needs refactoring. Typically you'll find yourself missing a few interfaces to decouple the modules. Or your code from one module is reaching out and tinkering with another module it should be, and instead you need a proper delagation/event/something in between. For my game object-y stuff they tend to "do stuff until finished", at which point the owner (which might be the level itself) removes then and tidies up - this way you never need to know about the owner explicitly. Taking the time to rework your code without the singletons and globals almost always results in better quality code overall - but you have to be willing to give it a try to actually see the results yourself.

The final little trick I like is the 'environment' struct. Instead of having long argument lists you can wrap common ex-singletons in a small class with them as public members. Eg. you might have a GameEnvironment which has your current level, hud, player settings, etc. which makes it obvious that certain bits of the code require a specific environment to operate in.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline purpleguitar

Junior Member





« Reply #14 - Posted 2006-06-26 14:14:22 »

The final little trick I like is the 'environment' struct. Instead of having long argument lists you can wrap common ex-singletons in a small class with them as public members. Eg. you might have a GameEnvironment which has your current level, hud, player settings, etc. which makes it obvious that certain bits of the code require a specific environment to operate in.

I didn't want to hijack the thread to defend my use of Singleton for a sound system, or Singletons themselves, but you must appreciate the irony that you're encouraging the use of public members here, perhaps the most egregious way to inject procedural thinking into an OO system.  Think of the children!
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #15 - Posted 2006-06-26 14:22:22 »

Pragmatic programming says that any fixed rule like "Singletons are Stupid" is probably wrong Wink. If it works for your situation - then great - if proved to be a problem just refactor it out - and thats where singletons are useful (well sorta not these days with modern IDESs):
Now you're just nitpicking, Wink we all know Never is Never Never. But while singletons may be valid sometimes, they're much overused and cause lots of problems of there own (which is basically what the last bit of "singleton considered stupid" says). Theres a whole world of difference between "singletons are great, use them for your game world" and "use them very, very carefully". Things like changing access levels are a symptom of the problem - yes you can just about work around things, but in the end you're just making things harder for youself when you really didn't need to.

Quote
Note: I'm not "for" singletons - I just think the main problem with designs most of the time is that people sit there worrying about what "rules" there are, and which "patterns" they can abuse - instead of just thinking, what works here. Stick the patterns in your head - and they'll just sort of pop up when needed Smiley
I agree, which is why "just create one" (despite the pattern-alike name) is so good. You don't worry about patterns, you don't fret about whether you do need to enforce one instance, you just create one object and use it. It might not be fancy, but it'll work. And it'll be easier to change in the future.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline purpleguitar

Junior Member





« Reply #16 - Posted 2006-06-26 14:23:32 »


use a static global reference/singleton, ie Main.getGameWorld();
give every GameObject a reference to its GameWorld in the constructor, ie new GameObject(gameWorld);
pass the GameWorld reference as a method parameter like: gameObject.update(gameWorld);


A few observations:

+ If you use a factory class (not a pattern per se, but a powerful idiom for abstracting object creation), then you can easily change your design later without modifying your clients.  As long as you factory has a reference to the (current) game world, then you can easily switch between #2 above and the swing-style approach mentioned elsewhere.

+ If you have a large number of very similar objects, consider the #3 above (send the object as a parameter).  If you discover that managing the large number of objects is a bottleneck, then you can easily refactor to a Flyweight.  A good example is the cell renderer in Swing's table or list API: rather than have a separate renderer for each table cell, one (or few) renderers are shared among cells, and each takes the cell as a parameter when drawing.

+ "Premature optimization is the root of all evil."
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #17 - Posted 2006-06-26 14:26:28 »

The final little trick I like is the 'environment' struct. Instead of having long argument lists you can wrap common ex-singletons in a small class with them as public members. Eg. you might have a GameEnvironment which has your current level, hud, player settings, etc. which makes it obvious that certain bits of the code require a specific environment to operate in.

I didn't want to hijack the thread to defend my use of Singleton for a sound system, or Singletons themselves, but you must appreciate the irony that you're encouraging the use of public members here, perhaps the most egregious way to inject procedural thinking into an OO system.  Think of the children!

I don't see the problem - we're only talking about a little mini struct here, it's not bolted on to an existing class but exists on its own with no operations at all, it's almost a value class. You can do without it if you want, as it's mostly syntactic sugar in a language where long parameter lists can get unweildy. Theres nothing procedural about it.

Although I feel we're getting off topic somewhat now...

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline CommanderKeith
« Reply #18 - Posted 2006-06-26 16:27:10 »

Great discussion here, I'm going to miss Australia v Italy while typing this.   Shocked

Start passing it [GameWorld] around and you should find that it doesn't need to be shared quite as much as you think. If your code is using it everywhere then your code needs refactoring.

Do you really interact with the whole Gameworld? or is it part of the gameworld? I don't think it's as much defining global var beeing as bad, and defining states 'globaly' well in a sence that you should evaluate if the state or stuff your sticking in gameworld is really that global/genetric should the scope perhaps be smaller.

Good points - OO programming says a Shoe has as its members a ShoeLace and an Owner, but the shoe need not have the Universe.  (That's kind of like the Swing getParent() tree approach I suppose).

That strict OO design which I'm going to call the need-to-know approach is elegant & the GameEngine package of classes/interfaces shoud definitely abide by this simple pattern since the GameEngine has code you want to re-use. 

But back to Kev's point about how game object code is rarely re-used, for the actual game code which is built on top of the GameEngine, having a global GameWorld that can be accessed by any GameObject is a massive plus for flexibility when dreaming up the game logic/objects.  But everything within the GameWorld should not be able to reach out of the GameWorld to reference the GameEngine (in keeping with the need-to-know idea).

So when the scope of the game has been defined (ie a 2D platformer & not a MMOG  Smiley) and the GameEngine bones are coded, scrap any thought about elegance and just code away since the game logic/objects are not going to get any deeper, there isn't any need for extensibility.  I think that's what I'll do - no globals/singletons for the GameEngine package, but definitely a global GameWorld for all of the GameObjects to access.

+ "Premature optimization is the root of all evil."

I need to scratch that into my screen.

Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #19 - Posted 2006-06-26 16:54:58 »

Quote
Now you're just nitpicking, Wink we all know Never is Never Never.

Sorry if it came off that way, I was simply hoping to give some constrast to another "Singletons" are bad discussion. Personally, I seem nothing wrong with using them where your talking about utlities (SoundSystem seems reasonably to me for instance) - I find their contemptable when used as part of the actual model - i.e. the bit you're modelling on your game's environement.

Quote
use a static global reference/singleton, ie Main.getGameWorld();
give every GameObject a reference to its GameWorld in the constructor, ie new GameObject(gameWorld);
pass the GameWorld reference as a method parameter like: gameObject.update(gameWorld);

I use the constructor, I consider it part of the object integretity - a GameObject cannot exist anywhere outside of the GameWorld - to enforce this you can't create one without a GameWorld.

Although in my case you need place the name "GameWorld" with the "Map" which is facet of the game world. As Mr_Light mentions - I like to keep what my game objects can access controlled so they only need to access parts of whats in the game world.

In the past I've used the term "GameObjectContext" where the constructor of the abstract super class of all game objects looks like:

1  
public GameObject(GameObjectContext context);


And where GameObjectContext is an interface that is implemented by GameWorld and gets added to as I discover the GameObject's need more facilities.

Worked for me at least Smiley

Kev

Offline f.l.x

Senior Member


Projects: 3


there is no place like 127.0.0.1


« Reply #20 - Posted 2006-06-26 17:02:55 »

even risking myself into premature optimization... isn't refering methods of an interface slower than refering them from a class?

Litterarum radices amaras, fructus dulces
http://flx.proyectoanonimo.com
figth spam!
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #21 - Posted 2006-06-26 17:11:10 »

I know there used to be a penalty back in 1.3 days that people used to worry about just because of the Java is Slow mentaility - i.e. compound factor.  I'm not sure any more with recent VMs, there was work going on to reduce/fix the issue, I'm sure Jeff could tell you. However, the penalty for using an interface isn't going to be so big that I'd stop using where they're appropriate to gain flexibility through decoupling.

Of course - it's your decision to make each and every time you consider using one Smiley

Kev

Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #22 - Posted 2006-06-26 18:27:01 »

In the past I've used the term "GameObjectContext" where the constructor of the abstract super class of all game objects looks like:

1  
public GameObject(GameObjectContext context);


And where GameObjectContext is an interface that is implemented by GameWorld and gets added to as I discover the GameObject's need more facilities.

That sounds like a good way of doing things (although I often pass the world down to the objects, often it's just a raw object, not via an interface). It'd also mean you could use a MockGameWorld which would allow you to test interactions between game objects much better. Grin

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline endolf

JGO Knight


Medals: 7
Projects: 1


Current project release date: sometime in 3003


« Reply #23 - Posted 2006-06-26 20:19:13 »

By passing the game world into the constructor you could use dependency injection and not worry about passing it in directly, using something like spring you can have 1 instance of the game world within the system without it being a jvm wide singleton. (probably not so usefull for games where there is only one game in existance at a time).

Endolf

Offline CommanderKeith
« Reply #24 - Posted 2006-06-26 22:21:40 »

even risking myself into premature optimization... isn't refering methods of an interface slower than refering them from a class?

That's got something to do with virtual v non-virtual methods... the method called on a class that is Final or is not extended is optimised by the HotSpot compiler (a non-virtual method I think).  I'm not sure how smart the HotSpot compiler is though, if there's only one class that implements GameObjectContext then it may optimise that method...

Offline tortoise

Junior Member




<3 Shmups


« Reply #25 - Posted 2006-09-11 19:39:43 »

This is the typical singleton argument: "But I really do need this everywhere! I can't be bothered passing it around all the time!". It's also usually wrong.

That's not the point of a singleton.

Singleton is a perfectly valid and perfectly fine design pattern. But just like every other pattern, it's only appropriate in certain situations.

The real reason to use the singleton pattern is not to allow global access, but rather ensure only one instance of your object is ever created. My keyboard interface is a singleton. Why? My user will never have more than one keyboard attached to his computer! Ensuring only one keyboard object is ever created leads to much more robust and cleaner code.

Things don't get used so often as to obtain a name by accident. The singleton pattern is nothing to be afraid of.
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #26 - Posted 2006-09-11 21:36:42 »

Holy thread ressurection batman!

This is the typical singleton argument: "But I really do need this everywhere! I can't be bothered passing it around all the time!". It's also usually wrong.

That's not the point of a singleton.
I'm afraid you've completely missed my point. I never said that was the point of a singleton (although that is often their use).

Quote
The real reason to use the singleton pattern is not to allow global access, but rather ensure only one instance of your object is ever created.
No, the requirements for a singleton are both - when you want to enforce a single instance, and allow global access to it. Only when you have both should a singleton be considered. Most uses of a singleton fall under only one (many don't need either).

Quote
My keyboard interface is a singleton. Why? My user will never have more than one keyboard attached to his computer!
Thats a fantastically short-sighted view. But I've already addressed this with my second post in this thread.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Mr_Light

Senior Member




shiny.


« Reply #27 - Posted 2006-09-13 00:37:17 »

Holy thread ressurection batman!
Return of the living death, euh thread, death thread!

although I'm in the "If it works for your situation - then great - if proved to be a problem just refactor it out" (as kevglass put in) zen type of things

weighing the whole accessed everywhere is interesting I need to let it sturr in my head for a bit.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline lukemasters

Junior Newbie





« Reply #28 - Posted 2006-11-28 22:52:29 »

Hi All,

I think this is a very interesting subject. The funny thing is, and personally I don’t understand why it’s like that, people seem not to consider video games has software projects. People are reluctant to apply Software Engineering practices to video game development. When I see video game project, I rarely see any UML or architectural documents.

In my opinion, video games should be considered has software, granted a special kind of software but software none the less. People should view game development in a disciplined, systematic and reproducible way.

Using such techniques has Iterative process, Architectural design, design patterns, and refactoring (and much more). We should change video game development projects main quality attribute from performance to scalability, maintainability.

I think all software design pattern, and architectural patterns (MVC…), should be used in game development they’ve already made there mark in the software world, and can easily be applied to games. I would go even further by saying that there should be specific design patterns and refactoring dedicated to game development.

“Failing to plan is planning to fail”

I’m currently working on a project to help promote these ideas in video game development. When I’m ready, I will make more information available.

Thanks

Luc Trudeau
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #29 - Posted 2006-11-29 01:23:57 »

Wow! Never saw this thread before...

Regarding game objects and what kevglass was saying about GameObject needing a GameWorld instance, I found that an event driven system is rather nice when it comes to handling game data messaging. The GameWorld would in fact be a GameObjectNode and it would have certain listeners for specific events, so in this case, GameWorld would not be a singleton but it would just be a normal object that other GameObjects might attach themselves to it and not directly reference (they could reference other GameObjectNodes for heirarchy business). Now what would happen in a case when the player shoots a bullet that hits a button that changes the gravity is this:

Bullet Fired Event -> ButtonGameObject recieves collision event -> custom code is run to fire a RequestGravityChange event -> The GameObjectNode would intercept the event and change the gravity accordingly by changing a field in GameObjectNode...

Localised Gravity anyone ? Grin

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (35 views)
2014-04-15 18:08:23

BurntPizza (31 views)
2014-04-15 03:46:01

UprightPath (46 views)
2014-04-14 17:39:50

UprightPath (29 views)
2014-04-14 17:35:47

Porlus (46 views)
2014-04-14 15:48:38

tom_mai78101 (67 views)
2014-04-10 04:04:31

BurntPizza (127 views)
2014-04-08 23:06:04

tom_mai78101 (227 views)
2014-04-05 13:34:39

trollwarrior1 (192 views)
2014-04-04 12:06:45

CJLetsGame (199 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!