Implement Social Racing in Your Experiences With Game Maker 0.11

In this three-part series, we’re breaking down how to implement some of Game Maker 0.11’s most exciting new features.

Welcome to our series highlighting new features in The Sandbox Game Maker 0.11 update.

The Sandbox Game Maker 0.11 is a versatile tool that enables creators to enhance player experiences through gameplay mechanics, introducing new layers of interactivity and engagement. In this three-part series, we’ll explain how to create fun games using social racing features, combination codes, and rotation, providing concrete, step-by-step examples of how to use these new features to bring a game to life.

Today, we’re examining how to build Social Racing Experiences! While there are many ways to approach this concept, this document presents one method that combines a lobby and social system with multiplayer functionality. Update to the latest version of Game Maker and read on to get started.

This article is the first of a three-part series about using new tools in Game Maker.

Table of Contents

1. Build Your Lobby

2. Set Up Your Race

• 2.a Registration Period
• 2.b Countdown
• 2.c Victory Condition Method for Registration and Winning

3. Enhance Player’s interaction

• 3.a Spectator area
• 3.b NFT Store
• 3.c Mini-games

Considerations

1. Build Your Lobby

There is currently no built-in matchmaking or lobby system in Game Maker, but that doesn’t mean these mechanics can’t be implemented. By designing a system that allows players to come and go freely, races can take place seamlessly while also enabling spectators to watch events they cannot participate in.

This approach creates a dynamic lobby where players can socialize, interact with various features, complete quests, and uncover hidden mysteries. Additionally, players can earn currency to unlock different appearances and showcase their favorite outfits while playing.

Lobbies can be built around any concept and in any style you choose. In the above example, a haunted house serves as the multiplayer lobby where players can join and leave at will. Lobbies must include certain features to facilitate races and manage access for participants.

To make this lobby system work, you need to build portals or gates that players can enter to start the race. Once a player enters a portal, it will close and display a message indicating that it has been used.

You can set up as many portals as you want. For this example, there are 10 portals, meaning each race can host up to 10 players. Once a portal is used, the player cannot return to the lobby until the race is over. If all 10 portals are in use, other players must wait until the race ends.

How To Implement:

This guide does not delve deeply into the logic, as implementation can vary. However, it covers the general workflow:

• Create Your Assets: Design the portals however you like. For this concept, we used old, spooky doors.
• Add Text or Visual Cues:Use clear visual indicators to show whether a portal is available or in use.

Example: Display “Enter” text when a portal is available. After a player enters, the portal should play a closing animation, and the text should change to “In Use.”

• Use Trigger Volumes: Detect players using trigger volumes. Display the appropriate text and toggle behaviors to make the portal visible or invisible based on its status. This should display the text and remove it if the player leaves the doorway.
• Set Up a Teleporter Behavior: Create a teleport behavior and place it on a logic asset. Set up the behavior to teleport the player to a new area (we will cover this in a future guide) and make sure it detects the first player entering a portal.
• After teleportation, close the portal by toggling its behavior off. This could involve disabling the teleporter, playing a closing animation, and blocking access. Once the race is officially over you can toggle the behavior back on to start the races again. This ensures only one player can use each portal.
• Use Actor Property as a Toggle: To make the door close and display the text, you can assign tags to your visual elements. These could include text messages like “Race in Progress,” “Reserved,” or “Join Race,” as seen in our example.
• The actor property can be set up to toggle the visibility of an asset when specific messages are sent and triggered. These elements should only be triggered once certain conditions are met, such as when the race is in progress or when a player has entered the portal.

Key Points to Remember:

• Each portal is triggered by a player and closes after use.
• Only one player can use each portal — this means you need as many portals as there are players and each portal is unique in its message and setup.
• This system allows races to run repeatedly while players can freely enter and leave the lobby.

This setup ensures race organization is smooth and that the lobby remains functional for ongoing player interactions.

Once a player enters the portal, it will close, registering that player for the race. The door will lock to prevent others from entering. This ensures the player is committed to the race and cannot leave the starting area.

Each portal registers players uniquely. This system tracks the number of participants and prevents overfilling while still allowing races to proceed even if only one player joins. It also prevents players from entering a race already in progress, ensuring participants experience the full race. While waiting for the next race, players can solve quests and explore the lobby.

2. Set Up Your Race

For the race concept you see in the above video, we created different stages for the race to provide an optimal player experience. Each stage is put in place as a safeguard, ensuring that engaged players can join the race and prevent players from going AFK, which could bar other players from joining or cause the race to never end.

• Portals: Portals serve as the first check to ensure we get players. The race can start with as few as one player or up to 10 for this example.
• Racing Holding Area: Once the player enters the race, they are teleported to a mini-lobby or racing line where other players will join. Players are locked into this area until the race starts.
• Registration: After entering the racing area, there is a countdown of around 15 seconds to allow other players to join. The UI is displayed to everyone so all players can see the timer and registration status.
• Close the Portals: Once the registration period ends, the portals are closed, preventing any new players from joining.
• Countdown: A countdown from 5 to 0 is used to get players ready for the race.
• Remove the Barrier: After the countdown, the barrier is removed, allowing players to race simultaneously.
• Timed Race: The race is timed, giving players around 3 to 4 minutes to finish. This ensures that if players go AFK, the race will naturally end, and anyone still in the racing area will be moved back to the lobby.
• Qualify: The races are split into three stages. This allows races to be modified in the future, with updates and new races planned for version 0.12. Players have 3 to 4 minutes to qualify by reaching the end of the stage. Players who qualify move on to the next stage, while those who don’t are teleported back to the lobby.
• Stage 2 and Future Stages: The process repeats for each stage. Players have 3 to 4 minutes to race to the end of the next stage, continuing until the first player reaches the final stage and wins the race.
• Checkpoints: Checkpoints are placed throughout the stages to ensure players don’t lose too much progress, reducing frustration.
• Award the Winner: The player who wins is teleported to a ceremony where they receive a unique item to show off in the lobby. Additionally, they receive a secret quest to redo the race, but this time without hitting any checkpoints.

These are the key aspects that make the race system work and ensure that the lobby system stays open. This setup allows players to come and go freely, earn coins to unlock new cosmetics, and explore the secrets of the manor.

2.a Registration Period

Once a player enters a portal, the registration period will begin. This is a timer that counts down, allowing other players to join. When the timer reaches zero, all portals close, and a “Race in Progress” sign will appear. Players will then need to wait for the next race or go to the spectator section to view the current race.

How To Implement:

1. Set Up a Timer: Create a time variable that will act as your countdown. You can set this to any duration you prefer.
2. Set Up a Teleport Message: Create a teleport message that sends the player to a new area. In the new area, check if a player is present using a trigger volume. If the trigger detects a player, send a message to start the timer.
3. Once the Timer Hits Zero: When the timer reaches zero, send a message to the asset that controls the portal’s closing (such as a door asset). This will trigger the closing animation or block, preventing further entries.
4. Actor Property: Use an actor property to make the “Race in Progress” message visible when a player is close to the door. This should feature a toggle behavior that only activates when the registration timer hits zero, ensuring the message displays at the appropriate time.
5. Reset After the Race: After the race ends, all elements need to reset. This includes reopening the doors and resetting the timer for the next group of players. Using actor properties and toggle behaviors helps automate this reset process.

2.b Countdown

While the race is happening there is a timer which means if players do not qualify in time they will be removed from the lobby. The timer gives enough time for players to qualify and to do so they need to reach the end of the stage. All players who qualify are teleported to the next stage; all the ones who did not finish will be teleported out.

How To Implement:

Set Up a Timer

• Create a timer that counts down once the race starts.
• Use a global variable for the timer to ensure it can be accessed and reset throughout the system.
• Choose a countdown duration that balances fairness for players while keeping the gameplay dynamic.

Set Up a Qualified Variable

• Create a variable to track how many players need to qualify.
• This should adjust dynamically based on the number of players at the start of the race. For example, if there are 10 players, it might start at 0/10.
• Add or remove players from this count as needed during the race.
• If the player has qualified then they should move to the next stage and the game should get ready to teleport to the next stage.
• If the qualified variable is zero, the game should reset the race instead of teleporting or preparing stage two’s logic.

Set Up Elimination

• Use a teleport system to send unqualified players back to the lobby once the timer ends.
• Trigger this teleport with a check to confirm whether players have qualified.
• Any players who haven’t qualified by the end of the race timer are removed.

Set Up Checks at Each Stage

• At the end of each stage, include a check to see if players are present in the area.
• Use a message trigger tied to the timer to verify the player count. If no players are detected (e.g., the variable equals zero), reset the race.
• These checks should run as timed events to ensure consistency across stages.

Set Up a Player Check Variable

• Create a variable to verify if players are in the race area when the stage begins.
• If players are present, proceed with the registration and race timers.
• If no players are detected, reset the race.
• Apply this logic at every stage to ensure smooth transitions and prevent issues.

2.c Victory Condition Method for Registration and Winning

In Game Maker 0.11, the victory condition has been updated to include ways to reset and trigger victory conditions, giving you more control over how a race ends. This component allows you to:

• End the race after a specific point.
• Let all players finish before the race concludes.
• Replay or loop the race

These updates provide more flexibility in managing races and victory conditions. The image below shows how to set the condition trigger, for example, using collision.

Tags: Tags can now be used to trigger the condition. This allows for team-based triggers, such as for the Red or Blue team.

Victory Types:

• Individual: This means the condition only triggers for that player, allowing others to continue racing.
• Team: This victory condition triggers when a team finishes, awarding the win to that team.
• All: This means everyone receives the victory condition, and the race ends.
• End Game: You now have the option to keep the experience running after victory is triggered. Players can choose to resume after the condition has played out.
• Message to Reset: A message can be sent to reset the victory condition to its original state, allowing it to be triggered again. This enables looping races.

Other settings are still available, such as delaying the ending if you want the experience to conclude as before.

To recap:

• Set up the race trigger however you want.
• Define your victory condition as outlined above.
• Assign any necessary tags to make the race function properly.
• Configure any additional gameplay elements, such as timers.

Using the new victory condition can streamline your process and provide flexibility in setting up a race. When using Game Maker 0.11, consider experimenting with different setups for looping or ending the race.

Qualified

When the player gets to the end of the stage, they become qualified as long as they do this within the time limit. Once qualified, the other players will have time to equally qualify. If all players have qualified, then it will move to the next stage automatically. This is why we add that variable that checks to see how many players are present and add it dynamically so we know how many need to qualify for it to move to the next stage. If the number is below the max, it will wait until the time runs out before teleporting everyone, giving everyone a chance to finish.

Winning

As the player progresses through each stage, other players are eliminated, and the final round will crown whoever finishes first. Consider making this area exclusive to the winner, offering something cool that only they can obtain, such as a golden crown. The winner is also told about a hidden quest — it’s not triggered but hinted at. This provides the player with another reason to play, but this time, it’s more challenging since they won’t have checkpoints.

3. Enhance the Player’s interaction

Since this concept focuses on social racing, consider adding social features for players to interact with. The concepts in this section include various quests and mini-games that players can engage with to enhance their experience and encourage exploration.

3.a Spectator Area

If a race is in process and players cannot enter, consider adding a spectator section. This will allow players to watch races and possibly interact with them.

The spectator area should let players view races and stay engaged while a race is ongoing. This portal remains open, allowing players to enter and leave freely. We will cover its functionality and additional considerations for player interaction in future articles.

How To Implement:

1. Set Up the Portal: Use similar assets to the race portals for consistency in design.
2. Text or Visual Cues: Clearly indicate that this is the spectator area to avoid confusion.
3. Teleport Functionality: Set up a teleporter to transport players to the spectator area (this will be explored in a future article.)
4. Keep the Portal Open: Do not close this portal. It should remain accessible to all players at any time.

This setup ensures that players can spectate races without being restricted by ongoing events.

Once inside the area, ensure the player can view the race but not join. Set up blocks or barriers to prevent them from entering the actual race space.

Consider adding ways for the players to interact. In our example, we included a small gun that fires a projectile, which applies a speed debuff if hit. However, we’ve implemented a power-level system, requiring players to unlock this feature by playing the races to prevent overuse or abuse.

The spectator section should also provide a way for players to navigate the race space. We used teleports in this example as it’s important to allow players to return to the lobby.

3.b NFT Store

Consider adding cosmetic items or collectibles for players. In this concept, players can collect coins during races and spend them to unlock cosmetic item sets. This gives players a way to customize their appearance and provides goals to work toward.

Expand the System with the On-Equip Features: Wearing a specific outfit could trigger hidden features in the manor or provide gameplay bonuses, such as speed buffs. Consider how cosmetics might influence gameplay beyond aesthetics.

How To Implement:

1. Add a Currency or Upgrade System:Integrate a currency system into your lobby, or use an XP or collectible system instead.
2. Create Item Displays: Design displays for the items players can buy and use in the game.
3. Set Up the Rule System: Create a variable to track the player’s currency. Ensure this variable is local to the player.
4. Create a Math Rule: Set up a rule to add a specific amount to the currency variable. Choose a message that triggers when the player collects a coin or collectible.
5. Design the Currency: Create the collectible asset (e.g., coins). Ensure it triggers the appropriate message on pickup to update the currency variable.
6. Set Up a Purchase Location: Design a place where players can buy outfits or items. Use a comparison rule to check if the player has enough currency: If the player has enough, allow the purchase and deduct the currency. If not, display a message informing them they need more currency.
7. Spawn Purchased Items: On a successful purchase, spawn the items for the player to collect.

3.c Mini-Games

Consider adding mini-games or other features that allow players to spend their currency to gain buffs or other interesting rewards. For example, we implemented a spinning wheel that randomly selects a result with each spin, providing a stackable speed buff. Once the race starts, the buff is applied.

This is achieved through a variable and a check to determine if the player has a speed buff, and its value, and then applying that as a speed bonus. Of course, you can customize this concept, but think about incorporating money sinks or time sinks for the player to engage with.

For multiplayer, consider how players interact and the limitations of mini-games. Use the new tag system and actor properties to assign and remove tags to trigger events for a player, instead of relying on spawning or despawning objects.

Considerations

Backup checks for player presence are essential to avoid race issues. For example, if a player qualifies but then logs out, crashes, or leaves the game, the system must confirm if any players remain in the race area. If no players are detected, the race should reset. This ensures the game doesn’t stall due to missing participants.

The logic for this system can be quite complex because it involves multiple checks, resets, and interactions. The goal is to ensure smooth transitions between stages, eliminate unqualified players, and handle unexpected situations like players leaving. Plan carefully to avoid conflicts or bugs in how variables, triggers, and timers work together.

Resetting the system is critical. Every part of the race, including variables, behaviors, timers, and teleports, needs to be reset cleanly after each session. Failing to do so can leave remnants from a previous race that disrupt the next one.

Finally, thorough testing is required. Edge cases, such as players leaving unexpectedly or triggering glitches, must be addressed. Be prepared to experiment with different methods and refine the system to ensure reliability and adaptability.

The logic should use toggles to start or stop behaviors, spawners, or message broadcasters. For example, if no one qualifies, the behaviors for stages 2 or 3 should not be toggled. Instead, a race reset message should be sent.

As mentioned, the logic is complex and beyond the scope of this documentation. There are multiple ways to approach it and you can learn more here. However, ensure the following:

• Check if players are present at all times.
• Use timers to eliminate players, preventing races from lasting too long.
• Include resets that clear all races, timers, and variables to ensure the system is ready for the next session.

Technical Limits

Currently, multiplayer has delays and latency issues. This means the server may not accurately register where a player lands after a jump or may cause rubber-banding. These issues persist in Game Maker 0.11 and will affect multiplayer performance. If players are located far from the server, the impact will be more noticeable.

To mitigate this, consider designing simple jumping sections with plenty of space. Avoid complex moving platforms or precise jumps to minimize rubber-banding and latency problems. The performance impact can be significant, so this should be carefully considered when designing multiplayer races.

Unleash Your Creativity With Game Maker 0.11

This article guided you on how to craft a social racing experience within The Sandbox Game Maker 0.11. You learned how to create a dynamic lobby where players could interact, race, and earn currency while learning about using portals for race entry, timers for registration and race duration, and actor properties to control asset and message visibility.

Check out the other articles in this series on Combination Code Behavior as a Save System and Rotate Behavior to learn more and unlock the power to transform your gaming adventures in The Sandbox.