It's heavily implied by the design approach that I'm not going to just allow any frame to start calling functions designed to load a map or initialize SDL or anything, just by convention of how the function-pointer list that the frames reference works. I imagine it will work well enough for the sidescroller I intend to use it with where there's not a whole lot of elegance in object management required.
Example being: "Object A tries to move in the direction of object B. Do whatever the function to move this object says to do. I don't care to sanity-check the results; the function will resolve that on its own. The end."
What's your preferred way of letting objects affect the game?
Really? All I can see is the many hundreds of ways this can crash and burn in a series of amusing ways... more so when you consider the follow up reply about not sanity checking the results...?
I can see this being a legitimate approach if and only if your game logic is heavily data-driven and validated by external tools prior to loading into the engine.
heh, I was vague on purpose as I felt the general idea was more important than the precise details ;)No offense meant but phantoms "clarification" was unfortunately lacking in "how" it works.
For the record I'd favour a hybrid of using scripts/graphs designed by a designer to drive things but allow that to push messages into the message system if needs be. (Such as wanting to kick a sound off and not want to directly tie the sound system into the scripting/graph system.)
What's your preferred way of letting various objects (units)
affect the game (by creating other units, buildings, projectiles,
hurting/healing other units, etc.)?
Directly. I've started in with component based entities, and letting isolated single responsibility components work directly against references (while ignoring what those references are, or how they are provided) is totally awesome. No event storms to hunt through, no message queues to interpret or parse, no bundles of void* or object to cast about.
Dependency resolution is done in one isolated place, and otherwise components go about their business: exposing functionality for other things to use/consume.
I'm curious about this. I understand what you're saying in terms of risk to SRP, but is a 'Game' class really necessarily a god class? If all of the components of 'Game' are properly abstracted it could be pretty simplistic, couldn't it?ApochPiQ, on 16 Feb 2013 - 19:25, said:
The key realization is that representing a "game" or "unit" or "building" might still be violating SRP.
Yes, on some level, those are "single" groups of responsibility. But they're really just God Classes of slightly more tame dimensions.
You made the point that representing an RPG character with a single class is inappropriate. Are you saying that a character instance should be represented by more than one object, such as dividing character state between components that deal with the character or do you just mean that the attributes of the character should be further abstracted?
I'm not sure I follow the question, honestly.
I think you should organize your code so that individual units of organization have a single, clearly defined area of responsibility. I also think that's extremely context-sensitive, as I said before, and what makes sense for a small design may utterly backfire in a larger one - and vice versa.
There are no 100% applicable rules that govern every single design situation. You have to learn how to solve the problem at hand.
I think you should organize your code so that individual units of organization have a single, clearly defined area of responsibility. I also think that's extremely context-sensitive, as I said before, and what makes sense for a small design may utterly backfire in a larger one - and vice versa.
There are no 100% applicable rules that govern every single design situation. You have to learn how to solve the problem at hand.
I'm just asking what you mean when you say classes like "game" or "unit" or "building" are mini-god classes.
My understanding of SRP is that a unit should do one thing and do it well. When I think of a 'Game' class I want to limit it to essentially being a container for the game's components that works like a composite for updating them. The Game class itself only holds the component system objects, of which there are few, and runs the main control loop, which simply updates the member objects in order. I consider this to be adhering to SRP. While it's true that nearly the entire program runs within the context of the Game class instance, the Game class itself is only performing one duty - playing host to the parts. What the parts themselves do I consider to be their own areas of responsibility, not that of 'Game'. Is this sensible?
Just interested in your point of view.
My understanding of SRP is that a unit should do one thing and do it well. When I think of a 'Game' class I want to limit it to essentially being a container for the game's components that works like a composite for updating them. The Game class itself only holds the component system objects, of which there are few, and runs the main control loop, which simply updates the member objects in order. I consider this to be adhering to SRP. While it's true that nearly the entire program runs within the context of the Game class instance, the Game class itself is only performing one duty - playing host to the parts. What the parts themselves do I consider to be their own areas of responsibility, not that of 'Game'. Is this sensible?
Just interested in your point of view.
I was referring to the OP. Nothing grand or sweeping. I don't mean to imply that any class called "Game" or "Unit" or "Building" is inherently bad, although it seems that's what you inferred, for which I apologize for my lack of clarity.
If you read through the rest of my posts in this thread, it should (I hope!) be abundantly clear that composing such a class from SRP-adherent constituents is perfectly fine with me.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
