Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 2 down vote favorite

I have in my model, a list of Classes : Player, NonPlayerCharacter, Monster, Item, NonMovableItem etc

With AndEngine I've a list of sprite for each piece of my model,

How can I manage the relashionship between my model's classes and the graphical elements, what is the degree of abstaction recommended for my problem?

One sprite for one Model or one Model for one Sprite or n for n

for exemple If I do drag&drop have I to make abstraction of the Sprite Class, another exemple a map is a List of sprite or a list of element of my model?

share|improve this question

1 Answer

up vote 1 down vote

The Model (collectively) is the actual state of the world. There is one true world state; there can never really be more than one. So yes, use one model which consists of one sub-model for each unique element in the world.

In the real world, the "model" or state for your backyard might state that there are 7 puppies there; no more, and no less -- there is no ambiguity, because there is only one true "state" of your backyard (ignoring quantum mechanics :)

Views are representations of the world. A thing can be represented in an infinity of different ways. For instance, your puppies might be represented by nametags which give them each a unique name; they can be represented by photographs of each individual puppy; they could be represented each by their own unique DNA (as an alphanumeric string); or each puppy could even have a unique theme tune associated with it. So you see there are countless means of representation; as many, in fact, as you care to dream up.

A good example of using multiple views for the same part of a model, in a game, is the main world viewport vs. the minimap which many games have. In a minimap, each entity is represented as a small icon (Elder Scrolls) or even a pixel of a particular colour (StarCraft), whereas in the world view they might be 3D models or full sized, animated 2D sprites.

So the number of "views" is determined by looking at how many ways a particular thing needs to be represented, within the bounds of your design. But the relationship between model and view is always 1:n, where n can theoretically be anything from 0 to infinity.

Feedback from sprite to associated model

This is usually done through a publish/subscribe model, commonly found as event dispatcher / listener pairs. So when the sprite view object is moused over, clicked or whatever the case may be, it will dispatch an event which will trigger some update in the game logic -- which thus affects the model.

But if you wish to keep things simple, and bend the rules of MVC a bit, you can just give the view a direct reference back to the model. That's not good encapsulation, but it is much simpler / more direct to set up.

share|improve this answer
ok but the user's interactions are done through the sprite, so I need to determinate the model by his view so is there a good way to attach them together? – Christophe Debove Nov 5 '12 at 19:53
@ChristopheDebove: So the sprite has to have a way to get back to the original model it represents, yes? There are many ways to do this, the most simple (and some would say, incorrect) way to do this is to let the sprite hold a reference back to its model. I do not consider simple to be incorrect. I consider it to be simple, and thus useful. Another way (eg. in JS) is to just have the onclick handler call some outside function to say what should be done when that particular sprite is selected. In the long run, this provides somewhat better encapsulation so that the sprite can't access model. – Nick Wiggill Nov 5 '12 at 19:56
so it's not a composition by the strict term but only an association through the reference, a little bit like when we send the Context reference to a button(with Android). – Christophe Debove Nov 5 '12 at 19:59
@ChristopheDebove: Yep. The issue is that you can come up with all the fancy indirection you like, "to prevent the view accessing/changing the model", and some people are sticklers for this kind of architecture, BUT if it doesn't help you in the long run there is no point. And for many it doesn't help, because you're solo (right?) and so you're never going to need to worry about other people coming in to maintain that code. So better to just keep it simple. If you get massive funding one day, and a huge dev team, then you can afford to change it, right? :) – Nick Wiggill Nov 5 '12 at 20:00
@ChristopheDebove: But if you really want to do this kind of indirection, it will pretty much always take the form of the publish/subscribe model, i.e signals or event dispatchers / listener callbacks. – Nick Wiggill Nov 5 '12 at 20:03
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.