Re: [pygame] I have a quick question... again...

[kschnee@xxxxxxxxxx]

On Sun, June 17, 2007 1:36 am, Greg Ewing wrote:
> Marius Gedminas wrote:
>
>> I never fully understood the "controller" part of it;
>>
>
> Me neither. I *think* in the original Smalltalk terminology,
> the view handled output and the controller handled input. But I find that
> input and output are usually so closely coupled that it's not worth having
> two separate objects, so I just talk about a View and a Model.


When I first heard of the Model/View/Controller programming style, I found
it very useful because my code was a tangled mess. Now... well, it's still
a tangled mess, but less so.

What I learned from it was to apply the general idea of separating the
game logic -- the code for tracking where objects are and what they can do
-- from the graphics and input systems. At first I tried following MVC
religiously and found it cumbersome to always do things that way, so the
happy medium seems to be applying the pattern only when it would simplify
things.

On a related note, I've been avoiding using Pygame's Sprite module because
it seems to violate the separation of view and model. Since collision
detection is based on the _pixel_ location of objects, that code doesn't
take into account that in a complex game there's likely to be scrolling or
other effects such that you shouldn't manipulating objects using data from
the way they're drawn. With my project for instance, you can (lack of
Z-ordering permitting!) walk "behind" a tree such that the sprites overlap
but the objects they represent don't.

Something I've worried about is how an AI character should fit into a
model/view pattern. What kind of data should a non-player character have
access to, represented how, and how should it send commands to the world?
As an extreme case, I released a Pygame thing called "Cubeland"
(<http://kschnee.xepher.net/code/070613cubeland.zip>) where the input
comes from outside the actual program!