[Tutor] movement controls

[Luke Paireepinart]

On Fri, Mar 19, 2010 at 4:09 AM, <snet-1 at msn.com> wrote:

>  But yes, I'm not quite sure about what you mean. I guess you mean keep
> the character on the x plane <----> then for the jumping movements move the
> level? what do you mean by 'You should probably decouple the view from the
> model'
>
>
> and it's preferable not to use html when sending e-mails, 'cause your font
settings don't necessarily look good on other people's computers.

You should really be asking this on the Pygame list, and you probably still
should.

Having said that... I'll try to answer your question.

The way you're currently doing it, you have all of your sprites' coordinates
just stored in random variables, and you're calculating where they should be
on the screen and then drawing them directly, right?
In other words, if player.x = 100 and player.y = 200 then he is located at
100, 200 on the screen?

Having a view and a model relates to the MVC (model-view-controller)
paradigm in programming.

Basically think of it like this.

Suppose I have a window that I'm looking out, and my dog is outside running
around somewhere.  Now you walk by the window.  Does it make more sense for
me to model your interaction with my dog in relation to what I can see out
of my window, or should I model your interaction with the dog in a separate
space, independent of where I may be looking?

Say I want to describe your position to my friend who lives up and to the
right of me.  Would I say "see that guy by the bench petting my dog?" or
would I say "see the guy that is 12 meters forward and 1 meter to the right
of the center of my window?"  The friend doesn't have any idea what
perspective _I_ view the world from, and he really shouldn't have to.

SO in the MVC framework, you model your _world_ space and your VIEW is just
an outside observer "peeking" at the current state of the world.  So, for
example, say your world is a grid
of 1000 x 8000 units, and your character is located at 200x200.  There might
be an enemy moving around at 800x2000, who may not be on the screen, but I
still want to model that enemy moving around,
so that when the character gets over there, the enemy will be in a new
location.  Or maybe he'll walk over and be on the screen.

When you do it this way, you can merely say "render everything that is
around my player's current position" and then all your problems are solved.
The view will automatically follow the player, and when he jumps up, the
view will raise with him.  If you set an upper and lower limit, then the
view will naturally not move until the player moves past a certain point of
the screen.

If you continue to refer to the game objects in terms of their graphical
position in relation to the screen, it's going to get very convoluted.

In order to  "decouple your view from your model" you will likely have to
rewrite a lot of your code -- the key here is that you should've written it
this way (MVC) in the first place.

Read up more on MVC, and specifically how it relates to game design.

Also, when you reply,
use Reply to All
otherwise your reply is only seen by me, not by the other members on the
list.

Good luck,
-Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20100319/c46c2247/attachment.html>