even risking myself into premature optimization… isn’t refering methods of an interface slower than refering them from a class?
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 
Kev
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. ;D
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
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…
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.
Holy thread ressurection batman!
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.
[/quote]
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!
[/quote]
Thats a fantastically short-sighted view. But I’ve already addressed this with my second post in this thread.
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.
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
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 ? ;D
[quote] 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.
[/quote]
In the real world a whole lot of stuff gets written without any UML or architecture documents, but I follow your point. I suspect if you look behind the scenes at somewhere like EA you would find a whole load of documentation that produces the solid and predictable sequels that all EA fans have come to know and love.
The problem with that is that if you have your plan and your UML doc and everything else and one of your engine guys comes in and says “hey check out this neat effect I’ve just found how to do” but it’s not in the architecture document or given it’s own corner of the UML then it’s out, regardless of how much it would add. In games writing more than pretty much any other area of software development you need a bit of room for sponteneity and that is something that Architecture-first development doesn’t allow for. My experience is that it’s actually too rigid for any non-trivial development task, but I have never worked for a Fortune 100 software company and it probably works great for them. My view would be that a more Agile approach would be better suited to game development, but then I’ve never worked for one of the major game development houses either so I have no idea whether or not that is what they are doing, that’s just what my programming experience suggests. I can imagine that a comprehensive test suite that you could apply on lots of different hardware and OS combinations would be a big help with the basic QA stuff so your testing team could work on the more sophisticated things.
Here’s a tip, never do this:
/**
* Adds a rule
*
* @param rule
*/
public void add(Rule rule)
{
int divisor = rule.ruleNumber % 2; //ruleNumber is final
if (rule == null) {
return;
}
else if (divisor == 0) {
maxEvenNumbers++;
super.addSibling(rule);
}
else {
maxOddNumbers++;
super.addChild(rule);
}
}
For what it’s worth, my limited experience shows that wise application of design patterns yields architectures that are more adaptable to change. After all, this is one of the major goals of patterns, and reusable code promotes agility. I think you’re looking at two different issues: the application of patterns early in the design process vs. laying down an immutable architecture during the design process.
@lukemasters: I’m curious about your experience. I observed the same phenomona (lack of good software engineering practices) through a survey of books on game programming, but I do not have much exposure to the commercial development world aside from books.
I’m no game development guru or software development guru. Nor do I have tons of years of experience in gaming. I’m also aware that companies like EA and Ubi might not used architecture or UML document.
But it’s not because they don’t do it, that we should not. I also am fully aware that a waterfall approach (Architecture-first development) is not adequate for games and software development projects to.
If my project works out, I want to promote an Iterative approach that put the emphasis on an evolutive design, architecture and patterns.
As for agile development, you must remember that Agile does not mean no design. On the contrary if an agile project is done they way it should be done, there should be UML and Architecture documents.
One of the main pitfalls to avoid is developing huge architecture documents. In my opinion architecture documents should be short and sweet.
UML and architectural documents are traditionally about communication.
over the years it has found it’s way into the process.
it’s diffuculd to express but the short sum of it is that design or documentation has little to do with processes as waterfall agile and that whole pile.
if design is written down or not doesn’t mean there’s no design anypiece of code is written by some design sure the perspective level and amount of overview differs, but design is there.
documentation is always there from a list of machine code to highlevel programming language to skeches on a paper. it all discribes the program and is thus documentation for human beeings not or hardly interpaterable doesn’t matter it is documentation(yes sure is (piss) poor documentation).
Working togetter is hard no matter what the common consensus is. Esp. in area’s without references, such as cutting edge and creative processes.
[quote]In the real world a whole lot of stuff gets written without any UML or architecture documents, but I follow your point.
[/quote]
heh, those must be doing the projects who bring the stats down in one of those carts of standardish group.
int divisor = rule.ruleNumber % 2; //ruleNumber is final
if (rule == null) {
return;
}
because your accessing an object and then you check for null?
[quote]The problem with that is that if you have your plan and your UML doc and everything else and one of your engine guys comes in and says “hey check out this neat effect I’ve just found how to do” but it’s not in the architecture document or given it’s own corner of the UML then it’s out, regardless of how much it would add.
[/quote]
the problem is in your decision making not in your uml part. next to that your achitecture probely isn’t an good achitecture to begin with, it’s should guide the program allow parts to work togetter and allowing parts to work if it restricts you from adding or using parts then your “achitecture” goes against everything it’s suppose to stand for.
[quote]the problem is in your decision making not in your uml part. next to that your achitecture probely isn’t an good achitecture to begin with, it’s should guide the program allow parts to work togetter and allowing parts to work if it restricts you from adding or using parts then your “achitecture” goes against everything it’s suppose to stand for.
[/quote]
Look into how games are written by the big companies. They put together a design document, give it to the development house and expect it to be matched exactly. That may not be how we want to imagine it works, but it is how it does work for the majority of professional game developers; here’s the document, here is your deadline; build it in time for the Christmas market. No leeway, no room for experimentation. One of the main reasons that when EA bought up Bullfrog a few years back (they were based just round the corner from me) pretty much all the Bullfrog developers, who had been used to a more creative environment, quit within a few months.
EA is wrong on so many levels ;D lets not start that subject.
A design document is not an achitectural document, thats more a manual or specification as to how your program should be put togetter. a software design document may comtain a chaper or probebly should contain a chapter on architecture but that describes how it fits in one, and usually that one is predefined in the achitectual documentation. We might have had a glitch in our communication there.
that a design document is Law and absolute, well there is nothing against that imo. Thats perfectly fine as it’s your nexus or medium for communication between programmers requirements engineers and the likes. If some programmer wants todo something differendly then the document should be changed and then he can follow up. This is the way it should go cause other programmer will be basing there parts on the document and you might get problems glue stuff togetter. Where the problem is that ‘the creative programmer’ in question is unable to change the document. Which can be because the process is wrong or that the process is based around that programmers don’t profide input. Although I’m pritty sure against the latter it can be justified depending on your view, but this is turns into policial mombo-jumbo quite quickly.
In games technical changes often also lead to changes outside technical consideration/implementations so it also has to go around another document(which everyone seems to name differendly)
anyways these process usually get slow esp in big(er) companies and is what the agile movement is out to cut down on. Some are not as transparent to apply in game development I gues as your typical user or usergroups even are difficuld to indentify. And theres the whole the-consumer-doesn’t-know-what-he-want-till-he-has-it part. Figuring out what the user want before he knows it probebly makes making games exciting.
It is pretty stupid of me eh? ;D
[quote]because your accessing an object and then you check for null?
[/quote]
will you trust me wenn I say that thats nothing? 
Huh? Not in the companies I’ve worked at. The developer writes teh design doc themselves, that’s what all those designers are on the payroll for :).