I think it's time I did the post-mortem for this - I released it at the end of 2023, I spent £20,000 on it and made maybe £5,000 back. You can read the "how I released it" at the end of my 100 days of dev blog that I wrote during the last 100 days of development - that's the optimistic "omg I made it" post. This post is not that. This post is what went wrong.

First things first - sales!

• I got £1000 from a kickstarter campaign, which provided a little bit of dev funding
• On Steam, it made $1,000. That it made any money at all is a miracle in hindsight! This isn't horrible for an indie's first release.
• On Xbox, it made roughly £1,500.
• The bullet spawning tool I released alongside it made the remaining money - another £1,500

So what went wrong?

Genre!

Steam players don't like arcade games. Steam players like games with a good amount of content - if you're good enough at my game, you can beat it in 15 minutes. Console players are similar, but they are a little more open to arcade stuff. This is the main reason the game didn't really sell very well, I think! Genre is half the battle, and damn it Chris Z was right about arcade games. At least I got to tell him that in person at GDC...

Hubris!

I had at that point been making games for 15 years. I had done it professionally for 10. I can make a game that is fun (at least JW of Vlambeer thinks so). I can make a game that is polished. I made a game that put accessibility first - it is high contrast by default, playable with just a thumbstick or a mouse, it ticked all the boxes (and was nominated for MCV/DEVELOP Accessibility Innovation of the Year).

Oh boy did I find out that those things don't matter at all 😂

Mechanics!

My game is very difficult to describe in a way that sounds fun - your ship is positioned on a ring, and your position is exactly the position of the thumbstick. That makes for some really cool bullet patterns that are actually dodgeable, even though they seem overwhelming, but it is VERY difficult to describe, and you really should be able to describe your core mechanic well. On top of that, the whole "even though they seem overwhelming" thing bit me in the ass! Because it looked so difficult, only 20% of players beat level 2 - that means 80% of players gave up before then 🫠

Spending!

If I hadn't spent £20k on the game, it could much more easily be called a success. Probably the most worthwhile money I spent was on music, and that was all I needed to spend really. The rest was pretty much useless - I did paid ads on reddit, youtube, tiktok, and twitter (only youtube and tiktok made any difference at all). I did marketing courses. I ran a huge ARG that was lots of fun but cost me so much money 😂 I gave away pizza on my Discord server, I ran competitions with cool physical prizes, none of it moved the needle, all of it cost money. I guess the people who were in my Discord were happy, which isn't nothing.

Dumbassery!

I got to the front page of r/indiedev. Do you know what was missing from that post? A STEAM LINK. A good amount of people knew about the game, but they did not have anywhere to follow through, so I launched the game with ~1000 wishlists. This was not my only mistake! I released on steam a week before the shmup fest, so as the shmup fest started my launch discount ran out and I couldn't add another. I made the musician rewrite all the music after he'd already done the entire soundtrack. There were some things to do with the Xbox release that I can't talk about. I did Steam Next Fest two full years before launch.

Also, I added a new mechanic that dramatically altered gameplay one single month before release. This forced me to hack together a rushed 30-second tutorial in about four hours, then required a complete re-balance of the scoring system right at the finish line. Don't... don't do this if you can help it. It made the game much better, but I strongly advise against this!

Pricing!

The game was originally priced at £12.99, or $15 - this was a terrible idea. I thought the "premium" price tag would make it more attractive, and I gave £1 per sale to a charity called SpecialEffect. That killed my bottom line, so the price tag couldn't be too low or I'd be losing money if people bought it on sale. On top of that, the game was actually pretty popular in Brazil, so I should've adjusted regional pricing.

Pacing!

I worked without a deadline or goal for over 2 years. I don't really recommend that, treating the game like this meant it would never be finished. Then I switched track entirely, pulling all-nighters and crunching for 20 hours in a single day, which led to a lot of the dumbassery in the end. If you're reading this and wondering what you can do better than me, there is little that will be more impactful than setting yourself clear boundaries!

Conclusion

Was this a failure? If you only look at it from a financial point of view (and I did only look at it from a financial point of view for the first... year?), yes, it was a bit of a disaster. I won't sugar-coat it, I was bitter and grumpy. Was. I have since realised that it was a very good opportunity to get a game published on Xbox by myself, and I learned a TON from doing it. Hopefully I've been able to pass on some of the lessons I've learned.

Hey! Today I want to step back from code architecture and talk about game design. Specifically, how playtesting can prove a mechanic is incredibly fun... and also that you need to delete it 😂

I’ve been working on an aggressive, Burnout-style racing game, and I wanted a strong mechanical hook to make it stand out from the crowd. So, I prototyped a neat bouncing mechanic.

Here is how it worked: instead of braking into corners and losing speed, you hold a button to become perfectly frictionless and bouncy, allowing you to bounce off the walls. If you let go of the button when you are closely aligned with the track's forward direction, you get a generous boost refill.

Once you figured out how it worked, it felt AMAZING. It was so much faster and gave you these insane lines through corners.

There was a major problem though, have you spotted it?

The Teaching Trap

This mechanic was too difficult to explain and teach.

I put together a dedicated tutorial flow that forced the player to use the mechanic on a really simple track. I put it in front of 10 to 15 people, and basically all of them completely failed. I had to physically step in and explain how to do it.

Once they finally got it, most people had a blast! But that doesn't actually matter. If your game isn't simple to understand right out of the gate, it will have a massive churn rate. Players just won't stick around long enough to find the fun.

Sometimes your game's unique selling point is the exact thing working against it. It was a bit of a gut punch to realize this. It was a genuinely fun, highly unique mechanic, but that uniqueness fought against every natural instinct players bring into a racing game (like "brake for corners" and "try not to hit the walls").

Throwaway Code

Thankfully, I didn't lose months to this idea.

The bounce prototype took about a week to implement fully. I knew I needed to validate it, so I didn't get attached to the code. I didn't spend a single minute on clean architecture or SOLID principles. I just threw it in as a hacky mess so I could get it into players' hands.

The Lesson: Test early and test often. If you spend three months building perfectly decoupled architecture for a mechanic that takes 10 minutes to explain, you are building a beautiful ship that will immediately sink.

Because the code was cheap, throwing it away didn't hurt.

The Pivot

I've got a new mechanic to replace it that is much more straightforward. If you stick behind other drivers for long enough, you gain the ability to pierce right through them, shattering them into a million pieces.

This actually fits the aggressive vibe of the game a lot better! Drafting is something that already aligns with the way people typically play racing games, so I don't have to teach them a totally alien concept. I haven't fully playtested this specific implementation just yet - I want to make a couple more little tweaks first - but it is already miles easier to explain.

Don't get too attached to your mechanics, even the really fun ones. Build an ugly prototype, validate it early, and don't be afraid to kill your darlings if your players can't figure them out.

Hey! Today, instead of systems and tech stuff, I want to step back and talk about the hardest thing to debug: your own brain.

I'll let you in on a secret: your brain often works against finishing. This isn’t a moral failing or a lack of discipline. It is just predictable human behaviour given uncertainty and long timelines. Common symptoms include doomscrolling, endless code refactoring, announcing features you haven't built, and writing massive design docs that never ship.

By the end of this post, you’ll understand the forces causing it, and you'll have a concrete checklist to turn "I should work on my game" into a repeatable shipping loop.

The Problem

Saying your brain "hates" you is a bit dramatic. The truth is, your brain loves you! It is an ancient survival machine designed to keep you alive, which means its priority is conserving energy and avoiding threats. It is constantly scanning your environment for the path of least resistance.

This brings us to dopamine.

Dopamine is heavily involved in wanting, drive, and learning what’s worth pursuing, especially through anticipation and reward prediction. While this is a simplified model, it’s incredibly useful for us game devs to understand. Your brain quickly learns which actions deliver fast rewards with low effort, and it will heavily bias you toward those. Because your brain wants to avoid threats, it is always looking for shortcuts that deliver quick reward signals (novelty, social approval, certainty) without the cost of building.

This leads to three common traps that quietly stall games for months:

Trap 1: Talking Instead of Doing

Have you ever had an amazing idea for a mechanic, run straight to Discord or Twitter to announce it, and soaked in all the "Wow, that sounds incredible!" replies?

Publicly announcing goals can create a false sense of completion and identity ("I'm the kind of person making this awesome game"). Your brain generated the drive to build something, but you fed it a cheap, immediate social reward instead. The anticipation is resolved.

The result? You are left with much less drive to do the hard, ambiguous part next. This isn’t a strict rule to never share. It just means you shouldn't cash the praise check before you’ve done the work (a well-documented psychological phenomenon often called the social reality effect).

Trap 2: Decisions Based On Vibes

Because your brain wants the path of least resistance, it prefers to make design decisions based on hypotheticals. Running a Twitter poll or posting a community questionnaire is a low-effort reward signal disguised as actual development.

I learned this the hard way during a playtest. A tester read over the concepts for two different game modes. Based purely on the idea, they filled out their pre-play feedback form and confidently stated that Option A was the right choice. Then, I actually built both.

• Option A: Player abandoned it after 10 minutes.
• Option B: Player engaged for a full hour.

People will tell you one thing and do another! In playtests, you can treat what people tell you as a hypothesis, but you learn a lot more from observed behavior. In a 20 to 30 minute test, track these specific metrics:

• First 60 seconds: Note points of confusion.
• Time-to-first-fun: Wait for their first smile, laugh, or "oh!" moment.
• Retries: Count the number of voluntary attempts after failing.
• Engagement: Notice when they ask a question versus when they just keep playing.
• Persistence: See if they choose to continue when given an explicit out.

Trap 3: Ambiguity Avoidance

A lot of procrastination in game dev isn’t pleasure-seeking. It’s ambiguity mixed with a fear of wasted effort. When the next step in your project is unclear (like "Fix the combat system"), the brain flags it as a high-energy threat. In this context, "threat" often just means uncertainty plus potential wasted effort plus ego risk (finding out your idea isn't fun). It seeks clear, easy rewards elsewhere, like watching a YouTube tutorial.

Conversion Rule: Rewrite any task until it starts with a verb and can be done in 10 minutes. For example, replace "Fix combat" with "Spawn one enemy in an empty room and log time-to-kill with a debug print."

The Fix: Design a Pro-Shipping Environment

If you know your brain is an energy-efficient machine looking for shortcuts, yelling at yourself to "just work harder" won't fix anything. Instead, you need to design your environment and workflow so the "easy path" points toward shipping.

1. Micro-Dose Progress (Build Momentum)

If you're stuck, your task is too vague. Lower the energy required to start. Open the project. Hit Play. Write the next micro-step where you can’t miss it (a sticky note, a README, or a task list). The win is simply having the project open and one tiny change committed.

2. Use Prototyping as a "Cheap Win"

Stop theory-crafting the perfect system in your head to avoid the work. Make crappy throwaway prototypes using primitive shapes and borrowed constraints from an existing game. Or make it on paper! It gives your brain the fast, low-friction win it craves, but in a productive way.

3. Lock the Social Reward

You need a hard constraint to stop reward substitution. Here are a good couple of rules I like:

• Share progress only in spaces that create accountability (like a build log with a set deadline), not just praise.
• You are not allowed to post a screenshot or tweet about a feature for public validation until you have a playable, tested build.

A Checklist for Shipping

Game development is a marathon filled with uncertainty. Keep this checklist handy to keep your brain on track:

• Daily micro-win: Define one task that takes <15 minutes and ends in a visible change.
• Prototype rule: Any mechanic idea gets 60 minutes of ugly implementation before discussion.
• Social lock: No posting until there’s a playable build and one external playtest note.
• Behavior > opinions: Measure time-on-task, retries, and voluntary re-engagement.
• Reduce friction: Ensure your project opens in <30 seconds. Keep a "next task" note in your repo so you never start with a blank slate.
• Weekly ship: Package one build every 7 days, even if it’s small and ugly.
• Weekly review: Spend 10 minutes asking what shipped, what stalled, and what’s the next smallest playable slice.

Template:

• This week’s smallest playable slice: ____
• This week’s playtest question: ____
• Ship date/time: ____

Pick one item from your backlog right now. Set a 15-minute timer. Define the smallest visible change and do only that. Stop while it’s still easy, so tomorrow has low friction.

Hey! Since we've already covered the math behind firing beautiful geometric bullet patterns, I thought it would be fun to tackle the other side of the shoot 'em up equation: the enemies firing them.

This post focuses on the software architecture of building levels. For actual wave pacing and enemy placement theory, I highly recommend checking out Boghog's Shmup Workshop

I'll let you in on a secret: hardcoding your enemy spawns in your game loop is a trap. If your update loop is full of timers and nested if statements, making a full, five-minute level is going to be an absolute nightmare. We need a way to cleanly sequence exactly what happens and when.

Enter the Command Pattern!

Timers!

Let's start by looking at what we want to avoid. When you first start building a level, it's really tempting to just count the seconds and spawn enemies based on the current time:

private float levelTimer = 0f;
private bool waveOneSpawned = false;
private bool waveTwoSpawned = false;

void Update()
{
    levelTimer += Time.deltaTime;

    if (levelTimer >= 2.0f && !waveOneSpawned)
    {
        SpawnEnemy(enemyPrefabA, new Vector2(5, 10));
        waveOneSpawned = true;
    }

    if (levelTimer >= 5.5f && !waveTwoSpawned)
    {
        SpawnEnemy(enemyPrefabB, new Vector2(-5, 10));
        waveTwoSpawned = true;
    }
}

Notice the problem? For a typical shmup level, you might have hundreds of spawns. This script will turn into an absolute monster, and tuning the timing of an early wave means manually tweaking all the numbers for the rest of the level. It's rigid, creates bugs, and hurts to read.

Commands!

Instead of writing the logic out procedurally, let's turn "Spawning an Enemy" into an object. We want to decouple what happens from when it happens.

However, we don't just want fire-and-forget commands. What if we want a command that pauses the level until the screen is clear of enemies? If we use a basic loop, we'll immediately hit a wall. To pause the game's timeline, a command needs a way to tell the queue: "I'm not done yet!"

We also want to make sure this code is incredibly clean and performant. In Unity, the rookie mistake is to use FindObjectsOfType<Enemy>() to check if the screen is clear. That is intensely slow and creates garbage collection spikes.

Instead, we are going to design our architecture using SOLID principles so everything is fast, decoupled, and easy to extend.

Context!

First, our commands shouldn't depend on a monolithic LevelManager script. That breaks the Dependency Inversion Principle. Commands should depend on abstractions (interfaces).

Let's create an interface that holds references to all the systems our commands might need to interact with:

public interface IEnemyTracker
{
    int ActiveEnemyCount { get; }
}

public interface ILevelContext
{
    IEnemyTracker EnemyTracker { get; }
    // We could add IAudioService, IScoreManager, etc. here later

}

Now, instead of Unity's slow methods, our actual game logic will just maintain a simple integer counter of enemies. An EnemySpawner increments it, and an Enemy's OnDestroy event decrements it. Checking if the screen is clear is now a lightning-fast O(1) integer check!

Wait For It...

Next, let's look at our command structure. Every command needs to be executable, and every command needs to report if it is finished:

public interface ILevelCommand
{
    float Timestamp { get; }

    // We pass our decoupled context here
    void Execute(ILevelContext context);

    // Allows commands to block the queue from progressing
    bool IsComplete { get; }
}

For standard, fire-and-forget commands (like spawning an enemy), IsComplete will just return true. They finish instantly.

But here is our WaitUntilClearCommand. Its single responsibility is to capture the enemy tracker when executed, and then constantly report its completion status based on that tracker.

public class WaitUntilClearCommand : ILevelCommand
{
    public float Timestamp { get; }

    // We store a reference to the tracker once executed
    private IEnemyTracker tracker;

    public WaitUntilClearCommand(float timestamp)
    {
        Timestamp = timestamp;
    }

    public void Execute(ILevelContext context)
    {
        tracker = context.EnemyTracker;
    }

    public bool IsComplete => tracker != null && tracker.ActiveEnemyCount == 0;
}

Look at how clean that is! It knows nothing about Unity, nothing about prefabs, and nothing about timers. It just asks the tracker for the count.

The Upgraded Queue!

Finally, let's look at how our main game loop handles this. We need to introduce the concept of an activeBlockingCommand.

If a command blocks, we stop pulling from the queue and we pause the timer.

public class LevelTimeline : MonoBehaviour
{
    private Queue<ILevelCommand> commandQueue;
    private ILevelContext context;
    private float levelTimer = 0f;

    // Stores any command that takes time to complete
    private ILevelCommand activeBlockingCommand = null;

    void Update()
    {
        // 1. If we are blocked, wait until the command finishes
        if (activeBlockingCommand != null)
        {
            if (activeBlockingCommand.IsComplete)
            {
                // Unblock
                activeBlockingCommand = null;
            }
            else
            {
                // Still waiting? Stop doing level updates.
                return;
            }
        }

        // 2. We only advance time if we aren't blocked
        levelTimer += Time.deltaTime;

        // 3. Process new commands
        while (
            commandQueue.Count > 0 &&
            commandQueue.Peek().Timestamp <= levelTimer
        )
        {
            ILevelCommand nextCommand = commandQueue.Dequeue();
            nextCommand.Execute(context);

            // If this command isn't instantly finished, it blocks the queue!
            if (!nextCommand.IsComplete)
            {
                activeBlockingCommand = nextCommand;
                break; // Exit the while loop early
            }
        }
    }
}

Because we followed the Open/Closed Principle, our LevelTimeline code is completely closed for modification. We never have to touch this Update loop again to add new features! Want to wait for 5 seconds? Add a WaitTimeCommand. Want to wait until the boss reaches half health? Add a WaitForBossPhaseCommand!

Data!

This is where the magic really happens. Because our commands are just objects holding data (a time, a prefab, a position), we no longer have to define our levels in code.

We can move our level design completely out of C#. You could write your levels in a JSON file, a CSV spreadsheet, or ScriptableObjects. Here is what a level might look like when serialized to JSON:

[
  {
    "type": "SpawnEnemy",
    "timestamp": 2.0,
    "enemyId": "Fighter",
    "position": { "x": 5.0, "y": 10.0 }
  },
  {
    "type": "WaitUntilClear",
    "timestamp": 2.5
  },
  {
    "type": "SpawnEnemy",
    "timestamp": 3.0,
    "enemyId": "HeavyBomber",
    "position": { "x": 0.0, "y": 12.0 }
  }
]

N.b. if you're in Unity, you'll want to use something like Newtonsoft JSON to help with this

Now you can tweak timings, add complex waiting logic, and build entire new waves without ever recompiling your game. This opens the door to player-created levels, too, which is even cooler.

Taking it further!

This architecture is the foundation of a modern shmup engine. Our engine is completely separated: the timeline handles the flow of time, the commands handle the instructions, and the context handles the game state.

Once you have a timeline of commands running your game data like this, the next natural step is building a visual tool. Instead of typing out JSON, you can build a timeline editor (like Unity's Timeline or a custom visual graph) where you can literally drag and drop spawns and wait commands exactly where you want them. But it all starts with this clean, decoupled queue!

Hello again! Post #2 hot off the heels of the first - Bulletfury is now open source!

Version 2 is fully working, and it is currently being used in Polyfury: Definitive Edition to great effect (thanks Hermit Cat!).

There are lots of really cool changes from V1, too. Here's a brief summary:

• Works with Unity's collisions. That means no more custom collider components.
• Scene view preview, like particle systems.
• Improved performance (read: no more memory leak lol).
• In depth module system for deep customization. This is my favorite thing really; it's so easy to add new spawner and bullet behaviors.
• Massive overhaul of the editor interface. It looks pretty cool.
• Performance hints: if you are using modules that impact performance (for example, the "track object" module calculates the direction to an object for every bullet every frame), you'll get a little indicator and explanation.

V2 is a significant step up. I've learned a lot by releasing a full game using my own tool, and the core engine is now completely free and open source.

You can grab the open source repo here: github.com/WayfarerGames/bulletfury.

There is an asterisk there, though: I've put a lot of time and effort into this, so I've separated some more interesting modules into the paid asset store version. Here's what that version has:

• Object tracking for homing missiles.
• Bouncing bullets (a commonly requested feature!).
• Same-device deterministic mode with replays and rewinding!
  • N.B. this isn't guaranteed cross-device deterministic, so you can't use it for shared replays or online multiplayer unfortunately. I would love that, but it is so much work.
• Aimed bullets with aim prediction.
• Sub spawners for bomb bullets.
• Sin waves so you can wobble your bullets.
• Force over time so you can apply extra forces.
• Spawn from transform so you can change where your bullets initially spawn from.

More will be added over time to the premium version, and this is a free upgrade for anyone who has bought V1.

If you can't afford the £15 price tag, though, I've made all of this solely through the module system - so you can probably write it yourself!

Hey! As I put the finishing touches on the open source version of Bulletfury, I thought it would be fun to talk bullet spawning and maths (everyone's favourite).

This post focuses on implementation math. For design theory I'll point you to Sparen's Danmaku Design Guides, which are excellent.

I'll let you in on a secret: it's all circles! Most of the best patterns are just different types of circles under the hood. We'll start off simple and evolve the process until it's clear how the craziest bullet hell games make their pretty patterns.

Circles!

So let's start at the beginning: spawning bullets in a circle. When dealing with circles, we like polar coordinates - that's an angle and a radius. We'll use the number of bullets to work out the angle, and then we'll convert the polar coordinates to an x and y position so our game engine knows where to put them:

for (int i=0; i<numBullets; ++i)
{
    float angleDeg = (float)i / numBullets * 360f;
    float angleRad = angleDeg * Mathf.Deg2Rad;
    var position = new Vector2(Mathf.Cos(angleRad), Mathf.Sin(angleRad)) * radius;
}

Here's what that looks like as we increase the number of bullets:

Notice anything? We get useful shapes out of this, not just circles! Bullets = 3 gives us a triangle, 4 gives a square, 5 a pentagon, etc.

Polygons!

Now let's fill in the edges. To do that, we need to create bullets between two points - so we'll take this point and the next point, and interpolate between them. Linearly. We're gonna use lerp.

// We already know the angles for our corners from the Circle step
var p1 = PolarToCartesian(angle, radius);
var p2 = PolarToCartesian(nextAngle, radius);

// Now we fill the gap between them!
for (int j = 0; j < numPerSide; ++j)
{
    // Calculate how far along the line we are (from 0 to 1)
    float t = (float)j / numPerSide;
    
    // A little offset to center the bullets nicely on the line
    t += (1f / numPerSide) / 2f; 

    // Find the exact point on the edge
    var position = Vector2.Lerp(p1, p2, t);
    
    SpawnBullet(position);
}

Here's what that looks like as we increase the number of bullets per side:

Arcs!

An extra way to add some visual interest is to limit the arc of the circle. Instead of doing the hard-coded 360°, we'll swap that out for an arc that we can define from 0-360:

var angle = i * (arc / (numPoints - 1f));

One extra bit of polish here is adding an offset, so the shape is centered:

var angle = i * (arc / (numPoints - 1f)) - (arc * 0.5f);

Now here's what that looks like as we increase the number of points:

Movement!

Bullets should, obviously, move. We're going to keep it simple here and just set an initial direction and make the bullets move in that direction for their whole lifetime.

We have a few options here! We can make the bullets move:

All together in the same direction - I use the up direction of the spawner GameObject, so you can rotate the object to aim:

Vector2 direction = spawnerTransform.up;

Out from the center of the shape (radial), which forms a circle over time. If your spawner isn't at the world origin, normalize the vector from the spawner to the spawn point:

Vector2 direction = (spawnPosition - (Vector2)spawnerTransform.position).normalized;

Perpendicular to the edges of the polygon, which keeps the shape. We get the direction at the midpoint of the edge for this:

Vector2 edgeMidpoint = Vector2.Lerp(vertexA, vertexB, 0.5f);
Vector2 direction = edgeMidpoint.normalized;

Along the points of the shape, which shoots bullets diagonally. To do this, we just grab the direction of the closest corner:

Vector2 direction = (t < 0.5f ? vertexA : vertexB).normalized;

Spirals!

This is where the fun begins. Most of the patterns you see in bullet hell games will use spirals a lot - but there is no complexity here! All we do is rotate the spawned position by an angle, and change that angle over time:

// In your Update loop
currentRotation += angularSpeed * Time.deltaTime;

// Apply this rotation to the final spawn position
var finalPos = Quaternion.Euler(0, 0, currentRotation) * position;

And that's it!

Randomness!

A quick note on randomness - pure random feels bad in bullet hell games. It is unpredictable and can often hurt the player experience. However, there is a fix if you want a bit of variation: bounded randomness. Instead of a radius of 3, we can pick a random number between 2 and 4. Instead of a speed of 5, we'll put the speed between 5 and 7. That will give you variation in how the bullets look and behave, which gives it a more "natural" feeling without being unfair:

It's up to you whether you prefer the look of this or not, and it will depend entirely on the game!

Taking it further!

This is only the beginning. In Bulletfury there are even more options, but they all start from the circular base. We've got bullet groups - which is a separate circle spawned from every point on the original circle. There are modules for making bullets rotate their direction over time, apply an extra force, change speed over time, track objects, spawn two bullets with different speeds in the same position, the list goes on, but it all starts with this.