@tng

Can you share an example program or project? thank you

@tng

Can you please share the project link?

@jamesa-blackwell-57b383d3

You mean a folder that contains other sprites or folders, right? That’s an interesting idea. Would it be something like this?

1. You can create an empty folder
2. You can drag any sprite into a folder
3. You can double-click to open a folder, so you see the sprites inside that folder only
4. You can move up to the parent folder by double-clicking the up arrow.

@dreamsmp_luck

We will ban his account more.

@sanicplushshow

Maybe you can get help from your parents or teacher? Please keep in mind that this is a public forum for coding-related topics only.

@dreamsmp_luck

That’s the minimum requirement.

@sanicplushshow

Your old account has been banned for 24 hours due to posting topics not directly related to coding. It will be available after that, but please stick to coding related topics. thanks

@dreamsmp_luck

That’s for experienced users who answer lots of questions on the forum.

@wollowtaff

Thank you for the suggestion. To clarify, are you saying the code blocks themselves do not need to be in Polish?

@dreamsmp_luck

Great!

@dreamsmp_luck

Please see https://www.forum.creaticode.com/topic/1093/creaticode-xo-ai-assistant-explain-to-me

@dreamsmp_luck

So what did XO say when you ask this?

“when I press the up arrow, the character does not jump up, why?”

@dreamsmp_luck

Great. Then you can try to ask XO a follow-up question like this:

when I press the up arrow, the character does not jump up, why?

@sonicplushshow

Can you please reply to your existing topic instead of starting many new topics?

It is hard for others to see so many new topics.

Thank you
CreatiCode

@sonicplushshow @dreamsmp_luck

Can you please reply to your existing topic instead of starting many new topics?

It is hard for others to see so many new topics.

Thank you
CreatiCode

@dreamsmp_luck

It is hard to tell without the rest of the program. Have you try to ask the AI assistant? See https://www.forum.creaticode.com/topic/1093/creaticode-xo-ai-assistant-explain-to-me

@sonicplushiesc4

The key is to press the camera button when the stage is showing exactly what you want as the thumbnail.

@sonicplushiesc4

This project shows a dog saying hello right? So when it says Hello, you can press the button to update the preview. It will become this:

@kirbstyre_63

Most likely, we will implement a system similar to MIT Scratch’s “messages” (https://scratch.mit.edu/messages). But this is currently behind other more urgent tasks.

@sonicplushiesc4

If it is not working, can you share the project link? And you pressed that button while the project is running?

@sonicplushiesc4

You can use this camera button on top of the stage to update the project preview:

@sirbots

We have added 2 new blocks to make it easier to work with clones. Please check them out there:

https://www.forum.creaticode.com/topic/2032/2-blocks-to-scan-for-clones

 

Introduction

 

In game projects, clones are commonly used to create objects like enemies, obstacles or powerups. However, it is not easy to scan for them in our code, which is often needed when we need to do something clever, such as “find all the enemies near me”, or “check if I have a clear line of fire”.

In CreatiCode, every clone has a clone ID, and the original sprite can also be treated as a clone with an ID of “originalsprite”. There are 2 new blocks that can be used to scan for clones of a given sprite: one is simply based on distance from this sprite, and the other based on a scan area.

 
 

Find Clones by Distance

 

You can use this sensing block to find clones of a given sprite within the given distance from this sprite, and save their information in the given table:

 
Notes:

• You can pick any sprite, even this sprite itself
• The original sprite can also be treated as a clone, with a clone ID of “originalsprite”.
• The distance is the direct-line distance between this sprite and each clone of that sprite, calculated using their x and y positions.
• If any clones are found within this distance, they are listed in the table in order of increasing distance (nearest first). The table will always have at least 4 columns: clone ID, x, y and distance. If the clone has any private variables, they will also be added as additional columns.

 
 

Example

 

Here is an example program showing how it works: play.creaticode.com/projects/685e804081a45ef495ae5fdf

 
In the Tree sprite, we create 5 clones of the tree. Each clone will go to a random position, generate a “secret” that is private to itself, and then say its clone ID to identify itself.

 
So on stage, you will see 6 tree objects like this:

 
Now, in the Truck sprite, we can use this sensing block to find trees that are with 100 units distance from the truck:

 
Then we can look at the content of table1:

 
As shown, there are 3 clones whose distance is less than 100 from the truck.

The nearest clone is the original tree sprite, which is at x of 0 and y of 0. It is about 64.85 units away from the truck.

The second nearest clone is the one with ID of “clone_3”. It is a bit further away, and its secret is 78.

You can try to change the distance threshold or drag the trees around, and observe how table1 changes. For example, when the distance threshold is very large, all clones should be listed in the table; and when it is very small, the table should become empty.

 
 
 
 
 
 
 

Detect Blocking Clones in the Forward Direction

 

Another very common question we need to ask is whether there are obstacles in front of our sprite, which may block our sprite’s movement or block the shots it fires.

One way to do this checking is to use the block above to find all clones on the stage, and then check the position of each of them. But the calculation become more complex when the sprite is facing an angle (not straight left/right or up/down).

Instead, you can use the following block for this task, which defines a rectangle “scan area” in front of this sprite, and list any clone of the given sprite it finds in this area in the given table.

Notes:

• You can pick any sprite, even this sprite itself
• The original sprite can also be treated as a clone, with a clone ID of “originalsprite”.
• The distance is going forward along this sprite’s current direction. So if this sprite is facing 45 degrees, you can imagine it moves forward along this direction for 200 units, and check if there are any clones that’s 20 (half of 40) units away on the left or right side.
• If any clones are found within this distance, they are listed in the table in order of increasing distance (nearest first). The table will always have at least 4 columns: clone ID, x, y and distance. If the clone has any private variables, they will also be added as additional columns.

 
 

Example

 

Here is an example program showing how it works:

play.creaticode.com/projects/685e928081a45ef495ae82c0

 

The truck is facing -30 degrees (upper left direction). In the Tree sprite, 2 clones are created in a similar way.

You can drag them to a formation like this:

 
The original tree sprite is directly on the forward path of the truck. The clone 2 is slightly blocking the path on the right side, and clone 1 should not be a blocker.

 
Now, suppose we run this block in the truck sprite:

 
The detection area will be 200 by 70 in front of the truck:

 
The table1 will contain 2 rows:

 
Explanation:

• The center point of both the original sprite and the clone 2 are inside the red rectangle, so they are included in the result table.
• For clone 1, although its edge touches with the red rectangle, its center point is outside the rectangle. Since we only look at the x/y position of each clone, and not their size, the only thing that matters is their center point’s position.

Therefore, when deciding the width of the detection area, you need to consider the width of both this sprite and the clones.

Now, suppose we change the block to use width of 100, then the table will contain 3 rows, because the detection area now includes the center point of the clone 1 as well:

 
You can try to play with different truck direction, tree position, distance and width settings to understand how this block works better.

This change has been released. Please refresh your playground to get latest code.

 

Introduction

 

In part 1 of this tutorial, we built a basic AI controller for the game. That AI could already move the truck to random locations, and even seek and attack the opponent.

In this second part, we’re going to supercharge our AI! We’ll add two major new skills: collecting power-ups and avoiding tree obstacles. With these upgrades, our AI will become a much tougher competitor in battle.

Here is a demo of what we’ll be building:

 
 
 
 
 
 
 
 
 
 
 

Version 4 - Collecting Powerups (Difficulty: 4)

 

To get our truck to collect powerups, it first needs to know where they are. Then, it has to drive over to them. A key part of the logic will be deciding when to go for a powerup versus when to keep attacking the opponent.

 
 

Step 1 - Duplicate the Previous AI Code

 

We’ll be building on the AI controller we made in Part 1 (Version 3). Go ahead and open that project, and then save a copy of it. This way, you’ll always have the original version to go back to if you need it.

 
 

Step 2 - Check for Powerups

 

To collect powerups, our AI first needs to know that they’ve appeared on the map. It only makes sense to change the truck’s behavior after a powerup is available. The best spot for this check is right at the start of our main forever loop.

Let’s create a new custom block and name it check powerups. Important: Make sure to check the box for “Run without screen refresh.” This gives our code a nice little speed boost.

 
And we will place this new block at the beginning of the main loop:

 
 

Step 3 - Check Our Life Count

 

Remember, there are two types of powerups in the game:

• Sugar: Increases our truck’s life count (up to a max of 3).
• Gas: Boosts our truck’s speed (up to a max of 120).

It makes sense to prioritize survival. If our truck has fewer than 3 lives, getting a Sugar powerup should be the top priority. Let’s start by adding a check for that.

 
Note that the ☁ my lives variable keeps track of the life count for our truck, which is identified by the my team ID. This sensing block is very handy when you need to access any private property of a clone so long as you know its ID.

 
 

Step 4 - Look for Sugar Powerups

 

If our truck needs health (meaning it has less than 3 lives), it’s time to scan the area for any Sugar powerups. We can do this using the special find clones of sensing block.

 
This block is incredibly useful. It searches for all visible clones of a specific sprite within a certain distance. Since we want to find Sugar anywhere on the map, let’s use a large distance like 1000. Any Sugar clones it finds will be listed in the table1 variable.

 
 

Step 5 - Check If Table1 is Not Empty

 

If the find clones of block successfully located one or more Sugar sprites, it will add them as rows to table1. So, to see if we found anything, we just need to check if the number of rows in table1 is greater than 0.

 
 

Step 6 - Update Mode and Target Location

 

Okay, we’ve found a Sugar powerup! The next step is to drive to it. The table1 is conveniently sorted by distance, meaning the very first row always points to the closest clone. For example, this screenshot shows that one Sugar clone was found. It has a clone ID of 1, is located at X: 160 and Y: -65, and is 96.43 units away from our truck.

 
Now, we could create a whole new mode like “collect sugar,” but there’s a clever, simpler way. We can just reuse our existing wander mode! All we have to do is update the target x and target y variables with the location of the Sugar item. The existing code in the wander block will then automatically navigate our truck right to it.

 
 

Step 7 - Return from “check powerups”

 

Once we’ve spotted a Sugar clone and decided to go for it, our job inside the check powerups block is done for this cycle. There’s no need to continue and check for Gas powerups. We can use a return block to exit the custom block immediately.

Pro Tip: It’s a common misunderstanding that the return block is only for reporter blocks (the ones that return a value). You can also use it in regular stack blocks like this one to simply stop the block from running any further. Its return value is just ignored. This is equivalent of using the stop [this script] block.

 
 

Step 8 - Look for Gas Powerups

 

If our truck is at full health, or if there were no Sugar powerups to find, the code continues. Now we can check for Gas powerups. But, there’s no point in grabbing a Gas powerup if our speed is already maxed out at 120. So, let’s first check our ☁ my speed variable.

 
 

Step 9 - Complete the Rest

 

The logic for finding and collecting Gas clones is nearly identical to what we just did for Sugar. See if you can build the rest of the code yourself! It’s great practice.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Here is the complete solution for the check powerups block:

 
 

Step 10 - Test This Version

 

Time to test our new powerup-collecting AI! To focus just on this new skill, let’s keep the tree count at 0 for now (you can change this in the Setup sprite).

It’s also really helpful to make the table1 variable visible on the stage. This way, you can see exactly when the AI finds a powerup.

One last tip for faster testing: in the Sugar sprite, you can shorten the time it waits before reappearing. For example, try changing the random wait to between 3 and 9 seconds.

 
Now you can test your AI by opening the project in two browser tabs and letting them battle. It should look something like this:

 
 
 
 
 
 
 
 
 
 
 
 

Version 5 - Avoiding Trees (Difficulty: 5)

 

Now for a real challenge: obstacle avoidance! Right now, our truck will just drive straight into trees and get stuck, completely stopping it from chasing the opponent or grabbing powerups. We’re going to fix this by teaching our AI how to detect when a tree is in the way and then plot a “detour” to get around it.

 
 

Step 1 - Export Version 4 for Backup

 

First thing’s first. Let’s make a backup of our working powerup-collecting version. Export your Controller sprite as a file (it will be named something like sprite3). This way, if anything goes wrong, you can easily import this version and start again.

 
 

Step 2 - Define a New Reporter Block

 

To avoid trees, our AI first needs a way to “see” if its path is blocked. We’ll create a new custom block that can answer a simple question: “Is this direction blocked?”. Let’s name it direction is blocked, and it will take the command as an input. Make sure to select “Run without screen refresh” and define it as a reporter block. A reporter block returns a value; ours will return 1 if the path is blocked and 0 if it’s clear.

 
 

Step 3 - Discussion On How to Detect Tree Obstacles

 

Before we jump into coding, let’s talk strategy. How can our Controller sprite, which only sends commands, know if the Truck sprite is about to hit a tree?

In standard Scratch, you might try a “ghosting” technique: quickly move the sprite forward, check for a collision, and move it back before the screen refreshes. But that won’t work here, because our Controller sprite and Truck sprite are separate. The Controller can’t directly move the Truck to test for collisions.

So, we need a different, more clever approach:

1. We’ll temporarily move our invisible Controller sprite to the exact location of our Truck.
2. We’ll point the Controller sprite in the direction we want to move.
3. From that position, we’ll use a new sensing block to scan a rectangular “detection area” in front of the sprite to see if any trees are inside it.

 
Let’s implement this idea in the next few steps.

 
 

Step 4 - Move the AI sprite to the Truck

 

First, let’s get the current X and Y position of our truck using its my team clone ID. Then, we’ll use a go to x y block to instantly move our Controller sprite to that same spot.

 
Remember, the Controller sprite is invisible, so you won’t see anything change on the stage. The whole point of this move is to establish a starting point for our tree-detection scan.

 
 

Step 5 - Face Upward if Command is 1

 

If the command we’re checking is 1 (move up), we need to check for trees above the truck. To do this, we’ll point our Controller sprite upwards (direction 0). This step is crucial because the detection area we’re about to create is always relative to the direction the sprite is facing.

 
Again, we’re just using the invisible sprite’s direction to set up our detection area.

 
 

Step 6 - Handle the Other 3 Directions

 

Similarly, we’ll handle the other three possible commands (2 for down, 3 for left, and 4 for right), pointing the Controller sprite in the corresponding direction each time.

 
 

Step 7 - Detect Tree Clones in a Rectangle Area

 

With our Controller sprite now at the truck’s location and pointing in the direction of intended movement, we’re ready to scan for trees. We’ll use the find clones of sprite in rectangle block. Here’s how this powerful block works for our setup:

 
Explanations:

• We are looking for visible clones of the Tree sprite. The original Tree sprite is hidden, so this check will correctly ignore it.
• The rectangle is defined relative to the Controller sprite’s forward direction. So if the command is 1 (up), the Controller is facing upward, and the rectangle will extend 60 units forward and expand 90 units wide, like this:
  
   
• We will store information about all clones found in the table1 variable.

 
Feel free to fine-tune the distance and width values. Think of distance as how far ahead the AI can “see,” and width as its “peripheral vision,” or how wide you want to scan.

If the center of any Tree clone is inside this rectangle (i.e. its center point falls into this rectangle), it will be listed in the table, which includes columns for clone ID, x, y, and distance.

 
If more than one clone is found, the table will be sorted by distance, with the closest one listed first.

 
 

Step 8 - Check If Table is Empty

 

We don’t need the specific details of the trees, just whether any tree was found. So, we can simply check if table1 has any rows. If the row count is greater than 0, a tree is blocking the path, and our block should return 1. Otherwise, the path is clear, and it should return 0.

 
 

Step 9 - Check if Command Direction is Blocked

 

Now we can put our new reporter block to use! Back in the main loop, right before we set the new command, we’ll call direction is blocked to check the path.

Also, to make our AI more responsive and quicker to react to obstacles, let’s reduce the wait time in the main loop to 0.1 seconds. This allows it to check for blockages more frequently.

 
 

Step 10 - Calculate a Detour Command

 

If our check finds that the intended direction is blocked, we need to calculate a detour. We’ll create another new custom block, calculate detour, to handle this logic. This block will figure out a new, unblocked detour command which will then temporarily override the new command.

 
 

Step 11 - Discussion on How to Make a Detour

 

So, how do we calculate a smart detour? There are many complex pathfinding algorithms, but we’re looking for a solution that is effective, fast, and simple to build.

Imagine the truck needs to get the Gas on the top right, but a tree is blocking the path to the right.

 
We have a few command options:

• new command: The original, blocked command (e.g., move right).
• alt command: The other direction towards the target. Since the Gas is also above the truck, moving up would be a good alternative.
• alt command 2: The opposite of the alt command. This is a backup plan if the alt command is also blocked.
• back command: The opposite of the new command. If all forward and side paths are blocked, our only choice is to back up to escape the “trap”.

Our strategy will be this: when we’re blocked, we will check these alternatives in order. Once we find a clear path, we’ll execute a two-step detour (e.g., move sideways for 1 second, then move toward the target for 1 second) before returning to our normal logic. This simple strategy will handle most situations very effectively. Let’s build it!

 
 

Step 12 - Initialize Detour

 

Inside our new calculate detour block, the first thing we’ll do is set up a couple of variables to manage the detour process:

• in detour: A “flag” variable. We’ll set this to 1 to signal that the AI is currently executing a detour.
• detour start time: We’ll record the current timer value here. This will help us time each step of the detour.

 
 

Step 13 - Calculate the Alt Command

 

Next, we need to determine the best alternative command (alt command). This command should still move the truck generally closer to its ultimate target.

If our original new command was vertical (up/down), the alt command should be horizontal (left/right). We can pick the correct horizontal direction by looking at distance x. If distance x is positive, the target is to the right, so our alt command should be 4 (move right).

 
Similarly, if the new command was horizontal (left/right), the alt command should be vertical (up/down). We can use distance y to decide whether to move up or down.

 
 

Step 14 - Calculate the Alt Command 2

 

The alt command 2 is always the opposite of the alt command. We can use a neat little math trick for this: since (left=3) + (right=4) = 7, we can calculate the opposite by subtracting from 7. This logic works whether the new command was vertical or horizontal.

 
 

Step 15 - Calculate the Back Command

 

The back command is always the opposite of the new command. We can use a similar calculation based on whether the command is vertical or horizontal.

 
 

Step 16 - Take the Alt Command If Available

 

Now we’ll decide which detour path to take. Our first choice is always the alt command. We use our direction is blocked reporter to check if that path is clear. If it is, we’ve found our detour! We’ll set up a two-step plan:

1. detour command: Set to the alt command.
2. detour command 2: Set to the original new command.

This means the truck will first move sideways, then try to resume its original path. Since we’ve found a plan, we can use a return block to exit the calculate detour script.

 
 

Step 17 - Take the Alt Command 2 If Available

 

But what if the alt command path is also blocked? This means obstacles are in front of us AND on one side. Our next best option is to try alt command 2 (the other side). If that path is clear, we’ll set our detour plan to use alt command 2 first, followed by the original new command.

 
 

Step 18 - Take the Back Command as a Last Resort

 

In the worst-case scenario, the paths forward, left, and right are all blocked. The truck is trapped! The only way out is to back up. We’ll set the detour plan to use the back command first, and then follow it up with the alt command to try and steer around the trap.

 
 

Step 19 - Add a New Branch for Detour

 

Now we need to modify our main loop to actually execute the detour. When the in detour flag is set to 1, we need to bypass all our normal logic (checking powerups, finding the opponent, etc.). Instead, we will run a separate branch of code dedicated to the detour.

The animation below shows how to restructure your main loop with an if/else block based on the in detour variable. Notice that the block that sends the command to the truck is now outside and after the if/else, so it runs in every situation.

 
 

Step 20 - Stop Detour in 2 Seconds

 

Inside the new “detour” branch of our if/else block, we’ll manage the two-step detour sequence. The whole detour will last for 2 seconds. By default, the new command will be our detour command. If the timer shows that 2 seconds have passed since the detour start time, the detour is over. We’ll set the in detour flag back to 0, so that on the next loop, the AI will go back to its normal behavior.

 
 

Step 21 - Switch to Second Detour Command in 1 Second

 

The detour itself has two parts. For the first second, the truck will follow detour command. After one second has passed, we’ll switch the new command to detour command 2 for the second half of the detour. This creates the “go sideways, then go forward” maneuver.

 
And that’s it! Our detour logic is complete. In short, when the AI “sees” a tree, it will now intelligently try to move sideways or even back up for a moment to get around it.

 
 

Step 22 - Test This Version

 

It’s time for the final test! Go to the Setup sprite and set the tree count to 6 (or even more to make it really challenging). Run the project and watch how your AI truck now cleverly navigates around the trees instead of getting stuck. You can also speed up the powerup spawn times again for a more action-packed test.

Here is a demo:

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Further Improvements

 

This AI controller is already much smarter, but there’s always room for improvement! If you want to take your AI to the next level and win battles, consider these enhancements:

• Smarter Attack and Dodge: Have you noticed your truck sometimes has a perfect shot lined up but decides to wander off instead? Improve the attack mode to recognize when it’s aligned with the opponent, take the shot, and then immediately move sideways to dodge any return fire.

• Strategic Powerup Denial: Right now, your AI only grabs powerups it needs. But what if your opponent is low on health and a Sugar powerup appears? A truly smart AI would grab that powerup just to prevent the opponent from getting it! Modify your check powerups logic to consider the opponent’s status, too.

• Don’t Waste Ammo: Firing donuts into a tree is a waste! Before shooting, you can use a similar detection method to the one we built for avoiding trees. Check if the line of sight to the opponent is clear. If it’s blocked by a tree, hold your fire and reposition.

• Press the Advantage: When your truck is stronger (more lives, more speed), it should be more aggressive! Instead of firing one shot and then wandering away, why not make it stay in attack mode and keep firing as long as it has the upper hand?

 
These are just a few ideas to get you started. The best way to improve your AI is to watch it battle. What mistakes does it make? When does it get outsmarted? Every battle is a chance to learn and come up with your own unique strategies to build the ultimate champion

@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!

@the_true_odst

What device/browser are you using? Have you tried to restart the browser?

@the_true_odst

Yes.

@the_true_odst

The scroll wheel is used for scrolling up and down to view the blocks, which is similar to the MIT Scratch interface. We strive to be consistent with MIT Scratch, unless there is a compelling reason to improve upon it.

@the_true_odst

The left mouse button is indeed used for dragging the editor area. Are you seeing otherwise?

@the_true_odst

Sure. We can probably add it to this block:

@the_true_odst

The stop button is meant to simply stop the program. It would be strange if it doesn’t.

Probably you can just add a “restart” button for this purpose?

Welcome to the CreatiCode Playground

 

The CreatiCode Playground is a fun online platform where you can create and share projects using Scratch blocks. It builds on the open-source MIT Scratch framework but adds exciting new tools and features to make your projects even more awesome!

This tutorial will guide you through the basics of using the CreatiCode Playground, perfect for beginners to block-based coding. If you’ve used MIT Scratch before, it is recommended that you quickly skim through and check out what’s different.

Let’s dive in and get started!

---

 
 
 
 

Create a New Account with Email and Password

 

Good to Know: If you have a Google email, you can sign in directly without creating a new account!

Here’s how to sign up using an email and password:

1. Go to creaticode.com.
    
2. Click the “Join” button in the top-right corner.
   
    
3. Choose whether you’re a student or an educator.
   
    
4. Fill out the sign-up form with your details, then click “FREE SIGN UP”.
   Note: The “Full Name” field is your username, and it doesn’t have to be your real name.
   
    
5. If you’re 13 or younger, you’ll need to provide a guardian’s email (like a parent or teacher). Your account won’t work until your guardian approves it.
   

---

 
 
 

Sign In to Your Account with Email and Password

 

Here’s how to sign in using your email and password (created by you or your teacher):

1. Visit creaticode.com.
    
2. Click the “Join” button at the top.
    
3. On the next page, click “SIGN IN” in the top-right corner to open a dropdown menu.
   
    
4. Enter your email and password, then click “Sign In”.

---

 
 
 
 

Sign In with a Google Account

 

If you have a Google account (like a Gmail or school email), signing in is super easy — no need to sign up!

1. Go to creaticode.com.
    
2. Click “Join” in the top-right corner.
   
    
3. Click “SIGN IN” in the top-right corner, then select the “Google” button in the dropdown.
   
    
4. Enter your Google email and password to sign in.
    
5. Select account type (student or educator) if this is the first time.

Tip: Always use the same sign-in method going forward (either email/password or Google) to avoid any mix-ups.

---

 
 
 
 

Explore Projects from the Community

 

Scratch — and by extension, CreatiCode — is all about Create → Share → Remix! You can make a project (like a game), share it for others to play and give feedback, and even let others “remix” it to create their own versions. It’s a fun way to inspire each other!

To check out projects shared by others:

1. Click the “Explore” link at the top of the page.
    
2. The top four rows show Editor’s Pick projects — cool demos that highlight what you can build on CreatiCode.
   
    
3. Below those, you’ll see all community projects. Use the two dropdown menus on the right to sort them:
   • Time Period: Choose a timeframe, like the past month or year.
   • Sorting Method: Pick how to sort projects:
     • Trending: Most likes.
     • Popular: Most views.
     • Recent: Newest projects.
     • Inspiring: Most remixes.
       

---

 
 
 
 

Understand Project Stats

 

Each project has a preview image with three key stats below it to give you a quick idea of its popularity and complexity:

• Love Count: How many users clicked the heart button to mark it as a favorite.
• View Count: How many times the project has been played.
• Block Count: How many coding blocks are in the project. A higher number usually means a more complex project.
  

---

 
 
 
 

Search for Community Projects

 

With so many projects in the community, searching helps you find exactly what you’re looking for! Here’s how:

1. Type a keyword (like “car”) in the search box and press Enter. You’ll see projects with that word in their name.
   
    
2. Click the small triangle in the search box to add filters, like finding only 3D projects or projects with a specific number of blocks.
   

---

 
 
 
 

Check Out a Project’s Home Page

 

When you click on a project, you’ll land on its home page, which has everything you need to explore it. Here’s what you’ll see (from top to bottom):

• Green Flag: Click this to play the project.
• Remix Button: Make your own copy of the project to edit.
• See Inside Button: Peek at the project’s code blocks and assets in the editor.
• !Report: Flag the project for the CreatiCode team if it has anything inappropriate.
• App Link: Send a link to the project as an app via email.
• Project Link: Get a direct link to the project.
• Comments: Share your thoughts (like compliments or ideas) and read what others have said.
• Remixes: Check out other users’ versions of this project, created by copying and modifying it.

 

---

 
 
 
 

Remix a Project

 

Want to put your own spin on a project you like? It’s easy!

1. Click the orange “Remix” button on the project’s home page.
2. A copy of the project will appear in your CreatiCode Playground.
3. Make any changes you want, then share your version with the community!

---

 
 
 
 

Share or Publish Your Project

 

Your projects are private by default, so you can experiment without anyone seeing your work. When you’re ready to show it off, you can share or publish it.

• Sharing lets others play your project, view its code blocks, and remix it. This is called “open-source” because the code is open for everyone to see and use.
• Publishing lets others play your project, but they can’t see the code or remix it. This is called “closed-source” and is great for sharing finished projects, like a puzzle game where the secrets in the code must remain hidden.

When sharing, you can choose who sees your project:

• Share: Open to all users.
• Share with friends: Only your CreatiCode friends can see it.
• Share with password: Only users with the password you set can access it.
• Share Unlisted: Not shown in Explore or search results — only users with the direct link can see it.
• Make private: Hide the project from everyone.
   
  

---

 
 
 
 

Create a New Project

 

Here’s how to make a new project:

1. Click the “Create” link in the top navigation bar.
    
2. Your new project comes with two default sprites:
   • Sprite1: A cute dog with costumes for walking in all four directions—perfect for animations!
   • Empty1: A blank sprite for your own ideas.
     
      
3. If you don’t need the dog, just delete Sprite1 and start fresh!

---

 
 
 
 

Browse Your Projects in “My Stuff”

 

The “My Stuff” page is your hub for managing all your projects. To get there:

1. Click the folder button in the top-right corner or select “My Stuff” from the dropdown menu.
   
    
2. You’ll see a list of all your projects, showing each project’s name, last modified date, and view count.
   
    
3. Use the menu on the left to filter projects by shared, published, or private.
4. Click “See inside” on any project to open and edit it.

---

 
 
 
 

Search for Projects in “My Stuff”

 

If you have lots of projects, finding the right one is easy with the search box:

1. Type a project name in the search box (upper or lower case doesn’t matter).
   
    
2. Tip: Give your projects clear, memorable names so you can find them quickly later!

---

 
 
 
 

Find Blocks in the Block Palette

 

The block palette on the left side of the Playground lists all the coding blocks you can use. Here’s how to use it:

1. By default, the palette is folded to give you more workspace. Click any block category to open it.
    
2. Want to keep it open? Click the “pin” button.
   
    
3. With tons of new blocks in CreatiCode, use the search box to find specific ones quickly. Clear the search by clicking the “X” button.
   

---

 
 
 
 

Adding Blocks to the Editor

 

To create a program with blocks, just drag them into the editor area. You can snap them together vertically, much like stacking LEGO bricks:

 
In some cases, you’ll need to insert one block inside another. When doing this, make sure to align the left edge of the new block (not the middle) with the target slot:

---

 

You’re now ready to explore, create, and share in the CreatiCode Playground! Have fun building your projects and remixing others’ ideas. If you get stuck, revisit this tutorial or ask a teacher for help. Happy coding!

 

Why Coding Still Matters

 

This AI curriculum comes at a time when artificial intelligence (AI) is rapidly transforming every walk of life, with a particularly profound impact on how professional programmers work. In the near future, it’s likely that 90% or more of all code will be written by AI. Our students, when they grow up, will be worse at coding than ChatGPT, just like they are worse at crunching numbers than calculators. All programmers will have to shift into new roles: guiding AI systems, initiating complex tasks, and reviewing what machines produce.

But that doesn’t mean coding is disappearing from education. On the contrary, we believe it’s more important than ever, and should remain a core component of every student’s education. Coding teaches students how to think logically, solve problems, and bring their ideas to life. It gives them creative agency in a world increasingly shaped by intelligent tools. Just as children will always build with LEGO and explore in Minecraft, they will continue to code; not because they must, but because it’s how they learn, create, and play.

The key challenge is: how do we keep coding fun, meaningful, and relevant in a world where AI is part of the process? This curriculum is designed to answer that challenge—by showing that the rise of AI isn’t the end of coding, but the beginning of a new way to engage with it.

---

 

AI as Assistant and Building Block

 

In a world where AI will increasingly act as a collaborator, students must learn not just how AI works, but how to work with it. That means learning to use AI tools thoughtfully and building directly with AI-powered components: not as passive consumers, but as creative problem-solvers.

CreatiCode builds on MIT Scratch, the world’s most widely used platform for teaching introductory computer science. It keeps what makes Scratch great: intuitive design, creative freedom, and a learning journey based on the cycle of creating, sharing, improving, and remixing.

On top of that foundation, CreatiCode introduces a full suite of classroom-ready AI tools. Students engage with AI coding assistants, generate assets with AI image tools, and use AI coding blocks to build real applications, like chatbots, gesture recognizers, and intelligent interfaces. These aren’t add-ons; they are central to how students learn to build with modern technology.

By working directly with AI tools in a controlled, educator-guided environment, students gain practical AI literacy. They learn to prompt, evaluate, and debug AI systems. They begin to understand how to collaborate with machines and how to shape what those machines do. In short, they’re not just coding with AI. They’re learning how to think, build, and create in a world powered by it.

This guide will walk you through everything you need to bring that experience into your classroom: the tools, the teaching strategies, and the core concepts behind each activity.

 
 

What Guides This Curriculum

 

This AI curriculum isn’t just a collection of tools and lessons. It’s built around a set of clear principles designed to help students thrive in a changing world, and to support teachers every step of the way.

First, we believe educators are essential. No AI tool can replace the relationships, insight, and emotional support that real teachers bring to the classroom. Every part of CreatiCode is designed to keep the teacher at the center. Technology should amplify your presence, not sideline it.

Second, we focus on student engagement within a safe environment. Students learn best when they care about what they’re doing, have agency, and can explore hands-on. At the same time, generative AI introduces real risks. That’s why all AI features on CreatiCode are moderated and controlled, allowing for creative freedom in a safe, school-ready space.

Instead of banning AI, we believe students should learn how to use it responsibly, like any other powerful tool. With the right support, they can explore what AI can (and can’t) do, reflect on how they’re using it, and become thoughtful users who are ready to shape the future.

Third, we prioritize doing over memorizing. Many AI curricula focus on abstract theory or concepts. Ours emphasizes building real projects, experimenting with tools, and learning by making. Scratch’s visual format removes coding syntax barriers, so students can focus on design, logic, and problem-solving from the start.

Finally, we encourage students to work together. After each core lesson, students pair up to extend what they’ve learned. These simple collaborations help reinforce ideas, build communication skills, and make learning social and fun. Working with a partner to build and debug supports deeper understanding and more confidence.

 
 

Tools That Support AI Learning

 
 
CreatiCode includes a full set of classroom-ready tools to help students learn AI in hands-on, creative ways while giving teachers the control they need.

The AI Coding Assistant helps students understand code and answer questions. It includes a Socratic Mode that asks guiding questions instead of giving direct answers, helping students reason through challenges and reflect on what they’re learning. You can choose when to turn this feature on and off, and all interactions are moderated for safety and focus.

The AI Image Generator lets students create custom sprites and backgrounds using text prompts. This supports visual creativity and brings more personality to their projects. Like all features on the platform, inputs and outputs are carefully filtered to keep things school-appropriate.

AI Coding Blocks offer easy access to powerful AI features like ChatGPT, text-to-speech, and hand-gesture recognition. These blocks make complex functionality accessible without overwhelming beginners. Students can focus on ideas and problem-solving instead of technical setup.

Widget Blocks give students the ability to build interactive AI applications using chat windows, buttons, text inputs, and other real interface elements. These tools introduce students to real-world software design by helping them build usable, accessible, and thoughtful digital experiences.

And most importantly, teachers have full control. Through the class dashboard, you can enable or disable AI features, see what students are generating, and guide the learning experience based on your goals. This makes it easy to support digital citizenship and balance freedom with structure.

 
 

What to Expect When Teaching AI

 

Teaching AI can feel different from teaching traditional programming. Here are a few key shifts to keep in mind as you plan your lessons.

• First, AI isn’t always predictable. Unlike regular code that always behaves the same way, generative AI can produce different answers depending on small differences in context. This means it’s a good idea to use screenshots or saved examples when demonstrating in class. It also opens the door to great discussions about how AI works and why it sometimes surprises us.

• Second, AI can be surprisingly competent in some areas and completely unreliable in others. Whether used as an assistant or through AI coding blocks, students will encounter tools that excel at certain tasks while failing unexpectedly at others. A key part of learning is developing the judgment to leverage AI’s strengths effectively while recognizing its blind spots. Students must learn to validate AI outputs, question results, and intervene when the system goes off-track.

• Third, how students access the AI assistant matters. Full access offers lots of support but may lead to over-reliance. Socratic Mode encourages deeper thinking but can frustrate students who are struggling. Sometimes, turning the assistant off entirely is helpful to build independence. A flexible approach is best.

• Forth, writing becomes a central skill. Communicating with AI is less about code and more about clear, precise language. Students need to learn how to ask thoughtful questions, give instructions, and reflect on results. Prompting overlaps with writing skills like argumentation and technical documentation. Our curriculum includes practice in prompt design to build this ability over time.

• Fifth, students won’t just be writing code — they’ll be taking on four new roles. As they build with AI, they must think like a creator — deciding what to make and why; a prompter — crafting inputs that guide the AI effectively; an integrator — combining AI-generated output with traditional code; and a tester — reviewing, refining, and improving what the system produces. These roles help students move beyond passive use and into active, reflective creation.

• Finally, students will be building tools, not just stories. While Scratch has traditionally been used for animations and games, AI projects often focus on building interfaces like chat apps or interactive tools. This shift introduces students to real software design and prepares them for the types of applications they’ll build in the future.

---

 
 

Concluding Remarks

 

AI is changing how we code, create, and learn, but it doesn’t replace the need for coding in education. Instead, it gives us new reasons to teach it. Coding helps students think clearly, solve problems, and build ideas from scratch. When paired with AI, it becomes an even more powerful learning experience. With CreatiCode, students don’t just use AI. They learn how to shape it, question it, and build with it, growing into confident creators in a world increasingly shaped by intelligent tools.

@andis_3cc

So you are hitting the daily limit for free users. It should reset tomorrow.

@andis_3cc

Here is a short example where it downloads the image from the given URL to the sprite as a costume, then attaches that costume to the chat, and then it asks the LLM to describe this image.

play.creaticode.com/projects/684340d71c49cae4508fc1ff

Also, what error message are you getting when you say you have hit the LLM limit?

Hi,

These are great questions, but there are no easy answers. CreatiCode is a much more advanced version of Scratch, so you will have to learn the basics before creating complex projects.

Can you start with the tutorials on this list?

https://www.forum.creaticode.com/category/17/tutorials

 
You can build some simple projects by following these examples, and then ask more specific questions about what you would like to do, such as how to modify one of these projects based on your idea.

@jamesa-blackwell-57b383d3

The simplest solution is indeed using the viewport:

1. Make the canvas size much larger than the view port
2. Draw a large backdrop in the stage canvas
3. Lock the viewport on the key sprite
    

 
Here is an example:

play.creaticode.com/projects/6842f3d73d952dd83a741d13

 
If this “does not work”, can you please explain what the problems are? We can either refine this or discuss a completely different solution.

Can you please post a screenshot? We have just tested it and this is what you should get:

@rubiired

We have communicated with that user and he/she agreed to remove inappropriate projects. If there is evidence that he/she is sharing new inappropriate projects again, we will take further actions.

@rubiired

Thank you. We will remove inappropriate projects from that user.