How are Roguelike/Bullet Hell mechanics stored in Unity?

Question

I'm going to be creating a roguelike bullet hell game wherein the play will be a bullet hell game, but you will be traveling between "rooms" wherein the action takes place. The "rooms" will be randomly generated like in roguelikes such as The Binding of Isaac, but with bullet hell play similar to Touhou or Batsugun, with a possible twist. It will be similar to Enter the Gungeon, but there will be some differences.

I'd like to know how Unity will deal with storing possibly thousands of different "rooms" and generating these each time, along with the enemies and bullets these enemies will begin to shoot after you enter the room. Only one room will be visible at a time.

How would Unity deal with mapping possibly thousands of rooms, and will it be able to store this while generating bullet patterns? I know that in classic bullet hell arcade games, when there were many bullets on the screen, the game tended to slow down because of hardware limitations.

Answer 1

The trick behind these roguelike mechanics is that typically you don't store much at all.

The shape/contents of each room are determined by an algorithm that's generally seeded with the position of the room, and possibly a unique key for each "new game" session.

This algorithm, which can take many forms, is effectively a deterministic machine: put the same numbers in, and you'll get the same room out. (But put in different numbers, and you'll get different rooms!) So you don't need to store the contents of the room to be able to re-draw it if the player doubles back. Just put the same position in again and you'll automatically get the same room.

This is how early roguelike and procedural games managed to pack such immense explorable worlds onto the tiny floppy drives and limited RAM of early PCs.

If the player can make changes to the rooms, then you do need to store those changes to be able to reproduce them faithfully. This storage generally grows linearly with play time, and can be discarded when the player hits a permadeath point, so even if it's conceptually unbounded it can usually be kept quite modest.

You can tune how much you need to store by the design of your mechanics: if the room repopulates whenever the player leaves it without clearing it entirely, then you only need a single bit of storage per room: a "cleared" flag. Or if the player's changes are limited to discrete cases: killed enemy/bombed breakable wall, you can similarly keep it scoped to some worst-case number of bits per visited room. Or you could have the player's changes "age out" after they move more than 10 rooms or 30 minutes' game time away, allowing complex state tracking with a limited time horizon. Games like Minecraft, which allow much deeper player customization of visited chunks, correspondingly have much more intense storage needs.

As for how "Unity" deals with this: it handles it however you tell it to. It doesn't have a built-in roguelike bullet hell component you're forced to use. So you can script whatever custom system you find will meet your game design/player experience goals and performance needs on your target hardware. Generating the next room's contents, discarding old rooms, storing what you deem important along the way, all of that is your responsibility.

If you ask a narrower question with details of a specific mechanic or piece of your generation strategy you'd like some help with, we can provide tailored answers about that particular problem.

Answer 2

If your game is like Binding of Isaac where each room is full-screen, then it might be a good idea to actually only have one scene with one room. When the player moves to a different "room", you just modify that room accordingly by Destroying and Instantiateing the room-specific objects.

When you do want scrolling transitions between rooms, you could do a room transition by instantiating the new room from a prefab, set it up, pan the camera to the new room, and destroy the previous room.