From Test-Scratch-Wiki

Tower defense projects have taken an incline in popularity due to Scratch 2.0's cloning. Cloning is beneficial for a tower defense game because it allows multiple of the same tower, projectile, or target to be generated. This tutorial explains how to create a tower defense project from scratch. For this tutorial, assume the following:

  • "Towers" are placed and fire at "enemies"
  • Towers always fire at the front enemy

Planning Out

Getting all or much of the artwork done prior to programming is helpful at times because it allows you to visualize exactly how you desire the game to run. For example, the enemies have to be programmed to move along the proper path, which cannot be done until the map is created and the path visualized. Other factors should be taken into consideration such as if a main menu is in place.

Creating a Main Menu

If you desire to have a main menu (which is often more professional), a simple button can do. Assume the button is as follows:

TD Play.png

A simple button like this can be created in the Scratch paint editor. Along with a button, a menu typically has a background. The background can be an image created in the Stage.


To program the main menu, simply add the following script to the button:

when gf clicked
switch backdrop to [mainMenu v] //sets the Stage's backdrop
show //make sure the button is positioned in a good location

when this sprite clicked
broadcast [play v] //triggers the game to begin
switch backdrop to [game v]

Structure of Enemies

Assuming the enemies have multiple layers to break down, the enemies have to have multiple costumes. One enemy sprite can be used for every enemy that will be present when the game runs due to cloning. In the costume pane, organize the costumes of the enemy so they are in sequential order of layers. This helps with the proper transition in the scripting of the project.

Starting Rounds

When the game begins, the round should not immediately begin; typically there is a start button in which one has time to assemble towers before clicking. Inside the start button, the following script can be placed:

when I receive [play v]

when this sprite clicked
set [running v] to [true] //variable that tells if the round is in progress
wait until <(running) = [false]> //wait until the round finishes
show //show again so you can begin the next round by clicking the button

When a round begins, the enemies need to be generated. For the enemy generation, the following script can be placed inside the enemy sprite. However, first assume the following:

  • "waits" is a list that determines how long the wait is before the next enemy is generated
  • "types" is a list that tells what costume the enemy begins at when it is generated. A higher costume makes a stronger enemy with more layers.

The boulder generation is encoded into lists, which is a part of efficient programming. Each item in the "waits" list is associated with the corresponding item in the "types" list. For example, if item 1 of "waits" is 4, then the enemy sprite would wait 4 seconds before creating an enemy with the costume # stored in item 1 of "types". Furthermore, each round is separated by a blank list item in each list. The following script generates the enemies constantly and pauses between rounds:

when I receive [play v]
set [i v] to (0)
wait until <(running) = [true]>
repeat until <(item (i) of [types v]) = []> // generate until blank list item detected
change [i v] by (1)
wait (item (i) of [waits v]) secs
switch costume to (item (i) of [types v])
change [amountOfBoulders v] by (1)
create clone of [myself v]
wait until <(amountOfBoulders) = [0]> //it must wait for the map to clear
set [running v] to [false]

Programming Enemies

All the enemy clones have a very simple method of determining which is in the front. There are four variables associated with the leading enemy:

  • progress
  • lead progress
  • lead x
  • lead y

The only private variable above is "progress". Every enemy has its own progress it records. When an enemy is generated, it starts with zero progress. Every pixel it moves along the path, its progress increases by 1. Every enemy constantly checks if it's progress is greater than the "lead progress" global variable. If an enemy's private progress is greater than the global lead progress, it sets the lead progress to its own, showing that it is in the lead. In addition, the leading enemy sets "lead x" and "lead y" to its x and y position to identify to the towers where the leading clone actually is.

when I start as a clone
go to x: (200) y: (180) //starting position
repeat until <(y position) < (0)> //until it reaches the center
change y by (-2) //speed may be modified mathematically according to costume #
change [progress v] by (2)

define check
if <touching [projectile v]?>
if <(costume #) = [1]>
if <(progress) = (lead progress)>
set [lead progress v] to [0]
set [lead x v] to [0]
set [lead y v] to [0]
delete this clone
switch costume to ((costume #) - (1))
if <(progress) > (lead progress)>
set [lead progress v] to (progress)
set [lead x v] to (x position)
set [lead y v] to (y position)
Cookies help us deliver our services. By using our services, you agree to our use of cookies.