@jeffreyrb03-gmail

Acknowledged. This will be fixed soon. Thanks

Introduction

 

When 2 users are using their own computers, they can collaborate on the same project remotely, using a new feature called “remote edit”. This is a fun experience that allows 2 people to write code together. When one person makes a change, such as adding a block or changing an input value, the other person sees the change right away. This is similar to how 2 people can edit the same Google Doc at the same time.

 
 

How to start a “remote edit” session

 

Here are the 4 steps for two users to start a remote edit session:

1. Owner User shares a new project. There are a few ways to share a project, such as sharing with everyone, sharing with friends only and sharing unlisted (no one can see it unless they have the project URL). The owner user then gives the project URL to the guest user, maybe through email or text message.

2. Guest User opens the project and clicks “Look inside” to open the project in the playground. The guest user selects the “Edit” menu on top, and then select “Request to edit”, then wait for the owner user to accept the request.

3. Owner User receives a request from the guest user, and clicks “Accept” button.

4. Guest User will receive the approval, and their project will automatically reload. This is to make sure the guest user starts with exactly the same project content as the owner user.

Here is a screen recording for what the 2 users would see on their computers (the left half is for the owner user and the right half is for the guest user):

 
After the 4 steps above, both users will be able to see and change the same project at the same time.

 
 

Making Changes

 

After the remote edit session has started, both users can make changes, such as adding/removing blocks, changing input values, etc. When one user is changing a block, that block will become greyed out on the other user’s screen, which indicates the remote user is making some changes. Users should try to avoid making changes to the same block at the same time, since the changes may conflict with each other, and only one change will be saved.

 
 

Limitations

 

There are some limits put in place to ensure the 2 users are always in sync:

1. No New Sprites: Currently, neither user can add new sprites once the session has started, and the “add sprite” button is hidden. Therefore, it is suggested that the owner user first creates all the sprites they need before starting the session.

2. Only Owner can save the project: Only the owner user can save the project, since that user still owns the project. The owner user should save the project whenever some important changes have been completed.

 
 

How to end a “remote edit” session

 

To end a “remote edit” session, either the owner or the guest user can click the red “End” button at the bottom.

 
 

Best Practices

 

Here are some suggestions on how to make use of this feature effectively:

1. Voice Communication: When the 2 users are not in the same room, it is better to have a voice communication channel, such as a zoom meeting or a phone call on the side. This can make it much easier for the 2 users to decide who will do what.

2. Division of Work: Although these 2 users can both make changes at the same time, they can not change exactly the same block at the same time. For example, if one user is updating the input parameters in a block, and the other user is deleting that block, then the result may be unexpected. It is recommended that the 2 users work on different blocks or stacks of blocks to avoid conflicts.

@tyller_

Please give it a try. I would love to hear your feedback. It is always a challenge to know when to give out the answer and when to hold it back, even for human teachers. Our current setting is to make the AI keep providing more hints when the user struggles. Hopefully, that will be good enough for most situations.

If you are looking for a particular 3D model that is not in our library, please reply to this topic. If you can include an example picture of it, it would be more clear what you are looking for. We will try to fulfill these requests as best as we can. Please make sure you do not submit duplicate requests by searching for it first.

Thanks
CreatiCode Support

Introduction

 

When you need to explain how a project should work, the best way is to make a screen recording of the stage. This short article will explain which tools you can use to record the screen, and also how to share the gif file to get a URL for it.

 
 

Screen Recording on Windows

 

If you are using a Windows computer, we recommend a free tool named “ScreenToGif”, which you can download here: https://www.screentogif.com/

Here is a short video explaining how to use it: https://www.yo utube.com/watch?v=ELfCBzN1Mtc

 
 

Screen Recording on Macbook

 

If you are using a Macbook, you can use a free tool called “Giphy Capture”: https://giphy.com/apps/giphycapture

Here is a short video showing how to use it: https://www.yo utube.com/watch?v=m-4cJMBGfS4

 
 

Share your gif file

 

Once your gif file is ready, you can share it this way:

1. Go to the “My Stuff” page at https://play.creaticode.com/mystuff, and make sure you are logged in.

2. Select “My Files” tab on the bottom left

3. Click the “+Share a New File” button on the top right

4. In the pop up window, click “Click to upload file”, and then select the gif file from your computer.

5. Click the green button that says “upload and share with the CC Attribution license” at the bottom.

After that, you will see the new file in the list of files, and then you can click “Copy file URL” button for that file, which will copy the URL to the clipboard, which would look like this: https://ccdncreaticodecom.b-cdn.net/user-files/BfemEPCxatY6MMAPs/castfireball.gif

Hi all,

Sorry there was an outage on our platform earlier this morning. Sorry about the inconvenience. Now we are back online.

CreatiCode

Introduction

 

In the costumer editor, when the costume is in bitmap mode (as opposed to vector mode), you can use the magic wand tool to select an area with similar colors, then delete the designated area or fill it with a new color.

 
 

Making a Selection

 

To make a selection, you simply need to select the magic wand tool, then click on the area you would like to select. It can be of any shape, and may even contain holes in it:

 

 
Behind the scenes, it uses a “flood fill” algorithm to expand the selected area into neighboring points, so long as their colors are similar to the point you have clicked.

Note that if your computer is slow or if the costume is big, then it will take longer for this tool to determine the selected area.

 
 

Changing the Tolerance Threshold

 

When the magic wand is selected, you can specify a tolerance threshold value. Its value is between 1 and 255, and by default, it is 5. This value represents how much difference in color it would tolerate when it tries to expand the selection area:

• When the value is low, it will make sure the selected area only contains points very similar to the point you have clicked;
• As the value increases, it will include more points even if they are more different from the starting point.

As shown, when you change this value, the selected area will be updated automatically:

 

 
 

Delete or Fill the Selected Area

 

After you have made the selection, there are 2 operations you can do with those points:

• You can click the “Delete” button or press the DELETE key to delete all of those points;
• You can also pick a color from the “Fill” dropdown, then click the “Fill” button to fill the selected area with that color.

 

@jeffreyrb03-gmail

You are right. We should allow users to submit new extensions.

However, the code snippet library should be more like backpack than extension, since it will allow users to modify the code blocks after a snippet is imported. If it is an extension, then users won’t see its implementation and also won’t be able to customize it.

@jeffreyrb03-gmail

There are already packagers like Turbowarp, which works well for generic Scratch projects. And since most of the new CreatiCode blocks don’t work offline, most likely this new packager won’t do much more compared to a Turbowarp packager, right?

So the question is whether it will be justified to dedicate manpower on this feature (as opposed to others) if it is not going to add much additional value.

@attractive-milk

Maybe you can try these ideas?

1. Click the trash bin again to make it stop yelling
2. Make random garbage items fly out of the trash bin
3. Drag and drop garbage items into the trash bin
4. Make the trash bin move to random places on the stage
5. Add multiple clones of the garbage bin of different looks.

@rubiired

That’s the idea. It shouldn’t take long once we finish the other tasks ahead of it in the queue.

 

Introduction

 
 

Candy Truck Battle is a 2D online shooting game played between two players. Each player controls a candy-themed truck that can move around, collect power-up items like Sugar and Gas, and fire donuts at the opponent.

Players control the truck using:

• WASD keys to move in 4 directions
• SPACE to shoot donuts

In this tutorial, we’ll build an AI (Artificial Intelligence) that can automatically control the truck in this game. Instead of using the keyboard, the AI will decide when to move and shoot, all by itself.

We’ll go through a series of increasingly powerful AI versions, each adding more intelligence and strategy.

Here’s a preview of what happens when two AIs face off after you complete this tutorial:

 
 
 
 
 
 
 
 
 

Version 1 - Random Walk (Difficulty: 2)

 

The first version of the AI will do something very simple: send out random movement commands. It won’t think, aim, or chase. It will just wander around randomly, like a monkey pressing buttons.

That might sound silly at first, but it’s actually very useful for two reasons:

1. It helps us set up and test the AI system early, without needing complicated logic. Once we get this working, we can improve it gradually.

2. It serves as a baseline. Any future AI we build should be able to beat this one. If not, the new AI probably isn’t very smart.

Let’s get started.

 
 

Step 1 - Remix the Game Project

 

Go to the following link and remix the original game project to create your own copy:

play.creaticode.com/projects/6858d69beb4683fb2ab03c73
 
If you’re interested in how this multiplayer game was built, you can read the detailed explanation in this tutorial.

 
 

Step 2 - Understand the Manual Controller

 

The Controller sprite is responsible for handling user input. Let’s take a look at the script that controls movement and shooting:

Here’s what the code does:

• It starts running after receiving the "start game" message.
• It enters a forever loop, constantly checking if the player is pressing any movement keys (W/A/S/D).
• If the SPACE key is pressed, it sends out a "shoot donut" message.
• If one of the W/A/S/D keys is pressed, it sends out a movement command using the "my team" message, with a value of 1–4 (up/down/left/right).
• If no key is pressed, it sends command 0 (stand still).
• It only sends a command when it’s different from the last one, to avoid spamming cloud variable updates.

 

In summary, our AI needs to:

• Send "my team" messages with movement commands (0 to 4).
• Send "shoot donut" messages at the right time.

That’s it! Once we can send those messages, we can fully control the truck without touching the keyboard.

 
 

Step 3 - Remove the Key Press Related Code

 

Let’s begin building our AI by reusing the manual controller’s loop, but deleting all the blocks related to key presses.

We end up with this stripped-down version:

Now we have a basic framework that can send commands. Next, we’ll let it pick commands at random.

 
 

Step 4 - Set a random new command

 

To make the truck move randomly, just pick a number between 0 and 4.
Each number means:

• 0 → stand still
• 1 → move up
• 2 → move down
• 3 → move left
• 4 → move right

Use the pick random block like this:

This alone is enough to make the truck wander.

 
 

Step 5 - Add a Short Wait

 

Without a delay, the loop may send hundreds of commands per second, which can overwhelm the cloud server or cause lag.

Let’s slow it down by adding a wait block. One second is a good starting point:

Now the AI will choose a new move every second.

 
 

Step 6 - Test the AI By Yourself

 

Now it’s time to test! You can run two copies of your game in your browser to simulate two AIs playing against each other.

Here’s how:

1. Open two browser windows side by side.
2. Open your remixed project in both windows.
3. In browser A:
   • Click the green flag
   • Click Create Game
      
4. In browser B:
   • Click the green flag
   • Click Join Game using the same session ID
      
5. In browser A:
   • Click Start Game

Now both trucks will begin moving randomly!

Here’s what that looks like:

This is a working AI. It’s not smart, but it’s alive. And now that you’ve built this, you’re ready to level up and give your truck a brain.

 
 
 
 
 
 
 
 
 

Version 2 - Random Targets (Difficulty: 3)

 

In the second version of our AI, we’ll give it a bit more purpose: instead of randomly pressing movement buttons, it will now pick a random target location and attempt to move there.

This small change makes the AI appear more intentional, even though it’s still completely blind to rewards, opponents, or obstacles. In future versions, we’ll replace the randomness with smarter decision-making.

 
 

Step 1 - Prepare for the new version

 

We will duplicate the code from Version 1 and modify it.

1. Detach the old random command block.
2. Keep the basic loop and message-sending logic.
3. Remove the block that picks a random number (0–4).

The structure should now look like this:

 
Don’t forget to disconnect the existing code from version 1. Otherwise it will keep sending random commands.

 
 

Step 2 - Initialize with a random target location

 

We’ll choose a random position on the stage as our target. Use two new variables: target x and target y. These should be initialized before the loop starts.

Make sure the coordinates are within the stage boundaries:

 
 

Step 3 - Calculate X and Y Distances

 

To move toward the target, the AI needs to compare the truck’s position to the target’s position.

You can use the following sensing block to get the X and Y coordinates of the truck. Make sure to reference the correct clone ID, which matches the player’s my team value.

At the start of each loop iteration, calculate and store the horizontal and vertical distances:

 
 

Step 4 - Pick a New Random Target Upon Arrival

 

If both distances are small (e.g. less than 20), the truck is close enough to its target. In that case, we’ll pick a new random target.

 
 

Step 5 - Compare Distance X and Distance Y

 

To decide whether to move horizontally or vertically, we compare the absolute value of the distances. Whichever is larger becomes the axis we move along.

 
 

Step 6 - If Horizontal Distance is Larger

 

If the distance is wider horizontally, then we move left or right depending on whether the truck is to the left or right of the target.

This version of the AI will go horizontally first in this case.

To decide left or right, check the sign of distance x:

 
 

Step 7 - If Horizontal Distance is Smaller

 

Otherwise, vertical distance is larger, so we’ll go up or down based on the sign of distance y:

 
 

Step 8 - Test with No Trees

 

To test if our AI is working properly, we will make some adjustments to the project:

Remove Trees

 
In the Setup sprite, change the tree count to 0. This is because our truck can not avoid trees yet, so it would get stuck at a tree forever.

 

Display variables

 
Show these 4 variables on top of the stage, so we can check the truck’s movement against these variables:

 
Now run 2 instances side by side. You’ll see the trucks moving directly toward randomly chosen spots:

 
 

Step 9 - Fix the Deadlock Issue

 

You might notice that sometimes a truck gets stuck at the target, going back and forth near the target point but never switching to a new target.

Here’s what that looks like:

 
Can you think about what the reason is?

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

The reason for this issue is the wait time in the loop. Here’s what’s happening:

• Truck is 30 steps from the target → moves forward
• The truck moves 80 steps in one second
• It overshoots → next time it’s 50 steps away, but on the opposite side
• This repeats endlessly

The Solution:

Lower the wait time. Set the wait block to 0.2 seconds or even smaller. This way, the AI updates its movement more frequently, and doesn’t overshoot as easily.

 
 
 
 
 
 
 
 
 

Version 3 - Random Targets or Attacking (Difficulty: 3)

 

In this third version of our AI, we add the ability to switch between two behaviors:

1. Wandering to a random location (as in Version 2);
2. Attacking the opponent truck directly.

This change brings the AI to life. It now uses the second message type, shoot donut, and can actually cause the game to end, unlike before where both trucks wandered forever.

 
 

Step 1 - Refactor the Code for Random Target

 

Start by duplicating the AI code from Version 2.
We’ll extract all the logic related to reaching random targets into a custom block called wander.

This simplifies the main loop to:

And the wander block contains the logic we moved:

 
 

Step 2 - Define the mode

 

The AI can now be in one of two modes: "wander" or "attack". We’ll create a new variable mode, and initialize it to "wander":

 
 

Step 3 - Switch to “attack” mode

 

Instead of picking a new random target after reaching one, we now switch to attack mode:

 
 

Step 4 - Define the “attack” Block

 

Define a new block “attack” to contain the logic of attacking the opponent.

Then, in the main loop, we’ll now check the mode before deciding which behavior to run:

 
 

Step 5 - Calculate Distance to Opponent

 

Inside the attack block, we calculate the X and Y distance to the opponent truck using clone ID 3 - my team: For example, if my team is 1, then the opponent’s ID is 3 - 1 = 2.

 
 

Step 6 - Check If We can make a shot

 

We are ready to shoot if the opponent is aligned horizontally or vertically with our truck (i.e., the distance in the X or Y direction is less than 15):

 
 

Step 7 - Move to Align with the Opponent

 

Let’s work on the logic to move to the target first, since we already have code doing similar things.

We can first duplicate the logic from the “wander” block, which looks at whether the vertical or horizontal distance is larger and turns the truck accordingly:

 
However, we will make one change: when the horizontal distance is larger, we should move our truck vertically, since it is faster to align horizontally to make a shot.

For example, in this situation below, we should move the yellow truck down, then fire the shot horizontally:

 
The code change is very simple. We just need to swap the 2 “if-then-else” blocks:

 
 

Step 8 - Turn to the Opponent

 

To shoot at the opponent, we need to first turn our truck towards it. Let’s define a new block turn to opponent. It turns out this is exactly the same logic we used for moving the truck towards the target position:

 
We will use it in the “attack” logic:

 
 

Step 9 - Send out the movement command

 

The turn to opponent block sets the command, but doesn’t send it. So send it now:

 
 

Step 10 - Take a Shot

 

After turning, wait briefly so the truck finishes its turn, then fire the shot:

 
 

Step 11 - Switch back to “wander” mode

 

After firing, the AI goes back to wander mode and picks a new random location:

 
 

Step 12 - Testing

 

Keep trees disabled in the Setup sprite.
Show the mode variable on screen to visualize what the AI is doing.

Here’s how it looks in action:

 
 
 
 
 
 
 

Improvements

 

Version 3 completes the core loop of wander → attack → wander, allowing the game to reach an actual ending. But it’s still a pretty weak AI. Let’s look at a few obvious improvements.

1. Smarter Target Switching

Currently, the AI only switches to attack mode after arriving at a random target. But it may have had a clear shot on the opponent midway through wandering.

Fix: Constantly check if it’s aligned with the opponent, even during wander, and switch to attack instantly if possible.

2. Dodging After Attacking

After shooting, the truck just picks a new random target — which might keep it in the line of fire.

Fix: After firing, pick a target that’s not in the same row or column as the opponent.
Or define a third mode: escape, and cycle like this:
wander → attack → escape → wander …

3. Combo Firing

Once the AI aligns with the opponent, it only fires one shot.
But it may be better to fire multiple donuts before wandering off.

Fix: Add a cooldown timer and allow burst fire.

---

These enhancements will make your AI more competitive — especially against another AI using the same version.

In Part 2 of this tutorial, we’ll teach the AI to avoid obstacles and collect power-ups.

@the_true_odst

Sure. But it will take a while. Maybe a few weeks.

 

Introduction

 

In this tutorial, you’ll build a 2-player game called Candy Truck Battle, where two candy trucks collect rewards and fire donuts at each other. Each player controls one truck on their own computer, but they’ll both see the full game scene on their screens.

To connect the two players across computers, we’ll use the enhanced cloud variables provided by CreatiCode. Here’s a quick preview of the final result:

 
 
 
 

Module 1 - Setting Up the Game Session

 

In this section, you’ll set up a game session that connects two players running the same project on different computers. We’ll use widgets for the user interface, and cloud variables for real-time communication between the two players.

 
 

Step 1 - Remix the Starter Project

 

Start by remixing this project:

play.creaticode.com/projects/68543e0c23ae1eb9ca386f59

 
It contains everything you’ll need: trucks, trees, donuts, rewards, and other assets.

 
 

Step 2 - Display the Game Name Input

 

Open the “Setup” sprite, which manages the connection between two players.

Create a new custom block called show setup screen and run it when the green flag is clicked:

 

Inside this block, start by displaying a label and an input box:

 
The label has a fully transparent background and 0 border, so we directly see the white text over the green stage. The input box has a default value of 1234 as an example.

This game name will be used later as a “session ID” to create a new game session. Each pair of players will share a common session ID, so that the cloud variables will only be kept in sync between them. This way, players in different sessions won’t interfere with each other.
 
Here’s what it looks like:

 
 

Step 3 - Show 2 Action Buttons

 

To connect just these two players using cloud variables, one player needs to create the session and the other must join it using the same session ID.

Under the input box, add a label and two buttons:

 
Here are the blocks you’ll add inside the show setup screen block:

 
 

Step 4 - Handle the “Create Session” Button

 

When the “create session” button (“button1”) is clicked, we will first set a few key variables:

 

• Player 1 sets my team = 1 and opponent team = 2.
• Store the session ID in a variable like session input.

 
 

Step 5 - Create the Session and Handle Errors

 

Use the create cloud session block. If it fails (usually because that session ID already exists), show an error and let the player try a different ID.

 
Here’s the error message shown to the user:

 
 

Step 6 - Show a waiting message

 

If player 1 successfully creates the session, they’ll wait for the second player to join.

 
The message looks like this:

 
 

Step 7 - Wait for ☁ ready2 from Player 2

 

We’ll use the cloud variable ☁ ready2 to let player 1 know when player 2 has joined. Initially, set it to 0.

Once player 2 joins, they’ll set ☁ ready2 = 1, and player 1 will detect this change.

 

 
 

Step 8 - Handle Player 2 Joining the Session

 

When the second player clicks Button 2 (“Join Session”):

• Set my team = 2 and opponent team = 1
• Save the session ID
• Try to join the existing cloud session

If successful:

• Show a “Waiting for player 1…” message
• Set ☁ ready2 = 1 (this triggers player 1’s next step)

If it fails, player 2 probably used the wrong ID or the session isn’t created yet.

 

 
 

Step 9 - Show “Start Game” Button for Player 1

 

Once ☁ ready2 = 1 is detected on player 1’s side, we hide the setup screen and show a new “Start Game” button.

 
 

Step 10 - Start the Game

 

When player 1 clicks “Start Game,” set the cloud variable ☁ game state = 1 to let both players know the game has started.

Start with ☁ game state = 0 when the project loads:

 
Then update it when the button is clicked:

 
 

Step 11 - Wait for ☁ game state = 1

 

Once ☁ game state = 1, both players proceed.

For player 1:

 
And for player 2:

 
 

Step 12 - Show Life Count

 

After the game begins, show each player’s life count, starting at 3. Create a block called show life count:

 

• Use lives_1 and lives_2 as label names for updates.

Call this block for both players:

 

 
 

Step 13 - Recap

 

Let’s walk through the full connection process:

1. Player 1 enters a unique session ID (like “1234”) and creates a cloud session. They wait for ☁ ready2 = 1.
2. Player 2 uses the same session ID to join. If successful, they set ☁ ready2 = 1 and wait for the game to start.
3. When player 1 sees ☁ ready2 = 1, they get a “Start Game” button. Clicking it sets ☁ game state = 1.
4. When both players see ☁ game state = 1, they clear the setup screen and display lives.

To test the setup on one computer:

1. Save and share the project.
2. Open a new incognito window, log in to creaticode.com, and open the project link.
3. Arrange the two windows side by side.

Or test with a friend on a different device.

 
Here is what it looks like on 2 browsers:

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Module 2 - Adding Game Objects

 

In this module, we’ll add the main objects to the game scene, starting with the trucks and trees. To keep both players’ views identical, we’ll rely on cloud variables to make sure these objects are created in exactly the same way on both computers.

 
 

Step 1 - Broadcast the “add trucks” message

 

After the life count is displayed on both computers, we broadcast a message called “add trucks”:

 

 
 

Step 2 - Create Truck Clones

 
Switch to the Truck sprite.

Since we only use clones for gameplay, hide the original sprite when the green flag is clicked. When the sprite receives the "add trucks" message, it will create two clones, one for each player:

 
Each clone has a unique clone ID:

• 1 represents Player 1’s truck
• 2 represents Player 2’s truck

In total, there are 4 clones running across both computers: each player controls their own truck locally, and the other player sees a “mirror” clone of that truck on their computer.

 
 

Step 3 - Initialize the Truck Clone State

 

Every truck clone will start with a ☁ my state variable with a value of 0. This value indicates which direction the truck is moving:

• 0: Not moving
• 1: Moving up
• 2: Moving down
• 3: Moving left
• 4: Moving right

 
Note that the ☁ my state variable is a cloud variable, and each truck clone has its own ☁ my state variable. The value of this variable is synchronized between the 2 clones with the same ID on the 2 computers. For example:

If Player 1 sets clone 1’s state to 3 on their computer, the state of clone 1’s mirror on Player 2’s computer is also updated to 3, so the clone 1 truck will start moving left on both computers. Meanwhile, clone 2’s state is unaffected.

 
 

Step 4 - Additional Truck Initialization

 

Each truck clone should also be initialized with:

• A life count of 3
• A speed of 40 (feel free to change the speed)
• A costume based on its ID (1 for yellow, 2 for red)
• And it should be shown, since the original Truck sprite stays hidden

 
 

Step 5 - Set Starting Positions

 

Now place the two truck clones in opposite corners:

 
After running the project, you’ll see the two trucks appear like this:

 
 

Step 6 - Broadcast the “add objects” message from “Setup”

 

Back in the Setup sprite, after the trucks are added (on Player 1’s computer only), we send the "add objects" broadcast:

 
Only Player 1 sends this message. Player 1’s program will decide when and where to add the objects, and then share those details with Player 2 using cloud variables.

 
 

Step 7 - Configure the Tree Count

 

Trees are static obstacles that block both trucks and the donuts they shoot. Use the variable tree count to define how many trees to add.

Set this value in the Setup sprite:

 
Then, in the Tree sprite, when it receives the "add objects" message, it checks if tree count > 0:

 
Again, this part of the code runs only on Player 1’s computer after the “Start Game” button is clicked.

 
 

Step 8 - Generate a Tree List

 

To ensure trees appear in the same places for both players, we generate their positions on Player 1’s computer, then share them using a cloud variable.

We use the format "x_y" for each position. A list of 2 tree positions might look like:

120_-23_100_70

Here’s how to build that list step by step:

 
The tree list variable starts as empty, and then we repeatedly append a random x position and a random y position to it, all using the “_” separator.

 
 

Step 9 - Share the List Using ☁ all trees

 

Once Player 1 has the full list, assign it to the cloud variable ☁ all trees.
Then both computers will extract the same data and generate trees accordingly:

 
 

Step 10 - Create Tree Clones

 

To create each clone:

1. Extract the x and y positions from the list using the "part of by" block
2. Move the Tree sprite to that location
3. Create the clone

Each tree takes up 2 entries in the list (x and y). So tree #1 uses part 1 and 2, tree #2 uses part 3 and 4, and so on.

 

Use a loop to process each tree:

 
 

Step 11 - Hide the Original Tree Sprite

 

We’ll only use clones for the trees. Hide the original sprite and show each clone when it’s created:

Now, test the game—you should see identical trees on both screens:

 
 

Step 12 - Add Sugar objects

 

Sugar objects restore a truck’s life when collected.

Unlike trees, Sugars appear dynamically during gameplay, and may also disappear if not collected. So they’re handled differently.

In the Sugar sprite, when "add objects" is received:

• Start a loop to randomly generate Sugar positions
• Each Sugar gets a unique ID
• A cloud variable ☁ new sugar info stores "ID_x_y" for the next clone

Key points:

• IDs start at 1 and increment
• Wait a random 30–90 seconds between Sugars
• This loop runs only on Player 1’s computer

 
 

Step 13 - Create Sugar Clones

 

On both computers, whenever ☁ new sugar info changes, split it to get the ID and coordinates, then create a clone.

 
Before cloning, check the clone ID is “originalsprite” to avoid duplicate clones from existing ones.

Use the first part (ID) to uniquely identify each clone.

 
 

Step 14 - Hide the Original Sugar Sprite

 

Just like with trees, hide the original Sugar sprite and show only its clones:

 
 

Step 15 - Auto-Delete Sugar Clones

 

Each Sugar clone will wait 15–25 seconds. If it’s not collected, it deletes itself:

 
 

Step 16 - Add Gas Objects (Speed Boosts)

 

The Gas sprite works just like Sugar, but boosts the truck’s speed instead of restoring life.

Just duplicate the Sugar sprite’s code and adjust the variables:

• next gas ID
• new gas info
• Any references to “Sugar” should be changed to “Gas”

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Module 3 - Keyboard Control of the Trucks

 

Now that the game world is set up, it’s time to let players control their trucks using the keyboard. But remember, this is a two-player online game. That means when a player presses a key to move their truck, the same movement must happen in real-time on both computers.

We’ll accomplish this using cloud variables to send and sync movement commands.

 
 

Step 1 - Broadcast the “start game” Message

 

Once all objects are added and the game is ready, we need to let both players begin controlling their trucks. In the Setup sprite, broadcast the "start game" message on both computers:

For Player 1:

For Player 2:

In the Controller sprite, we’ll listen for this message and begin a forever loop to handle keyboard inputs:

 
 

Step 2 - Detect Key Press and Set Command

 

Within the loop, check which arrow key the player is pressing:

• 1: Up
• 2: Down
• 3: Left
• 4: Right
• 0: No key is pressed (stay still)

This value is stored in the new command variable.

 
 

Step 3 - Send the Command Only If It Changes

 

Since this loop runs continuously (many times per second), it could end up sending the same command over and over. That’s unnecessary and wasteful. So we’ll compare the current command to the last command sent, and only send a new command when it actually changes.

First, store the command 0 in a current command variable initially:

 
Then, compare it with the new command. If different, save this new command:

 
 

Step 4 - Send the Command to the Correct Truck

 

Each player controls one of the two trucks. Player 1 controls truck 1, and player 2 controls truck 2. On both computers, both trucks exist, so we need to ensure that only the correct truck clone receives the command from the player.

Here’s how we’ll do it:

• Use the my team variable (1 or 2) to send a message with that same number
• Attach the new command as the parameter (we have made sure this is different from before)

So Player 1 will send message "1" with the command, and Player 2 will send "2":

 
 

Step 5 - Let the Correct Truck Handle the Command

 

Switch to the Truck sprite.

All truck clones (ID 1 and ID 2) will receive the message "1" or "2", but only the clone with the matching ID should actually respond. Use an if block to check the clone ID.

Then define a custom block called handle command that will process the movement:

So if Player 1 presses a key:

• On Player 1’s computer, Truck 1 responds and updates its state.
• On Player 2’s computer, Truck 1’s mirror will also update its state.

This keeps both trucks behaving identically on both screens.

 
 

Step 6 - Set ☁ my state Cloud Variable

 

Inside the handle command block, set the cloud variable ☁ my state to the command value:

Each truck clone owns its own cloud variable. This variable is not visible to other clones or sprites locally—but because it’s a cloud variable, the value is automatically shared with the other player’s computer.

So the state of a truck is immediately synced across both computers. That’s how both players see the exact same movement for the same truck.

 
 

Step 7 - Calculate Travel Duration and Distance

 

Now we’ll build the movement loop. To ensure that truck speed is consistent across fast and slow computers, calculate how much time has passed between iterations of the loop using the timer.

Use that to determine how far the truck should travel:

For example:

• On a fast computer, the loop might run 40 times/sec, so travel duration ≈ 0.025
• On a slower one, maybe 20 times/sec, so travel duration ≈ 0.05

Multiply speed by time to get consistent movement regardless of computer speed.

 
 

Step 8 - Move the Truck Up (State = 1)

 

Now use that travel distance to move the truck in the right direction. Start by handling state 1 (move up)

 
 

Step 9 - Move in the Other Directions (States 2–4)

 

Repeat this logic for states 2 (down), 3 (left), and 4 (right):

No need to handle state 0 directly—if no key is pressed, the truck simply doesn’t move.

 
 

Step 10 - Undo Movement if Hitting a Tree or Edge

 

If the truck hits a tree or touches the edge, immediately reverse the last movement:

 
Put this logic at the top level inside the loop, so it always runs on every frame, regardless of what state the truck is in.

 
 

Step 11 - Sync Position When Truck is Idle (Command = 0)

 

Even with identical movement commands, trucks can drift out of sync over time due to slight timing delays. Here’s why:

Imagine Player 1 moves the yellow truck up, then presses right. The command is instantly executed on Player 1’s computer. But there’s a small delay (maybe 0.1 seconds) before that command reaches Player 2. So on Player 2’s screen, the yellow truck moves slightly farther up before turning.

To fix this, whenever a truck receives command 0 (no movement), we broadcast its exact position to the other computer using a cloud variable ☁ my x y (formatted like "x_y"

 
Then, when the other computer receives this update, the matching truck clone updates its position smoothly:

This ensures both versions of the truck stay visually aligned.

 
 

Step 12 - Sync Position When Truck Hits Obstacle

 

When a truck hits a tree or an edge, it should stop moving—and sync its corrected position to the other computer. You can reuse the handle command block by calling it with command 0.

But only the truck being controlled locally by the player should do this, because only that version has the accurate position. Add this logic inside the collision detection block, not at the top level:

Now, both players will always see exactly the same movement, even when a truck hits trees or stop moving.

Here’s a demo of it in action:

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Module 4 - Collecting Items

 

In this module, we’ll enable the trucks to collect Sugar and Gas items, which can increase the truck’s life or boost its speed. When a truck picks up one of these items, we need to make sure the effect happens only once, and that it syncs across both computers.

This means the item should disappear at the same time on both screens, and the truck’s speed or life must update only on the player’s own truck (not the mirrored one).

Let’s go step by step.

 
 

Step 1 - Detect Touching the Sugar

 

Start in the Truck sprite.

We’ll use the “when touching [object]” block to detect when the truck touches a Sugar clone. But there’s an important detail: each computer has two trucks (clone ID 1 and 2), and we only want the truck controlled by the local player to handle the collection.

So first, check that my team matches the truck’s clone ID. That ensures only the player’s truck reacts:

If you don’t do this check, both the original truck and its remote mirror might react, and the item could be collected twice incorrectly.

 
 

Step 2 - Notify Which Sugar Was Collected

 

When a Sugar item is collected, we want both computers to delete that Sugar clone. Since each Sugar clone has a unique ID, we can use a cloud variable to broadcast that ID.

Set ☁ sugar being collected to the ID of the clone that was touched:

Once this variable changes, every copy of the Sugar sprite (on both computers) will be notified.

 
 

Step 3 - Increase Truck’s Life (Max 3)

 

After collecting a Sugar item, the player’s truck should gain one life—but only if its current life is less than 3.

Here’s the code to do that:

 
This check prevents the truck from going above the max life limit.

 
 

Step 4 - Delete the Correct Sugar Clone

 

Now switch to the Sugar sprite.

We want only the clone with the matching ID to delete itself when ☁ sugar being collected changes. Use the when [cloud variable] changes hat block, and compare the clone’s ID with the new value:

 
This event runs on both computers, but only the matching clone actually deletes itself.

To make this detection work reliably, set ☁ sugar being collected to an invalid ID at the beginning of the game, like -1 or "none":

 
If you skip this step, the first clone might mistakenly delete itself before anything has been collected.

Now test it out: try adjusting the Sugar spawn delay to appear more frequently so you can quickly see the effect during testing:
 

 
 

Step 5 - Handle Touching Gas Objects

 

Back in the Truck sprite, we’ll use similar logic to handle collecting Gas objects. These do not increase life—they increase the truck’s speed instead.

Duplicate the Sugar collection code and change it to work with Gas. When touched, increase the speed variable of the truck:

 
Again, remember to only allow the local player’s truck to trigger the collection.

 
 

Step 6 - Delete the Gas Clone

 

In the Gas sprite, add logic similar to Sugar. When the cloud variable ☁ gas being collected changes, compare its value to each clone’s ID. If it matches, delete the clone:

 
And just like with Sugar, initialize this variable to an invalid value at the start:

 
This avoids accidental deletions or unexpected behavior.

Once you’ve added this code, try testing the collection of both Sugar and Gas. Make sure:

• Only one truck can collect the item (not the mirror)
• The effect applies only to that truck
• The item disappears on both screens

This logic is essential for keeping both players’ games perfectly in sync.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Module 5 - Shooting Donuts

 

In this module, we’ll let players shoot donuts from their trucks. Donuts travel in a straight line and disappear when they hit a tree, the edge of the stage, or the opponent truck. If a donut hits the opponent’s truck, it will lose a life. As always, everything must stay synchronized between both players’ computers.

Let’s walk through each part of the shooting mechanic.

 
 

Step 1 - Detect SPACE Key to Fire

 

In the Controller sprite, add a condition to detect when the player presses the SPACE key. When that happens, broadcast a "shoot donut" message.

 
 

Step 2 - Only Original Donut Handles the Message

 

Switch to the Donut sprite. When the "shoot donut" message is sent out, it will be received by both the original Donut and all its clones. So, add a check to make sure only the original sprite handles it:

 
 

Step 3 - Limit Shooting Frequency

 

To prevent players from spamming the SPACE key, introduce a cooldown. Create two variables:

• donut_time: last time a donut was fired
• donut_interval: minimum wait time between shots (e.g., 1 second)

Initialize them like this:

 
And check the current timer value before allowing a new shot:

 
 

Step 4 - Get truck position and direction

 

A donut should appear at the front of the truck, facing the same direction. Use the sensing blocks to get the x/y position and direction of the truck the player is controlling:

 
Use my team to access the truck clone ID that matches the player.

 
 

Step 5 - Track Donut ID

 

Each donut clone should have a unique ID. Use a variable next donut ID, initialized to 0:

Increase it by 1 with each new shot:

 
 

Step 6 - Create ☁ new donut command

 

Use a cloud variable ☁ new donut command to let both computers know a new donut was fired.

Its format will be:

playerID_direction_x_y_donutID

Start with the direction 90 (right). Offset the x-position by 35 so the donut doesn’t touch the truck that fired it:

 
 

Step 7 - New donut commands for the other three directions

 

Repeat the same logic for directions:

• 0 (up): adjust y
• 180 (down): adjust y
• 270 (left): adjust x

 
 

Step 8 - Handle updates in ☁ new donut command

 

When the cloud variable ☁ new donut command changes, both computers will create a new donut clone.

Make sure only the original Donut sprite handles this:

 
 

Step 9 - Extract Donut Info

 

Split the command string into 2 parts and store them:

• owner team: the shooting player
• my direction: the direction the donut should move in

 
 

Step 10 - Move Donut to Position and Set Angle

 

Move the original Donut sprite to the target position and direction. The clone will inherit this when it’s created:

 
 

Step 11 - Create the Donut Clone

 

Now create the donut clone. Its ID will be a combo of the player’s ID and the sequence number:

 
 

Step 12 - Set Costume by Team

 

Set the donut costume based on the player who fired it:

 
 

Step 13 - Hide the Original Donut Sprite

 

Only clones should be visible. The original Donut stays hidden:

 
 

Step 14 - Calculate Travel Distance Based on Timer

 

Just like trucks, donuts should move consistently across fast and slow computers. Use the timer and a constant speed (e.g. 150) to calculate how far each donut moves every frame:

Each clone tracks its own prev time and travel distance.

 
 

Step 15 - Move the Donut

 

Move the donut in its set direction using the calculated distance:

 
 

Step 16 - Delete on Tree or Edge (Only on Owner’s Side)

 

Only the player who owns the donut should check for collisions (to avoid false positives due to lag). If a donut touches a tree or the edge:

• Set ☁ donut to delete to its ID
• Both computers delete the clone when this variable updates

 
 

Step 17 - Detect Hitting the Opponent

 

If the donut hits the opponent truck, do the same thing: set a cloud variable ☁ donut hitting target to the donut’s ID:

 
 

Step 18 - Delete the Donut

 

In the Donut sprite, when ☁ donut to delete updates, each clone compares its ID and deletes itself if it matches:

 
 

Step 19 - Handle Opponent Hit

 

Similarly, when ☁ donut hitting target changes, the matching clone:

1. Sends a truck hit message with the opponent truck’s ID. For example, if this clone’s team is 1, then the opponent team’s ID is 2 (3 - 1).
2. Deletes itself

 
 

Step 20 - Truck Handles “truck hit”

 

In the Truck sprite, handle this message carefully:

Only the truck that got hit, and only on its own player’s computer, should reduce its life by 1.

Use two checks:

• clone ID = truck being hit
• my team = owner of this truck

 
Then update ☁ my lives, which is mirrored on both computers.

 
 

Step 21 - React to Changes in ☁ my lives

 

Each truck that shares that cloud variable will react when ☁ my lives is updated.

Make sure the game has started (game state is 1):

 
 

Step 22 - Compare Life Count

 

Use a separate variable prev my lives (initially 3) to compare the new life count to the previous one:

 

 
 

Step 23 - Play Sound Effect

 

Play different sounds for gaining vs. losing lives:

 
 

Step 24 - End the Game if Lives = 0

 

If the truck’s life count drops to zero, end the game. This check happens on both computers:

 
 

Step 25 - Show the Winner

 

Before stopping the game, show a message announcing who won:

If truck ID = 1, then player 2 wins. If it’s 2, then player 1 wins:

 
Here is a full demo of the game:

 
 
 
 
 
 
 
 
 
 

Additional Challenges

 

The game you’ve built so far is a fully functional 2-player battle, but there’s plenty of room to expand and experiment. The main goal of this project was to demonstrate how cloud variables and clones can be used to build a multiplayer game where each player runs the same project on their own computer, and everything stays in sync.

Once you’ve got the basic mechanics working, here are some ways you can extend and improve the game. These ideas range from simple tweaks to major redesigns—try one or try them all.

---

Firepower Reward

You’ve already added Sugar and Gas as collectible items. Now try adding a third type of reward that affects the player’s shooting ability.

What to do:

• Create a new sprite for a Firepower item
• When collected, reduce the cooldown time between donuts (e.g., from 1 second to 0.5 seconds)
• Use a new cloud variable to sync this change across both computers
• Maybe even show a temporary fire effect or shooting animation

This reward adds more strategy and makes collecting items more impactful.

---

Shrinking Arena

To prevent players from hiding or running away forever, you can create a shrinking play area—similar to battle royale games.

How it works:

• Add invisible wall sprites that slowly move inward from the edges of the stage
• These walls can appear every 10 seconds or after a certain time has passed
• If a truck touches a wall, it loses a life or takes damage

This forces players toward the center of the stage over time, making the game more intense and guaranteed to end eventually.

---

2 vs. 2 Team Game

This is a major upgrade: turn your 2-player battle into a 4-player team battle, with two players on each team.

What changes:

• Four players will join the same cloud session, each with their own truck (clone IDs 1 to 4)
• Players 1 and 2 are on Team Yellow, and Players 3 and 4 are on Team Red
• Each player only controls their own truck, but it has 3 mirror trucks on the other 3 computers
• Donuts can damage players from the opposite team, but not teammates
• The game ends when both trucks from one team have lost all their lives

What you’ll need to update:

• Session setup screen to support 4 unique player IDs
• Truck spawning logic to handle 4 clones and assign them to teams
• Donut logic to check for friendly fire and block it
• Life tracking and win condition logic to check if both teammates are eliminated
• Display a win message like “Red Team Wins!” when the condition is met

@the_true_odst

Most likely there are too many messages in the chat history or output.

Please check this document: https://www.forum.creaticode.com/topic/867/ai-openai-chatgpt

---

Introduction

---

Flappy Bird is a simple and fun game, where the player controls the bird to fly through a few obstacles to reach its nest. There is only one control: press the SPACE key to make the bird flap.

In this tutorial, you will learn to build a simple AI program to control the bird instead of manually.

Note that this AI will be based on programming logic, rather than large language models (LLMs). That is due to 3 reasons:

• LLMs are too slow for such tasks: it usually takes a few seconds for LLMs to respond to each request, but we need to make the bird react and flap with a precision of milliseconds.
• LLMs are too unpredictable: LLMs are inherently random, and it is often hard to control them to generate precisely the same output every single time. In contrast, programming logic is much more predictable and reliable.
• LLMs are too expensive: It takes a lot of computation, and hence energy, to generate even a very simple output. To avoid such waste, when we can use programming logic to make a decision, we should do so.

The same argument also applies in many other situations, and that’s why a significant portion of AI systems will continue to be implemented using programming logic.

Now let’s get started with this simple AI program.

---

Step 1 - Remix the Starter Project

---

Open this link and remix the project:

play.creaticode.com/projects/684dbd401c49cae4509533bd

---

Step 2 - Read the Existing Code for “AI”

---

In the “AI” sprite, there are 2 stacks of code.

First, when the green flag is clicked, 3 parameters are set:

• How many columns (green pipes) are placed before the nest.
• The gravity for the bird’s falling speed;
• How much the bird rises up on each flap.

Below that, when the “start” message is received, this AI program will simply send out the “flap” message every 0.3 seconds. Each “flap” message will make the bird flap once. This is the most basic AI program, which we will improve in the next few steps.

---

Step 3 - Adjust the Game Settings

---

When you click the green flag, you will find that the bird will fall to the ground. The falling speed will depend on your computer, but it will look similar to this:

---

This is because the “gravity” and “flap strength” are not fine-tuned yet. As an exercise, please adjust these 2 values. In general, “gravity” should be a number between 0 and -2 (such as -0.5), and “flap strength” should be a number between 4 and 20. Your goal should be to make the bird fly horizontally with a nice waveform trail like this:

---

 

 

Step 4 - A Shorter Wait Interval

 

Currently, in the forever loop, we send out the “flap” message every 0.3 seconds, and the bird will stay at the same height. Suppose we want the bird to fly higher, then we need to use a shorter interval.

Instead of 0.3 seconds, let’s use an interval of 0.03 seconds. This may be necessary if the bird needs to rise up very quickly.

As a result, when you run again, the bird should reach the ceiling very quickly and stay there:

 
 

Step 5 - Skip some flaps

 

Obviously, the current AI always makes the bird fly too high. A simple solution is to skip some flaps, so the bird will do a free fall to reach nests that are below its level.

In general, to make smart decisions, an AI needs relevant sensing data. In this case, to determine whether the bird needs to fall a bit, we can compare these 2 variables:

• The bird’s Y position
• The Y position of the nest

Your AI can access these 2 values using these 2 reporter blocks:

 

Now, can you change the forever loop so that the bird would not flap if it is already above the nest?

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Here is one way to do it: we put the broadcast block inside an “if-then” block, so only when the nest is above the bird would the bird make a flap:

Try to run the program a few times. The nest is placed at random heights, but the bird will almost always rise or fall to its level quickly:

 
 

Step 6 - Add a few columns

 

Now let’s move on to the next challenge: make the bird fly through the columns (pipes). Change the “columns” variable to 4, which will add 4 columns:

Obviously the bird will crash with the columns and fail. What can we do?

 
 

Step 7 - Fly through all columns

 

Similar to above, we need to provide data to the AI. Specifically, here are information about the columns:

1. Each column has an opening at its center, and the Y positions of these openings are stored in the list named “columnYs”.
2. The number of columns is given in the variable “columns”.
3. The upcoming column has an index of “nextColumnIndex” in the list. For example, when the bird is facing the first column, nextColumnIndex is equal 1. After the bird flies through it, nextColumnIndex will automatically increase to 2.

With these information, can you try to make the bird fly through all the columns? Don’t worry about the nest for now.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

In fact, all that we need to do is to replace “nestY” with the Y position of the upcoming column:

 

The bird should have no problem flying through all columns:

 

 

Step 8 - Fly to the nest after all the columns

 

For our last step, we need to combine our solution for columns and the nest. When the bird has passed the last column, the nextColumnIndex will be more than the columns variable, and that’s when we should target the nest instead. Can you implement this change?

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Here is an example solution:

Here is the final demo:

 
 

Extra Practices

 

To practice what you have learned, here is an additional challenge for you.

Currently, the bird would only start flapping if it is below the target height (of the nest or the center of the opening), so it might fall too much below the target. If the target is very low, then the bird might touch the ground before flying back up.

To ensure the bird is always safe, it should start to flap if it is too close to the ground (Y of -240).

@tyller_

Currently, the playground already supports both:

• Ctrl + Wheel: zoom in or out
• Shift + Wheel: scroll left or right

And these are the same for MIT Scratch.

Hi all,

We have made some exciting new enhancements to cloud variables. The description is on this page: https://www.forum.creaticode.com/topic/1997/newly-enhanced-cloud-variables

We will post new tutorials on multiplayer games using this new feature as well. Please feel free to give us your feedback on this.

Thank you
CreatiCode

@the_true_odst

Got it. We’ll check why it happens on chromebooks.

Introduction

 

Cloud variables are a powerful tool in MIT Scratch for creating multiplayer programs. CreatiCode has enhanced them further, making them even more capable. In this tutorial, you’ll learn how cloud variables work in the CreatiCode playground.

 
 

Basics of Cloud Variables

 

When creating a new variable, you can check the “cloud variable” box:

If the project is shared and opened by other users, the value of that cloud variable will be synchronized across all their computers automatically.

For example, imagine 10 users are running the same project at the same time. If one user changes the value of a cloud variable, the other 9 users will instantly see the updated value.

Here’s what happens behind the scenes:

1. User A changes a cloud variable using a “set variable to” or “change variable by” block.
2. User A’s computer sends the new value to the CreatiCode server.
3. The server broadcasts the update to the other 9 users running the same project.
4. Each of those computers receives the message and updates the cloud variable’s value.

 
 

A Simple Example

 

Here is an example project: play.creaticode.com/projects/68473cea3d952dd83a76d160

It has one dog sprite with this code:

When the program starts, the sprite keeps saying the value of the cloud variable “counter”.

Whenever any user clicks the sprite, the value of “counter” increases by 1, and all other users running this program will instantly see the new value.

You can test this by opening the project in two browser windows (one normal mode and one incognito mode). Make sure you’re logged in, as cloud variables only work when you’re signed in. Of course, you can also try this with a friend on 2 computers.

Here’s what it looks like across two browsers:

 
 
 
 

The “When Variable Changes” Block

 

To make working with variables easier, especially cloud variables, CreatiCode has added a new event block:

 

This block is triggered whenever the selected variable changes, i.e., when its value becomes different. Note that if you set a variable to its current value (hence no change), then this block won’t be triggered.

It works with both regular and cloud variables. This means you no longer need a forever loop to constantly check the variable — you can run code only when the value actually changes.

Here’s how we can rewrite the earlier example using this block:

1. When the sprite is clicked, increase the counter as before.
2. When the counter changes, the sprite says the new value.

---

You can try it here: play.creaticode.com/projects/684747163d952dd83a76d79c

 
 
 
 

Number of Cloud Variables

 

MIT Scratch limits you to 10 cloud variables per project. In CreatiCode, you can use up to 100. This allows you to build much more advanced multiplayer projects.

 
 
 
 

Accepted Values and Update Frequency

 

In MIT Scratch, cloud variables:

• Can only store numbers
• Can only update any variable at most 10 times per second

For example, suppose your project has 2 cloud variables, then if within any second, your code updated them more than 10 times, then the extra updates will be ignored.

These limits were put in place to block users from building chat rooms, but they also make cloud variables harder to use.

In CreatiCode, cloud variables support any type of value, with some important rules:

• If the value contains any letters (a–z), it must pass a moderation check to filter inappropriate content. Also, such values can only be updated once per second per user. That’s still fast enough for chat room projects.

• If the value does not contain letters, and only contains numbers or symbols, like 120 or "1_23_44", it bypasses moderation and can be updated up to 20 times per second per user. This is useful when you want to send multiple numbers in a single update. For example, to send X = 50 and Y = 80, you can combine them into one value of "50_80". Also, CreatiCode does not drop any updates. Instead, these updates are queued and sent out at intervals of 50ms.

 
 
 
 

Cloud Sessions

 

In MIT Scratch, everyone running the same shared project receives the same cloud variable updates. For example, suppose you share a multiplayer game, then all users who run this game at the same time will receive the same updates. To isolate groups, you’d have to make separate copies of the project.

CreatiCode introduces cloud sessions, which limit cloud updates to just the users in the same session. If a user hasn’t joined a session, they’re placed in the default session.

To use sessions, one user has to create one with a unique name first, then other users can join that session with the same name. Here are the2 blocks from the “Variables” category for doing so:

 
The session name is just a string that users agree to use. Only users in the same session will receive each other’s cloud variable updates. These blocks are boolean blocks, since they will return true or false depending on whether the action is successful.

Here’s an example program that shows how to use these blocks:

 
To run this program:

• First, one user needs to create a session named “579”
• All other users can then join the same session using the same name.
• After that, only these users will see each other’s updates to the “counter” variable.

The project is shared here: play.creaticode.com/projects/6847509b3d952dd83a76dbfb

 
 
 
 

Private Cloud Variables for Clones (Advanced)

 

In MIT Scratch, cloud variables are always global: shared across all sprites and clones. This creates problems when you’re working with clones.

For instance, suppose a car sprite creates 2 clones: Clone 1 and Clone 2. If you use a global cloud variable like “facing direction,” then changing it to 90 will affect both clones, even if you only meant to rotate one.

To fix this, CreatiCode lets you create private cloud variables for each sprite or clone:

 
Now, each clone will have its own “direction” variable, separate from the others. For example, when one user updates the direction variable for “Clone 1”, then the direction will be updated for “Clone 1” running on all other computers, yet “Clone 2” will not be affected on any computer.

 
 
 
 

Example for Private Cloud Variables

 

Here is an example project: play.creaticode.com/projects/6847575f1c49cae45091d685

When the green flag is clicked, the original dog sprite hides and creates two clones, with IDs 1 and 2:

 
When born, each clone shows itself, says its clone ID, and moves to one side of the stage:

 
Now, when a clone is clicked, it increases its own private cloud variable called “direction” by 15. This triggers only that clone to rotate:

 
As a result, when any user clicks on a dog clone, that specific clone rotates on every computer — but the other clone is unaffected:

---

---

---

---

We hope you enjoy these new features, and we can’t wait to see the amazing multiplayer projects you’ll build with them!