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
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:
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 hide 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.
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] show when this sprite clicked set [running v] to [true] //variable that tells if the round is in progress hide 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) forever 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] end wait until <(amountOfBoulders) = > //it must wait for the map to clear set [running v] to [false]
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:
- 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) check end define check if <touching [projectile v]?> if <(costume #) = > if <(progress) = (lead progress)> set [lead progress v] to  set [lead x v] to  set [lead y v] to  end delete this clone end 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) end