On Wed, 28 Feb 2007 14:27:45 -0800 "Bob Ippolito" <[EMAIL PROTECTED]> wrote:
> On 2/28/07, Charles Joseph Christie II <[EMAIL PROTECTED]> wrote: > > On Wed, 28 Feb 2007 10:55:30 -0800 > > "Bob Ippolito" <[EMAIL PROTECTED]> wrote: > > > > > On 2/28/07, Kordova <[EMAIL PROTECTED]> 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.
