[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



In a message of Sat, 16 Jun 2007 09:32:09 PDT, Casey Duncan writes:
>
>On Jun 16, 2007, at 8:56 AM, Laura Creighton wrote:
>[..]
>>
>> If you use Model-View-Controller like separation of your code,
>> None.  All your changes will be in the drawing.
>
>I'm curious how many of you actually employ MVC using pygame, since  
>the library encourages mixing the model and view via sprites. I'd be  
>interested to see a "canonical" example of a pygame that uses MVC.

me, as you might have suspected.

>MVC has strong advantages when you need to present and interact with  
>the same data in multiple ways, but often in simple games data is  
>only presented a single way. Using MVC has advantages for unit  
>testing as well, but how many pygames actually employ unit tests in a  
>meaningful way? Also, is unit testing something that the gaming  
>industry at large embraces?

Unit testing for game logic is something the game industry embraces.
For the graphics -- its a mess.

But I think for the commercial game industry the advantage of
using MVC is a lot more pragmatic than this -- it means you
can build yourself a game engine that is independent of the art.

Then you ship the art-making part out to some place that is different
from your engine making place.  And based on how much you were
willing to pay, you could get cooler art.  Gaming companies, as
recently as 10 years ago, were unwilling to decide how much
money to spend on art until they had an idea how the gameplay was.

These days, I think it's turned on its head.  The art is part of the 
marketting which is done before the game logic gets made.  But one still
tried to use whatever game engine one has around.

>I'm curious how widespread these practices really are in the pygame  
>community, not to make a point for or against them, but to better  
>understand theory vs. practice.


Computer games have always been the bleeding edge.  The faster, the
uglier, the harder the graphics boards come, there will be
games that use it.  And make money at it.  Which is why certain gaming-only
video board manufacturers live high and well.

But just because you can mix model and view with sprites, there is no
demand that you have to.  YOu can make polite sprites that do not mess with
the model expect through very sane APIs.  

But some games still have to be dirty.  However, you speak as if
the mixing of model and view is in some way 'natural' and that
splitting them will be hard.  Depends on your background, I guess.
For me, the hardest times are deciding when _I just cannot get
the speed I need any other way_ and then deciding where to 
break separation and make has out of things.

As machines get faster, though, I find I do it less and less.

But I am using pygame to make 3-dimentional models of things
in biology and chemistry mostly.  I rarely need to have to hunt
down my molecules and kill them. :-)

Laura

>-Casey