Re: [pygame] Game idea revised

["Bob Ippolito" <bob@xxxxxxxxxx>]

On 2/28/07, Charles Joseph Christie II <sonicbhoc@xxxxxxxxx> wrote:
> On Wed, 28 Feb 2007 10:55:30 -0800
> "Bob Ippolito" <bob@xxxxxxxxxx> wrote:
>
> > On 2/28/07, Kordova <kordova@xxxxxxxxx> wrote:
> > >
> > > On Feb 28, 2007, at 8:27 AM, Charles Christie wrote:
> > >
> > > > This idea seems more and more feasible, and better for pygame,
> > > > every time I think about it, and my previous idea of making a
> > > > danmaku shoot-em-up game out of this typing thing gets less savory
> > > > due to the speed and accuracy limitations of python (which isn't
> > > > exactly a bad thing, it's easy to program in for a newbie like
> > > > me).
> > >
> > > I do not know what danmaku is (actually thanks to google I think I
> > > now do), but I have had success at work and at home with intensive
> > > 3d applications written primarily in Python. If you feel you are
> > > able to develop this and are interested in doing so, you should try
> > > it. In my experience most complaints against Python tend to be
> > > based on poor design and/or implementation of algorithms rather
> > > than the language running dog slow. (And you can make the plunge
> > > into C extensions or whatever if it really becomes an issue.)
> > >
> >
> > Python having "accuracy limitations" seems very suspect as well. Where
> > the heck did that assertion come from?
> >
> > -bob
>
> A tutorial on the pygame website says that you shouldn't try to get
> pixel perfect hitrect detection. Wouldn't that mess with the game's
> accuracy?

That's a general rule of game programming; doing bounding rects or
circles is a LOT faster than comparing swaths of pixels. It's possible
to do it with pixels in pygame if you really want to, and I'm pretty
sure I've seen extensions that do exactly that. You still need to
design for bounding rect or distance based collision detection in
*any* environment even if doing pixel based collision in order to
decide which things are worth comparing.

> And the speed limitations thing comes from the fact that, well, I suck
> at coding. :P
>
> I read one tutorial that if you're making a fast paced game you
> shouldn't even bother with Python. Of course, I considered this BS, but
> I know that Python isn't as fast as C. That doesn't mean it's _slow_,
> though.

If you can do fast paced games in Flash (and you can), then you can do
it in pygame. I've seen an ikaruga clone in Flash, which sounds like
the kind of game you're thinking of. That said, you need to know what
you're doing in nearly any environment to get good performance when
you're managing hundreds or thousands of things many times a second.

> Didn't know you could use C extensions in Python. Is that like saying,
> if I have a library I like to use in C (in this case, Kenta
> Cho's awesome bulletml library) I can use it in python? How much
> hacking would that take?

pygame is a C extension. I don't know anything about bulletml, but you
might be able to use it relatively easily with something like ctypes
or swig. Otherwise you'd have to write code in C or Pyrex against the
Python API that gets what you want out of it.

> Other reasons I wanted to change the idea of my game is because...
>
> 1. Time limitations. It'd probably be easier to come up with a grid
> instead of 20 bullet patterns and program them all, but if I could use
> bulletml this wouldn't be nearly as much of a problem.
>
> 2. I never thought of doing it this way and someone else said it would
> be a good idea, and I agree with him now.
>
> 3. No need to change the game code for every keyboard layout. My
> typing danmaku game idea assumed everyone has a QWERTY keyboard.
>
> 4. I've never seen anyone else do this, while I've seen multiple
> shoot-em-up typing tutors (but none of them were danmaku and none of
> them were based on the Touhou games).
>
> 5. Well... uh... my typing danmaku game would make a good sequel. ;P
>
> I didn't mean to make it sound as if it's impossible to make a danmaku
> typing game in Python, but rather a newbie like myself would end up
> making code that is slow and inaccurate due to lack of information and
> (moreover) time.

None of these really seem terribly relevant to Python or pygame. You'd
have the same problems with just about anything...

Since it sounds like you're just starting out I would recommend doing
simpler games that you can actually finish instead of trying to make
your first or second project a masterpiece... but again, that's not
Python or pygame specific advice.

-bob