Seperating logic / view
I am making a small test game with robotlegs to get to know the
framework and the MVC concept a bit more in-depth. The game is a
simple drop 'n catch game, objects fall from the top and at the
bottom the player has to 'catch' them.
I have a model that keeps track of the objects. These objects are
derived of the Sprite class. When the model is 'told' to create a
new falling object, it adds it to an internal list and sends a
system event so that the view can add it to the display list.
Here is my dilemma:
The objects that fall are actually part of the view, because they
are visible but their data, for instance the y position is part of
the model.
Storing all the objects that are active in the model and then loop through them on each cycle to set there y value works and is the easiest way. But it feels like I am contaminating my model with views.
Could someone reflect on this shortly? How could I make a better separation of view (falling objects) and their data, like position. I hope this is a clear question.
Much appreciated,
Jiri
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Jonny Reeves on May 06, 2010 @ 04:06 PM
Hi Jiri,
If you are concerned about mixing your View and Model logic then why not create a simple Value Object (or, indeed a Point object) which contains the required x, y value of each 'falling object'. You could then update the view based on the values inside this Value object and visa/versa.
TBH tho, I wouldn't have any problem with keeping track of the View objects in a model.
2 Posted by jiri on May 06, 2010 @ 07:08 PM
He Jonny,
Thanks for your reply.
If I understand correctly for each update cycle,i.e each y increment I would then notify a 'falling object' that its vo is updated and thus reflect the changes by updating the actual Sprite instance.
The model would loop thourgh its vo's and reset the values of the vo. How do I then communicate this change to the actual sprite. Does each sprite keep a mediator?
They way I have it now, I have a single view / mediator. With this set up it would mean a double loop. The first being inside the model, updating the VO's, the second is the view that needs to find out which Sprite the vo that has been updated belongs to.
I could use eventListeners on the VO's, but in my understanding VO's should not hold state and should be used to send data from one place to another...
hmmm...I guess my initial idea is the easiest, but I am happy to hear some other suggestions. Maybe I am missing something(s)
Much appreciated,
Jiri