Re: [pygame] Game idea revised

[Charles Joseph Christie II <sonicbhoc@xxxxxxxxx>]

On Wed, 28 Feb 2007 14:27:45 -0800
"Bob Ippolito" <bob@xxxxxxxxxx> wrote:

> 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.
Bounding rect? you mean like something that surrounds an object and
tells if the two bounding rects touched? That's what I thought he meant
by pixel perfect detection. Oops. ^_^;;

> > 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.
>
Good point. Although it wouldn't be thousands of things. at the most a
hundred or two.

> > 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.
> 
someone was writing a python wrapper for it and then disappeared off of
the face of the planet <_<

I kinda don't have time for that, though.

> > 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...

Yeah, I know, which is why I am going for something a little simpler.

> 
> 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

I could finish a danmaku game. I couldn't, on the other hand, finish a
danmaku game by May. I could probably do what I'm thinking by May,
however. I think its simpler.