0
\$\begingroup\$

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.

\$\endgroup\$
4
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Thanks! I'm going to ask for a little bit more advice here- I do not wish to store much about each room, only ones that contain things that the player may want to interact with later, such as shops. As such, would it be simpler if I wrote in something that stated that the room has an object that you can interact with, and only record data for that room, storing it separately from the data about random generation of rooms, or should I store them together? \$\endgroup\$ – user112281 Feb 6 '18 at 5:28
  • \$\begingroup\$ This decision will probably become clearer as you get deeper into your architecture & implementation. If a room can just happen to have a shop, you won't be able to store the state of that shop until it happens to get generated somewhere: it's runtime instance data, not part of the generator's pre-loadef knowledge. So you just note it down when it happens. But if only certain kinds of rooms can have certain kinds of shops, or a shop needs to occur no less than once in every 10 rooms, that kind of shop data needs to feed into your generation algorithm itself. \$\endgroup\$ – DMGregory Feb 6 '18 at 5:33
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy