CREATING INFINITE, DYNAMIC CONTENT

Example Use
You want the player to find new content when revisiting an old map. This could be a simple dungeon crawler which utilizes a single map, or a sprawling world with many large, dynamic landscapes.

DEFINITIONS

Switches are on/off functions, often too restrictive for creating dynamic content.

Variables allow for many possinle outcomes, essential for dynamic content.

Conditions are used to expand or restrict the possible outcomes based on specific criteria.

Call Event is used to call common events.

Common Events are designed to keep your code organized; an essential when working with dynamic outcomes.

Front End refers to your maps and map events. Essentially this is the place characters explore.

Back End refers to common events, which are managed separately from the playable area.



I'll demonstrate using the concept of unlimited chests, starting with a simple example, and then moving to more complex uses.

Unlimited Chests - Simple Version

Each time the player enters the map:

- Only 1 chest can spawn.
- The chest can spawn only in a single spot.
- The chest has a 25% (1 in 4) chance of spawning.
- The chest could contain 1 of 3 outcomes.

Back End Controls the 3 chest outcomes
Create a common event called Chests. Make this event triggered by being called.

Create a variable to randomize numbers. For instance, VarRandom.

In the common event code set VarRandom to random 1-3.

Set a condition branch, if VarRandom=1, then;
Include the content you want for one of your 3 outcomes when a player opens a chest. For instance, they gain a heal item and receive a message about what item they received.

Copy and paste the condition branch, but change VarRandom to =2, and change the content to your second possible outcome.

Repeat the last step but with VarRandom=3.


Front End Controls # of chests, spawn location, chance of spawn

Place an event in the location where a chest can spawn.

Page 1 of the map event remains blank and should be below the player.

Create a second page in the map event.
Page 2 will use a variable. Lets call it VarChestChance. Page 2 will activate if VarVhestChance is equal to or greater than 4. (Could just be equal to for this example.) Page 2 should show an image of a chest, be on the same level as the player, and be activated by the action key.

The event code would be: Call Event: Chests, followed by Erase Event.


This completes the code for unlimited chests, simple version.


Unlimited Chests - Dynamic Version

Each time the player enters the map:

- Up to 2 chests can spawn, individually or together.
- The chests can spawn in 3 predetermined positions.
- Chest 1 has a 5% (1 in 20) chance of spawning.
- Chest 2 has a 10% (1 in 10) chance of spawning.
- Chest 1 has 2 outcomes.
- Cheat 2 has 500 possible outcomes.

Back End
Edit your common event Chests, starting with VarRandom. Set VarRandom to a random number between 1-500.

We will use VarChest1 and VarChest2 to distinguish each chests outcomes.

After VarRandom, add Conditional Branch VarChest1 is equal to or less than 250.
Include content of outcome 1 for chest 1.

Copy and paste the conditional branch. Change it to VarChest1 is equal to or greater than 251.
Include the content for chest 1's second outcome.

Create a new conditional branch, VarChest2=1
Add your first outcome for chest 2.

Copy and paste the last conditional branch and increase the variable by 1. Edit the content as you see fit. For 500 possible outcomes you will repeat the step from VarChest2=1 up to VarChest2=500.

Note: Don't do this to yourself. This just shows the limitlessness of potential outcomes.

Front End
Create a map event out of the playable area and name it Chest1.

In Chest1, keep page 1 blank and below hero. Create page 2 with a requirement if VarChestChance1=1 (this will give us a 5% chance of spawn when we setup the map parallel event to follow.) Give page 2 a chest image, same layer as player, activate by action key. In the main box, Call Event: Chests, followed by Erase Event.

Save the Chest1 event and then copy the whole event and paste it on the same map, out of the playable area. Name this event Chest2. On page 2, change to use VarChestChance2=1.

Place a parallel process event on your map. Have it run VarChest1 random 1-3.
Conditional branch, if VarChest1=1, move event (Chest 1 event) to it's first possible spawn position.

For 3 potential, predetermined spawn locations, repeat this conditional branch step 2 more times with VarChest1=2 and =3, with the move events pointing to the other possible spawn locations.

Cut and paste the code so far. Change the variable starting from the "random" setting and including the 3 conditional branches to be VarChest2. Change the 3 new move events to move map event Chest 2, and pick different map positions from what was used for chest 1 to avoid overlapping chests.

Set VarChestChance1 random 1-20.
Set VarChestChance2 random 1-10.

Add Erase Event at the end of your parallel event. This completes the random (but predetermined) placement of your chests and determines spawn chance.


There, now each time the player enters the map, 0, 1 or 2 chests appear. 1 chest has 3 locations it can show up in, and the other chest has 3 locations it can show up in. One chest has 2 possible contents when opened, the other chest has 500 possible contents when opened. Chests disappear once opened, and the whole thing resets with random outcomes again when the map is reentered.


Getting More Dynamic with Chests
Here's some ways the unlimited chests could be more dynamic.

1. A chest can appear anywhere in the map.
You could create X and Y variables for each chest event and use randomization to of X and Y to place an event. If your map is small, you might even use VarRandom with a condition for each walkable space on the map, and a move event for every possible space for complete randomness (great for single room, randomized dungeons.) You could even use player XY variables and player facing condition to have a chest appear in front of, or a few steps from a player at random.

2. Chests can be things other than chests, such as piles of rubble, boxes, or pools of water which are atatic and may or may not have contents when searched.
In thie case, you could use your map static graphics as "chest" locations and simply keep the "Chest" events without pictures and same layer as the player. In this scenario the "chest" doesn't vanish once opened. You could even use an "opened chest" map graphic for which a "closed chest" event could spawn over it. When the closed chest event is actioned and erases, it keeps an open chest graphic below.

3. Some outcomes are only possible if a specific item is owned or equipped, or a specific skill has been unlocked (more specific conditions.)
This could be managed on front or back end, but I recommend doing this in the backend conditions (your common event.) Ie. Condition if VarChest1=1, Condition if switch on: SkillLooting, then +100 gold, else, +20 gold. There is no limit to the number of condition layers which can be used in this case, whereas the front end makes dynamic expansion difficult and limited.

4. Add more chest variables or increase possible chest content outcomes.
This is self explanatory but for inspiration: make some chests crate images and some chests. For outcomes, launch a mimic attack, provide a healing item, have an empty container. or have the player find several consumable items. Even use content specific "chests", like a first aid kit which can supply things like band-aids, scissors and tape, or a chemical storage container which gives bleach or other chemicals. Think outside the "open chest, get sword" generic framework.


Beyond Chests - Dynamic Worlds
Ever more dynamic chest spawning is a good starting basis for a limitless game, but a truly infinitely dynamic game has to have much more randomized and repeatable content than just chests.

Consider how the same principles could be applied to:

- Quests
- NPC's
- Enemies
- Map terrain
- Environments / weather
- Encounters


Dynamic Worlds - Simple
Try this out. Make a small, walled in map using simple graphics for now. Make the map large enough so it can have unplayable borders and plenty of space outside of that for hidden events.

Make spaces for a doorway in the center of north, east, south, and west. Imagine this map being thr only map in your game, but infinitely explorable and interesting, with dynamic, changing content. How would that work?

If you walk through the door on the east, you would teleport the player to come in from the west side and thr map would run all its randomness. So far, so good. Right? But if you then turned around and walked through the west entrance, logic says you went back to where you were - but the map just loaded random content again, so that doesn't feel right.

So we've established random needs to feel logical to your world. One way to get over this screen transfer hump, is to make the door close behind the player, and only ever allow them to move in a direction they didn't enter through. What if they go east, north, weat, south? Wouldn't they be back where they started? Lets consider options for an infinite, single map.

A. The player only progresses by falling through to "another level" ensuring they never return to a previous map.

B. The map is borderless and feels natural, like flying a ship in space. Think "Asteroids."

C. The player never leaves the map, only the content within changes.

D. The environment is always static, randomness comes from monsters or NPC's which logically could move around out of your view.

E. The map progresses in a single direction. So the player can move east repeatedly, but never west, like Mario Bros.

You get the idea. So you create a logical movement path. Lets stick with the walled in room with four entrances. Lets replace the doors with teleporters which, logically, could teleport you anywhere, but that if entered on the right, bring thr player to the left, and vice versa. Repeat for top bottom. Tbis creates a feeling of dynamic movement between spaces despite the player staying in a single map.

Now, we could take a couple approaches to the next step. One would be to make multiple events outside of the visible map which get moved into place if specific criteria are met. For a large map, this could be the best option but we are working in a small, simple map. In thiw case, we can make an event specific to ever space we might fill, for greater customization.

Using a floor tile, outline a path which touches every teleport point, ensuring no matter which teleport the player comes out of, they will always have space to move to another teleporter. Or, if you don't mind blocking your player in, make the teleporters have 1 open space in front of them, and the player could always walk through the teleporter they just came through for a new, randomized room. I prefer the first option as it ensures the player can always feel like they are progressing. Anyway, the marked out path (hopefully it's not straight lines but instead crooked, narrow, and illogical, will be reserved as free space. No events will randomize into these locations.

Outside of your reaerved path, but inside your player zone, add a map event.

Event page 1 is blank, below hero.

Each additional page will use a single variable which counts up by 1 number for each page. The variable used will stay consistent for thr event, but not be used for any other event (unless you want a second event to always have an identical outcome.)

On each page, decide what you might have appear. I recommend using a spreadsheet for this part of your game design and planning. Reserve number ranges for specific outcomes. For example, Var=1 to Var=10 might be terrain (tree, rock, hole, etc.) Var 11-15 might be different enemy types. Var 16 might call a common chest event. Var 17-18 might be the appearance of boosters or special items. Var 19 might be a vendor NPC, while 20 is a quest giving NPC. Etc etc.

Now for greater dynamic, those slots of 1-22 might be themed. For example, all of them use graphics indicating a snowy environment and NPC's dressed warm. Then 21-40 might repeat what exists in 1-20, but in an underwater theme. This is a layer of dynamics which could allow the player to explore different, or even advancing levels. I'll get back to this.

Okay, so you've decided to keep it simple. Your event will have one of the following outcomes:

- Empty
- Chest
- Enemy
- Quest NPC
- Rock (red)
- Rock (blue)

Empty is default.
Let's assume your enemy, chest, and quest NPC's call their own dynamic events.
Lets assume if the variable selects red rock, than it checks the condition of whether or not the player is in a blue room. If so, it changes the event variable to match the event page showing the blue rock.

Lets also assume your map tiles by default have redish walls and a dark red floor. But, when you go through a teleport, there is a chance the BlueRoom switch is turned on. If so, the map tileset is also changed to an identical map tileset where red tones are replaced with blue.

This just shows a method which can be used to transition levels. Instead of a "BlueRoom" switch, maybe its "Level2" or "SecretRoom." Your imagination is the only limit to this dynamic possibility.

Now, back to your map event. Lets say you're using a variable named EventA.

When you teleport, a parallel event will randomize variable EventA directly, or use a separate randomizer. Directly means the tile has the same chance of being an enemy or a quest giver or a rock. We want rocks to be more common than all other events combined, so we'll use a separate randomizer.

In the parallel event, "varRandomizer set 1-100". If Randomizer 20 or less, set EventA=0 (20% chance of empty.) If varRandomizer >= 21; <=26, set EventA=1 (5% chance of chest). You get the idea here.

Now, after the outcomes for EventA, you will repeat the randomization followed by event outcomes again, but this time using EventB.

EventA and EventB will be identical except for the variable being used. So really make sure EventA is working as intended and looks the way you desire, before continuing with additional events. You will continue with C, D, E, etch (or just use numbers) until all the playable area is filled, except the spots you reserved to always be walkable.

Your parallel event outside of the playable area will be cut and paste coding of the randomize followed by the condition events, where only the event variable is changed in the conditions each time. Do this for all events. The bigger your map, the more work this is.

Set switch "BlueRoom" to random.
Condition: if BlueRoom on, change map tileset to blue.
Else; change tileset to red.
Finish your parallel event with an Erase Event command.

Boom, your playable area will now appear blue or red themed. You will have a guaranteed walkable path to make all teleports accessible. All other playable spaces will be roughly 30% empty, 5% chests, 45% rock, 15% enemies, and 5% quest giver (as a for instance.)

Now in common events you would have made one called Chests, one called Enemies, and one called Quest NPC (or similar.)

The chest would work like described in this tutorial. You may make the outcome give one of three items. Say, "Stars" and "Coins" and "Health". Health will heal player automatically where Stars and Coins are collectibles. When one is collected, a Star or Coin variable is increased by 1.

The NPC will have 4 outcomes. It will either give you a quest to collect 3 stars, a quest to collect 5 coins, or it will tell you you've already taken a quest, or will provide the outcome for completing the quest if you have met the criteria. Obviously this could be greatly elaborated on but should demonstrate the basics which you could expand the dynamics for (kill x enemies, various NPC's, find X NPC, etc etc.)

The Enemy could be static, moving within the confines of the walkable space, flying above the confines, moving towards the player, moving at random, take X damage on touch then erase, etc etc. Again, many ways to elaborate on an enemy.


Our Example Endless Game
So we've used a single map with 3 simple common events, a couple basic tilesets, 1 parallel map eventz and likely dozens of individual map events, with a single switch and many variables and conditions.

In doing so, we created a game which randomizes the level, terrain, enemies, NPC quests, chests and chest content, which can be played indefinitely, or at least until the player dies.

Goals could be added and displayed on death, such as time played, quests completed, enemies slain, etc. This type of system is infinitely expandable, or portions could be utilized, such as randomized quests and chests in an RPG, without the random terrain.

We could even add randomized weather, tint, music, etc to make the experience more dynamic (but sometimes less is more.)

Using pictures, a system of randomized gun parts, effects, and names could easily mimic Borderlands, to achieve hundreds of thousands of potential outcomes.


Conclusion

Infinite, dynamic worlds or features can be made in RPGMaker with little effort.

Plan your game beforehand, ensure logic and consider obstacles and overlap problems before getting too far in. Use dynamic systems to make your games more fun and interesting, but be careful about adding unnecessary or boring features just because they are more complex.

Happy game deving!