Sign in to follow this  
Maxamor

MVC, Object construction, help!

Recommended Posts

Maxamor    361
I've been working on separating my game objects from their views. I am confused as to what role the controller plays or how it exists as an object. Say I have a model, "ZombieData" and a view "ZombieView". My "game world" is the controller which glues these two things together -- right? If that is true, where does the logic specific to a Zombie live? Within the ZombieData object or somewhere else? Does this mean the model is more than just the state or "data" part of the Zombie? If that is true, how do I go about constructing both of these objects in parallel? Is there a generic way of going about it? I feel like I'm really close to getting this right, can anyone point me in the right direction?

Share this post


Link to post
Share on other sites
Kylotan    9872
The 'proper', or at least original definition of a controller in the model-view-controller paradigm is that the controller takes the user's input and modifies the model. This is then reflected in the view. A graphical component would therefore be a controller/view pair, and this pair could vary independently of the model that represented the actual data.

Confusion sets in because MVC is/was not a generic design pattern, but actually a GUI design pattern, and the View is specifically how to present the item to the user and the Controller is specifically a user's input method. Often people try and apply MVC to applications that aren't simply GUI apps, and therefore the system doesn't apply quite so cleanly: who is the user entering input on behalf of that zombie?

In the spirit of the original MVC, I'd say that the controller for a zombie is the artificial intelligence. It's the external process that sends input to the zombie model, which is later reflected by the zombie's view.

When the game world creates a zombie, it should therefore need to create a ZombieController object of some sort, and associate it with your ZombieData. Periodically (ie. each update tick, or whatever), you tell the ZombieController to update. That will presumably collect whatever information it needs from the world, and make modifications to ZombieData as it sees fit.

Is there much benefit to this method? On one hand, it's possibly a bit contrived to separate the ZombieController from the ZombieData, as obviously the controller must depend extensively on the ZombieData to do anything useful. On the other hand, you could experiment with swapping out different ZombieControllers, perhaps with different AI models, and have them operate on the same generic ZombieData quite easily. You could even swap in a controller that takes mouse/keyboard input and lets a player move the zombie.

Share this post


Link to post
Share on other sites
kirkd    505
I don't want to hijack the thread, but I've approached this problem in a similar way to that described by Kylotan. In my case it was a very simple PacMan simulation. I know - sledgehammer, fly, etc. Anywho, the purpose was to apply MVC to a simple scenario.

Essentially I have an MVC triad for each character. Just as Kylotan says, the controller takes any input, feed it to the model, and tells the view when to draw.

The problem I ran into was when I started integrating all of these MVC triads. PacMan, each ghost, power-ups, and fruit all have to have a place to be drawn and they all exist in a larger world - the maze. I ended up have a Maze (or World) MVC triad that essentially encapsulated all the rest. It has its own data - the maze walls, locations of the food pellets - and supplies the view to which all the characters draw. In turn, it then is the master drawing object that is copied to the screen.

Any thoughts on this hierarchical approach?

-Kirk

Share this post


Link to post
Share on other sites
Kylotan    9872
I think the main benefit of MVC is that it sort of breaks up the idea of having one monolithic composition hierarchy of 'objects' that supposedly manage everything about themselves, and instead an object becomes a reference to 3 aspects, its model, its view, and its controller. Each of those can be aggregated in whatever manner you need.

For example you might have the views in a scene graph so you only render what you need, you might have the controllers in a list so you update each one in turn once per frame, and you might have the models implicit in an SQL database which you modify attributes on as necessary.

The Pacman example sounds to me like a model-level hierarchy - objects in the world exist as part of other objects or within other objects. If you want to implement that as C++ composition, that's fine, just as long as you have a reasonable way to manage the lifetime of the associated views and controllers, and that's really getting down into memory-management minutiae.

I'd argue that the important thing about MVC is not how things are stored, but how things are NOT stored - view information is in a separate object to the controller information, which is a separate object again to the model information. This lets you vary them independently and keep the behaviour well partitioned and hopefully re-usable. How you choose to go about using the individual components is up to you.

Share this post


Link to post
Share on other sites
Maxamor    361
Thanks for the responses. This is all great stuff. If I were to set it up like this and have three components per game object, at construction time I imagine it would look something like this pseudocode:
ZombieData data;
ZombieController controller(data); // Reference
ZombieView view(data); // Const Reference
Both the view and the controller hold direct references to the data? I don't need to rout changes in the model through the controller to the view, right?

Where is the data created so that it doesn't get destroyed by going out of scope? Should I store it in a shared_ptr and pass that to the controller? Or should I just store it in another bucket in my game world (like the views and the controllers)?

Share this post


Link to post
Share on other sites
kirkd    505
Another question/scenario to add to Maxamor's list. I've done MVC in the past with non-game applications and it made much more sense. The reason being is that there was always one model, multiple views. For example, one set of tabular data and many different charts of that data. Even in my simple PacMan I ended up with multiple views and multiple models. It was the integration of the multiple models that led to the World object that was composed of the sub-MVC triads.

Is this multiple model scenario unnecessary or have I just over-complicated my system?

Share this post


Link to post
Share on other sites
stonemetal    288
http://www.codinghorror.com/blog/archives/001112.html

^^Behold MVC in all it's glory.^^

Model - a model isn't just the data it is the full representation of the object being modeled.

view - A view is a visual representation of its model.

Controller - Links the user to the model by controlling the view and sending input to the model.

as a diagram user <-view
^
|
user->controller<->model
Edit:
It doesn't seem to like my spacing that arrow should be pointing at the view. from the controller.

Share this post


Link to post
Share on other sites
Maxamor    361
Quote:
Original post by stonemetal
...
Model - a model isn't just the data it is the full representation of the object being modeled.
...

So in this case the model (my "ZombieData" object) has both the state information and the AI logic -- right? The only thing the controller (my game world) offers is interaction between the user and this model. Am I following?

EDIT: Also, does it make sense to have an instance of a view per instance of a data object? If the view can determine what the data should look like at any point in time wouldn't only one view instance be required?

Share this post


Link to post
Share on other sites
kirkd    505
In my opinion, I wouldn't mix the AI logic into the model object. Your ZombieData object would have only information specific to describe the zombie - location, state, orientation, health, weapons, etc. The AI logic would go either in the controller, or you might have a ZombieBrain object that accesses the ZombieData and other data as necessary, performs some calculations, and then modifies the ZombieData as a result of the AI decisions. I would call it from the ZombieController in a normal update loop.

-Kirk

Share this post


Link to post
Share on other sites
Maxamor    361
I'm leaning toward doing that myself. I will implement a test of having a "triad" per game object and see how it goes. Thanks for the ideas.

Share this post


Link to post
Share on other sites
Shakedown    230
Quote:

So in this case the model (my "ZombieData" object) has both the state information and the AI logic -- right?


Another way to do it:

No. The AI logic is simply another type of a View. Your models should contain only the necessary data (state information) for them to function. AI logic is not necessary data.

Your Views are what control the Models.

Your AI logic is just another type of a View.

You will have a single HumanView (per computer) that contains ALL the code necessary to represent its Model (graphics, sound, etc). The HumanView will control its Model by reading input which is handled by a Controller.

You will have A LOT of AIViews - AIGruntView, AIEliteView, AIMasterChiefView. Each AIView will not have any of the graphics, sound, etc. code that the HumanView has because an NPC doesn't need these things. The AIView will only contain the code that controls its Model. This code will be different for every type of enemy you want.

Also, you don't need a different AIView for every enemy type in your game. If you have an AISystem, you could handle this differently - there's no one way to do it. Although, if you don't want to build an AISystem it's easiest to create a different AIView for each type of enemy in your game.

Share this post


Link to post
Share on other sites
Farraj    152
I was looking for examples on the MVC a few months back were I found this:

http://www.gamasutra.com/view/feature/2280/the_guerrilla_guide_to_game_code.php

It's very interesting.

The thing I liked the most was making a base controller for the model then creating a different controllers that are derived from it.

For example: You would make a Zombie controller (ZombieController)that has the minimum control over your Zombie. Then, you make a Player Controller (PlayerZombieController) and an A.I. controller (AIZombieController) that are inherented ZombieController.

Also, the idea of changing the 'Controller' in mid-play was a good one too. For example: your Player Character has a 'SoldierController' and when you try to use a mounted gun the controller changes to the 'MounetdGunController' :)

Very interesting indeed.

Share this post


Link to post
Share on other sites
Kylotan    9872
Quote:
Original post by Maxamor
Thanks for the responses. This is all great stuff. If I were to set it up like this and have three components per game object, at construction time I imagine it would look something like this pseudocode:
ZombieData data;
ZombieController controller(data); // Reference
ZombieView view(data); // Const Reference
Both the view and the controller hold direct references to the data? I don't need to rout changes in the model through the controller to the view, right?


Given the original definition of MVC that I cited, that is correct. Unfortunately, as you will have seen elsewhere in this thread, not everybody goes by the same definition, which adds a lot of confusion.

Quote:
Where is the data created so that it doesn't get destroyed by going out of scope? Should I store it in a shared_ptr and pass that to the controller? Or should I just store it in another bucket in my game world (like the views and the controllers)?


Wherever you like. That consideration is outside the scope of the problem MVC is trying to solve. But the important thing is that the Model 'is' the item in question. The controller and view depend on it. It's not part of the controller or owned by it. The model is conceptually part of your game world.

Quote:
Original post by kirkd
I've done MVC in the past with non-game applications and it made much more sense. The reason being is that there was always one model, multiple views. For example, one set of tabular data and many different charts of that data.


Yep, exactly. It fits well with the typical scenario of a business storing important information in an SQL database and presenting it via a web page or a simple client app.

Quote:
Even in my simple PacMan I ended up with multiple views and multiple models. It was the integration of the multiple models that led to the World object that was composed of the sub-MVC triads.

Is this multiple model scenario unnecessary or have I just over-complicated my system?


You're perhaps confusing the MVC paradigm for a design pattern. On the micro-level - ie. where all the examples are, unfortunately - you have 1 class for the Model, 1 for the View, one for the Controller. But that is really just to demonstrate the concept. MVC isn't really supposed to dictate the class structure you have, more the logical structure. Your various items that make up the world are 'The Model', the various classes that allow you to render them on a screen are 'The View', and so on. In any non-trivial system, each of the 3 parts will consist of many classes, and how you choose to arrange those is a sub-problem in itself.

In a very homogeneous system, you may get away with 1 of each class for each item, such as in the original idea of using MVC for GUI widgets. But the problem you are trying to solve is so different to that original problem that trying to be rigid about it instead of following the 'essence' is going to do more harm than good.

Quote:
Original post by Maxamor
Quote:
Original post by stonemetal
...
Model - a model isn't just the data it is the full representation of the object being modeled.
...

So in this case the model (my "ZombieData" object) has both the state information and the AI logic -- right? The only thing the controller (my game world) offers is interaction between the user and this model.


Where to split the logic depends on your design really. Is a certain behaviour or function intrinsic to Zombies? If so, it's part of the model. Or is it only intrinsic to how it is being controlled or manipulated? If so, it's part of the controller.

Quote:
EDIT: Also, does it make sense to have an instance of a view per instance of a data object? If the view can determine what the data should look like at any point in time wouldn't only one view instance be required?


Depends on the system. As I mentioned above to KirkD, MVC is not about prescribing classes, it's about prescribing divisions. The important thing is that the view system asks the model system what needs to be presented, and then does it. The number of classes you use to achieve that is up to you.

Quote:
Original post by Shakedown
Quote:

So in this case the model (my "ZombieData" object) has both the state information and the AI logic -- right?


Another way to do it:

No. The AI logic is simply another type of a View. Your models should contain only the necessary data (state information) for them to function. AI logic is not necessary data.

Your Views are what control the Models.


Without criticising the design itself, that's not how MVC works. Views are for presenting models, and that's it. The Controller controls the Model, hence the name.

Share this post


Link to post
Share on other sites
kirkd    505
Excellent discussion, and thanks millions to Kylotan - excellent explanation! Also, thank you Maxamor for letting me participate in asking questions. I hate it when someone tries to hijack a thread and I hope I'm not doing that here.

Under the assumption that I'm not hijacking anything, back to my PacMan design:

As I mentioned I have an MVC triad for each element of my game.

PacMan's model stores his state (direction or orientation), and his position; his view stores his bitmap and the code to draw it to a surface; and his controller takes keyboard input from an Input object, updates the model, and waits for the World to initiate a draw update. Ghost and Power-Up MVCs are similar.

At a higher level, the World Model is composed of PacMan, Ghost, and Power-Up models as well as the maze and dot maps. The World View holds the primary surface to which everything is drawn on each update. The World Controller essentially serves as the main target of the overall game loop. When an update is required, the World Controller updates all of the individual elements in the appropriate order and initiates drawing from each individual view onto the primary view in the World View in the proper priority order.

I'm fully open to any criticisms of this type of design.

-Kirk

Share this post


Link to post
Share on other sites
Maxamor    361
kirkd, I am planning on doing the same thing. I hope to have a demo together soon so I can try this out.

Another idea I had was to have an interface for each of the three components. Not for the purpose of mixing and matching controllers with models and views, etc. But for the purpose of returning a pointer from a factory. That way my world will only need to know about the interface and not every type of model, view, and controller. Is there any downside to doing it that way?

Share this post


Link to post
Share on other sites
Shakedown    230
Quote:
Original post by Maxamor
kirkd, I am planning on doing the same thing. I hope to have a demo together soon so I can try this out.

Another idea I had was to have an interface for each of the three components. Not for the purpose of mixing and matching controllers with models and views, etc. But for the purpose of returning a pointer from a factory. That way my world will only need to know about the interface and not every type of model, view, and controller. Is there any downside to doing it that way?


No. That is exactly what you want to do. Design Principle: Program to an interface, not an implementation.

Share this post


Link to post
Share on other sites
pompoko    122
I don't want to hijack this thread, but I'm struggling with the same topic, MVC and Design Patterns, albeit not object creation itself. I work on implementing a C# / .NET version of Twilight Struggle as a learning exercise, a Board Game similar to Risk (http://www.boardgamegeek.com/game/12333).

Now I have problems with setting up a generic and abstract system for handling the game events and with creating an appropriate abstraction for the game entities, especially since C# comes with a vast array of possibilities for handling events with delegates etc..

An integral part of the game mechanic comes in the form of card driven events that affect countries and other entities.
For Example

"Sadat Expels Soviets - Eliminate all USSR Influence in Egypt and add one US Influence."

Without being too specific: Let's say this card is played, and as an effect, Egypt will turn under US Control since US Influence has reached a sufficient level.

How should I model game entities and how do these entities communicate with each other?

I thought of splitting up an Entity (IEntity, IEntityRepresentation, IEntityController) because of that Gamasutra article.

With the above example:

The Concrete Controller informs the Entity that it has to change the Influence Value for both USSR and USA accordingly. The Entity sets the Influence Values and changes one of its Ownership if the US has enough Influence. The Concrete Entity informs its Concrete Representation that it has to change its Ownership Texture.

Now how is this done in detail? At every Update() Egypt calls GetDesiredInfluenceUSSR(), GetDesiredInfluence(USA) from its Controller? Then, it calls its own SetOwnerShip()? I don't think this is efficient, how could I abstract this? How do C# events and delegates play into this, considering timing issues etc.? How is the TextureInformation passed to the Representation, I guess could implement some simple command pattern.

And again, how do entire game entities communicate with each other in the first place? How does the Egypt Controller communicate with the Sadat Controller...


Share this post


Link to post
Share on other sites
Kylotan    9872
Quote:
Original post by pompoko
Without being too specific: Let's say this card is played, and as an effect, Egypt will turn under US Control since US Influence has reached a sufficient level.

[...]

The Concrete Controller informs the Entity that it has to change the Influence Value for both USSR and USA accordingly. The Entity sets the Influence Values and changes one of its Ownership if the US has enough Influence. The Concrete Entity informs its Concrete Representation that it has to change its Ownership Texture.

Now how is this done in detail? At every Update() Egypt calls GetDesiredInfluenceUSSR(), GetDesiredInfluence(USA) from its Controller?


No, the controller pushes information to the model. It's the model that holds the state, and the controller supplies input. In this case, the controller looks at this card/event, works out which [part of the] model needs changing, and changes it. It can then either notify the [relevant part of the] view that the model has changed, or the view can work on a polling basis and will see this for itself when it next updates.

If all your events affect single entities, then the game can forward the event to an individual entity's controller to be handled. If your events more commonly affect multiple entities though, it might not be worth having individual controllers for each aspect of your game model, and instead just having a game controller which modifies the parts of the model which it sees fit.

Quote:
How do C# events and delegates play into this, considering timing issues etc.?


No idea. MVC predates C# by about 20 years so I wouldn't expect that the benefits C# give you would necessarily fit well with the benefits MVC attempts to give you. Perhaps someone more versed in C# can offer some concrete advice.

Quote:
How is the TextureInformation passed to the Representation, I guess could implement some simple command pattern.


Depends how you created it. It's not really MVC specific. Presumably you'd have some sort of system that creates these representations, and that would deduce what you need at the point of creation.

Quote:
And again, how do entire game entities communicate with each other in the first place? How does the Egypt Controller communicate with the Sadat Controller...


Any number of ways. They may send events between themselves, perhaps by hooking up signals/slots or your language's equivalent. They may not communicate at all, and instead whichever object owns them coordinates actions involving the two. MVC isn't particularly interested in how several controllers work together. It may be that you don't need an Egypt controller and a Sadat controller anyway.

Share this post


Link to post
Share on other sites
stonemetal    288
Quote:
Original post by pompoko
I don't want to hijack this thread, but I'm struggling with the same topic, MVC and Design Patterns, albeit not object creation itself. I work on implementing a C# / .NET version of Twilight Struggle as a learning exercise, a Board Game similar to Risk (http://www.boardgamegeek.com/game/12333).

Now I have problems with setting up a generic and abstract system for handling the game events and with creating an appropriate abstraction for the game entities, especially since C# comes with a vast array of possibilities for handling events with delegates etc..

An integral part of the game mechanic comes in the form of card driven events that affect countries and other entities.
For Example

"Sadat Expels Soviets - Eliminate all USSR Influence in Egypt and add one US Influence."

Without being too specific: Let's say this card is played, and as an effect, Egypt will turn under US Control since US Influence has reached a sufficient level.

How should I model game entities and how do these entities communicate with each other?

I thought of splitting up an Entity (IEntity, IEntityRepresentation, IEntityController) because of that Gamasutra article.

With the above example:

The Concrete Controller informs the Entity that it has to change the Influence Value for both USSR and USA accordingly. The Entity sets the Influence Values and changes one of its Ownership if the US has enough Influence. The Concrete Entity informs its Concrete Representation that it has to change its Ownership Texture.

Now how is this done in detail? At every Update() Egypt calls GetDesiredInfluenceUSSR(), GetDesiredInfluence(USA) from its Controller? Then, it calls its own SetOwnerShip()? I don't think this is efficient, how could I abstract this? How do C# events and delegates play into this, considering timing issues etc.? How is the TextureInformation passed to the Representation, I guess could implement some simple command pattern.

And again, how do entire game entities communicate with each other in the first place? How does the Egypt Controller communicate with the Sadat Controller...


Typically the player's controller just turns the player's input from low level pushed button, to higher level Player played card #7. The model should A validate the input(make sure the player has card #7, it is his turn, etc.), and B know what to do with it. The controller should not be randomly changing the model based on what it thinks should be done. The model is supposed to keep it self internally consistent. The model should never need to have an update loop. It should automatically update when a controller tells it to. The controllers in a real time game need an update loop,but if you are doing turn based game then there is no need for it since you are waiting on who's turn it is. A naive view could pole for updates from the model, but a better way is to use an event system where the view only updates on changes.

Maxamor sorry for not responding earlier but a the zombie model should know how to update its internal state by providing an interface to the controller such as zombie.walk(direction) zombie.attack(person) This way you can attach different controllers to a zombie to change his behavior(like the hard ai vs the easy ai) while still making sure he is responsible for his internal state.

To repeat the model is responsible for keeping world state not only does this mean it holds all the data, it also means that anything that updates the world data is apart of the model(how else can the model insure consistency). The controller is what drives those updates. The controller shouldn't manipulate the model's data directly, it should just inform the model in terms of high level actions.

Share this post


Link to post
Share on other sites
pompoko    122
I think I was profoundly confused by [url=http://www.gamasutra.com/features/20050414/rouwe_01.shtml]this[/url] gamasutra article, where the the Entity polls its EntityController:

Quote:
The role of the Controller is to specify what the Entity should do. The Controller can't directly change the state of the Entity. Every update the Controller is polled by the Entity and the Entity tries to follow the Controllers instructions.

For example, the Controller would never call a MoveTo() function on a Humanoid but instead the Humanoid would poll the Controller's GetDesiredSpeed() function and then try to reach this speed while performing collision detection to make sure not to clip through walls.





Share this post


Link to post
Share on other sites
stonemetal    288
Weather the controller says go that way every frame or the model asks where are we going every frame, doesn't really matter there should be just one update loop you can put it in the model if you like. I prefer(and from what I have read, historically it is organized but as has been pointed out MVC has gotten muddied over the years) the controller because to me it makes more sense that the model is controlled by the controller rather than the model taking the controller's advice when it feels like it.

Share this post


Link to post
Share on other sites
Kylotan    9872
Quote:
Original post by pompoko
I think I was profoundly confused by [url=http://www.gamasutra.com/features/20050414/rouwe_01.shtml]this[/url] gamasutra article, where the the Entity polls its EntityController:

Quote:
The role of the Controller is to specify what the Entity should do. The Controller can't directly change the state of the Entity. Every update the Controller is polled by the Entity and the Entity tries to follow the Controllers instructions.

For example, the Controller would never call a MoveTo() function on a Humanoid but instead the Humanoid would poll the Controller's GetDesiredSpeed() function and then try to reach this speed while performing collision detection to make sure not to clip through walls.


I think it's fair to say that the author is altering the definition of controller from the original definition, if he suggests the controller 'never' calls methods on the model. Usually that is entirely what the controller is there for. An alternative, which I would prefer, might have been for the controller to call 'SetDesiredSpeed' on the Model. But maybe there's some reason why the desired speed is not actually part of the model in that case. You have to decide what is right for your game.

Share this post


Link to post
Share on other sites
kirkd    505
Quote:
Original post by stonemetal
Maxamor sorry for not responding earlier but a the zombie model should know how to update its internal state by providing an interface to the controller such as zombie.walk(direction) zombie.attack(person) This way you can attach different controllers to a zombie to change his behavior(like the hard ai vs the easy ai) while still making sure he is responsible for his internal state.



Well stated. I support this idea 100%. Going back to the PacMan example, each characters controller has an AI object. The controller asks the AI what to do, and then conveys that information to the model (or the AI tells the model directly, I forget exactly). This has made it VERY easy for me to develop a KeyboardAI (player input from the keyboard), path following AI (used in the attract mode when PacMan is just running around or in an instant replay mode with a pre-recorded path), as well as multiple types of AI for the Ghosts.

Share this post


Link to post
Share on other sites
Maxamor    361
I appreciate the discussion, everyone. Keep it going.

I think I feel good about separating my objects and hiding them behind an interface. However, this adds another layer of complexity to how I construct them and get them "in" to my world.

For instance, if I create a factory which constructs my game objects I'm limited to being able to return only a single object. Should I construct my model, view, and controller and then wrap them into a single object to return from the factory?

Should I have separate factories for each of the components? If I used separate factories, and they are abstracted behind an interface how do I work out passing references to the concrete classes for the components to use?

For example:
If all objects are created in a single place, I can do it like I did in my earlier post:

ZombieModel model;
ZombieController controller(model);
ZombieView view(model);
This is all good and well, except for the fact that I need to return all three objects from my factory to my world. Do I need to wrap them up and explode them later?

If I use separate factories I end up with a scenario like this:
EntiyModel* zombieModel = ModelFactory.get("Zombie");
EntityController* zombieController = ControllerFactory.get("Zombie", zombieModel ); // Would I need to do a dynamic_cast on this internally or what?
EntityView* zombieView = ViewFactory.get("Zombie", zombieModel); // Same problem here.

world.addEntity(zombieModel, zombieView, zombieController); // This is made up, but could possibly work like this.
I'm afraid of something like this becoming very rigidt and bound to my class hierarchy.

Ideas?

Share this post


Link to post
Share on other sites
Kylotan    9872
Quote:
Original post by Maxamor
For instance, if I create a factory which constructs my game objects I'm limited to being able to return only a single object. Should I construct my model, view, and controller and then wrap them into a single object to return from the factory?

If you like. There are many ways to get an object to 'return' 3 other objects. Wrap them in a struct, put them in a list, call a 'build' function followed by 3 accessors, use a language that allows you to return 3 things from one function...

It's more important to think about the context in which they are to be used. Where are you going to store these things after you've created them?

Quote:
Should I have separate factories for each of the components? If I used separate factories, and they are abstracted behind an interface how do I work out passing references to the concrete classes for the components to use?


I get the feeling you're perhaps overengineering this in your head. Software design is there to serve the programmer, not the other way around. Do you even need factories? Do you need an abstract interface?
Quote:
ZombieModel model;
ZombieController controller(model);
ZombieView view(model);
This is all good and well, except for the fact that I need to return all three objects from my factory to my world. Do I need to wrap them up and explode them later?

void make_a_zombie(Game& my_game)
{
int id = my_game.get_unique_id();
my_game.add_model(id, new ZombieModel);
my_game.add_controller(id, new ZombieController);
my_game.add_view(id, new ZombieView);
}


Is that so bad? My advice is to get the basic system working first, and worry about refactoring and abstracting things out later. Maybe you'll have base classes for Model/View/Controller so you can add things other than zombies, and they may include the basic interface for controllers to alter models and for views to query models, and implement the way for one to communicate with the other, but keep it simple to begin with.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this