Re: [pygame] learning pygame: what to focus for a board game?

["Dave LeCompte (really)" <dave@xxxxxxxxxxxx>]

"massimo s." <devicerandom@xxxxxxxxx> wrote:
> Once a tile pops out from the random sample, I assume it will be showed,
> but the user will want to rotate it, often, before placing it in the
> board. What would be nice is to have the rotation not to be completely
> instantaneous, but to actually see the tile rotate somehow smoothly.

You might consider using OpenGL for the graphics - there are several
examples of OpenGL on PyGame, including recent posts in this mailing list.

OpenGL for 2D graphics might seem a little more work up front, but it
would mean that you can get rotation and scaling of your tile graphics
without much additional work.

One of the down sides is that a lot of lower-end machines have poor OpenGL
support. People with Linux machines probably have Mesa, a software
implementation of OpenGL, installed by default. I'm not sure what the
off-the-shelf experience is for Mac or Windows. A boardgame running at
10fps is probably perfectly acceptable - a game that doesn't play on
grandma's machine might not be.

>  > in other words, in most cases, using Sprite will help you simplify
> things.
>> For example, I haven't read the description for your board game, but if
>> you were making, say, chess,
>> you could have a sprite group containing all the pieces, then whenever
>> you needed to move a piece, you could use the collision methods to check
>> if it were moving onto another piece, and if so, delete that other
>> piece...
> Thank you. I'll have a look at sprites, then.

Hm, I certainly wouldn't write a chess game this way. I don't use sprites
in my projects, for reasons along the lines of Laura's MVC suggestions -
they seem to provide too tight a coupling between the view and the model.
In the case of chess, I'd have my own game board class (probably something
like an 8x8 array) and detect collisions there, rather than in screenspace
where the piece display happens. This would end up being easier down the
road if you wanted to provide alternate visuals (a 3d board, skinnable
graphics, different screen resolutions), or if you wanted to support
network play.

(Hm, another thought on this - I recently worked on a chess game where we
had 3D animated characters for the pieces. When a piece was taken, the
moving piece would have an attack animation and the target piece would
have a "die" animation, both of which would play as soon as the player
entered their move, long before the piece models came into contact.)


> I was wondering if wxpy integration was useful, but pygame wiki says
> it's BAD BAD BAD (and it has good reasons). PGU instead seems what I was
> looking for.

Well, that might be overstating it a touch. But I've liked what I've seen
of PGU - you could do worse than working with it.

But that does bring up another downside to OpenGL - UI toolkits are even
scarcer for OpenGL-upon-PyGame. They're not terribly hard to write, but
they're not that fun to write, either.


>> Some general advice, if you're new to game development:
>> get a gmail account, so that you can register your project with google
>> code.
>> This will provide you with an online SVN server.
>> Then get TortoiseSVN if you're on Windows (if you're on Linux or Mac I
>> assume you already have a subversion client.)
>> then, register for a www.blogger.com blog (affiliated with Google)
>> and you can keep a log of your progress on it.
>> Get a photobucket or imageshack account so you can upload game
>> screenshots
>> easily for inclusion on your blog.
>
> The blog idea is cool; I already have gmail accounts so I guess I can
> use the one I'm mailing you from. I've seen a lot of people moving on
> google code. I was accustomed to the old idea that SourceForge was THE
> place for free software projects. I'd love to know why google code is
> better than sourceforge.
>
> I will surely use svn, anyway.

Using an external SVN server (e.g. Google code) has the benefit of giving
you a remote location where your code "lives", which is good in case
something bad happens at home (a power surge fries your development
machine, or worse). It's even better if you're planning on collaborating
with other people, especially if they're distributed around the planet.

I run a SVN server for my projects in my own home - my bandwidth to the
outside net isn't as good as I'd like, and I don't tend to have other
people working with me on the code. A good lightning strike could take out
a bunch of work, but I'm OK with that risk right now.


Good luck with your project!
-Dave LeCompte