WARNING Bullet patterns in bright colors over a dark background. I'm not an expert on seizures, so I'll warn just in case.
This is an experiment about making bullet hell patterns in a more... expressive way. The key idea is that, instead of bullets being "updated" every frame, we know already of their position at all times, because they really are functions from time to place.
The project has
-
The bare minimums to make demos passable (i.e. there is no track of score, lives, etc.)
-
A bunch of "helper" functions. These include functions to group bullets, functions defining a bullet's movement, etc.
-
A bunch of "demos" showcasing the helper functions as well as bullet patterns from the bread 'n butter to the pointlessly complex.
It's public domain (CC0). If you want to use bullet patterns, pieces of code (e.g. helper functions), etc, feel free to use them. In fact, I'd be glad to hear this has helped someone.
This is meant to, in one way or another, serve as a reference to this "flavour" of bullet patterns. Or at least as a source for inspiration.
Not better, not worse, but different. A more in-depth discussion of what precisely is this new way can be found in the wiki. The consequence of the different approach are...
- You get to know where every bullet is at every point in time.
- You can have eternal bullets.
- You can mess up with time seamlessly.
- Slow motion
- Speed up
- Go back in time
- You get the power of Bezier curves to interpolate crazy patterns.
- Really useful!
- Harder to keep track of bullets independently
- Much harder to do "bomb" (locally eliminating bullets) behaviours.
- Much harder to have bullets move based on physics
- E.g. "follow the player" bullets are much harder to make.
First, try changing the constants of the demos (under the "Scripting" header), and see how the choice of them changes the patterns. Many times, finding the right pattern is just a matter of tinkering with the constants enough.
Secondly, I'd recommend looking at the source code for the demos (inside the "demo" directory), to get a sense of how they work. You should be able to make new demos by picking parts here and there.
Thirdly, I'd recommend looking at the wiki to see how everything fits together. There, I'll also discuss bullet patterns for a designing rather than programming point of view.