BulletControl.py Progress Thread

[Silver Skree]

I think programming counts as creative? There's no board for non-metroid indie game development, but feel free to move this as you see fit.

BulletControl.py Demo 1 (Flea's midboss patterns)

This is a bullet hell engine I'm writing in Python using the pygame library. Right now only the Bullet and BulletControl classes work; the Player object is up next on my agenda, and then we'll see about hitboxes. Enemies are going to be a fun pain in the ass.

Shoot the Bullet music? Why not. At this point, silent youtube videos are just disappointing.

[passarbye]

 :whoa: i want cheat codes. NAOW.

seriously though, i would save those patterns for bosses.
and of course they'll need to be balanced a bit because some of them look too fast.



looks very good though!  :grin:

[Katelyn]

Remind me to never play any of your games ever unless I want to gouge my brain out with a spoon.

[Zhs2]

Remind me to never play any Touhou ever unless I want to gouge my brain out with a spoon.

FTFY

[Silver Skree]

Haha. It should be noted that I write patterns for the top / second-top level difficulty first, and then tone them down for the easier difficulties. :P

This game's Hard is going to be about like Touhou's Normal, and there'll be no penalties aside from end-of-stage score multipliers for playing on Easy. Which is pretty much "No hand-eye coordination? No problem!"

Anyway, I've got my player class written now, and it's 'playable', but there's no interaction between player and bullets yet. So that means it's time for me to implement hitboxes. Whee.

EDIT:

reallyeasy.wmv
This is about what Easy will be like, for that last pattern.
I changed it a little more after posting the video so the bullets go a tad slower, but that's pretty much it.

[Quietus]

That video actually looks about right to me.  While I don't dislike the bullet hells (they appeal to certain people), I tend to find that it detracts you from enjoying what's actually going on.  I'd much rather have less bullets, and bosses with interesting and varied patterns / attacks.

[ProjectXVIII]

You and I certainly have incredibly different definitions of "really easy".

[Yuki]

looks great  skree. looks about right for an easy level pattern.

[Silver Skree]

You and I certainly have incredibly different definitions of "really easy".

You can bomb if you want to
You can leave the bullets behind
Cause the bullets don't hit
And if they don't hit
Well they're no bullets of mine.

[zephyrtronium]

I was going to comment on how ridiculously fast that is for Python+Pygame, but then I saw that you aren't doing any collision detection.

Also, the thing about bullet hell that appeals to me most is the patterns created by boss attacks, and the challenge of avoiding everything when four out of five pixels are death. Simple enemies just get in the way of the fun, if you ask me; I'd love bullet hell comprised solely of boss-style enemies.

[Silver Skree]

I'll be implementing a quadtree with edge case handling to minimize the amount of math done per bullet. No need to check for collision on bullets all the way over on the fukken other side of the screen. Also for efficiency, I now have a class of bullet (Bullet.simple) that does its trig calculation for angle/velocity to get its positioning for the next frame only once ever, and then stores the X and Y difference. From there, it just applies that same difference to its own position every frame. This disallows curvature or de/accelleration, but it saves a lot of power. I can have twice as many simple bullets on screen as I can regular bullets, with no lag, and around 8x as many off-screen, using the don't-kill-offscreen AI for each.

[zephyrtronium]

This makes me wonder whether it would be realistic to have bullets whose paths are solutions of differential equations. It seems unlikely, but then I don't know much about numerical integration techniques. Perhaps by splitting up the space into a number of blocks and solving the equation for the midpoint of each block and using that to discretize the vector field would work; just add the vector from the block in which the bullet currently lies at each (or perhaps every other) step. This would work best if every de were known at the start so that the solutions could be precomputed. It might even be realistic to find some algorithm to take advantage of low derivatives of the vector field to change block size for more accurate results. Constructing a Voronoi diagram with generators concentrated in areas of high rate of change ought to work for that, though I'm not sure how fast it is to determine to which cell an arbitrary point belongs. Some research on Wikipedia suggests that I've been roughly describing a finite difference method, though I just woke up and my ability to comprehend is shaky at the moment.

Thanks for making me want to do things I shouldn't be doing.

Thinking about it, using a precomputed vector field would be only marginally slower than simple bullets; instead of looking up the relative vector on the bullet object, it looks it up from the vector field, which only adds a nested array lookup for the plain grid method. numpy could be used to make this very fast, as well as give the option of occasionally transforming the vectors, perhaps to interpolate between different states.