|This page or section is in question as to whether it is useful or not. You can discuss whether you want it deleted or not on its talk page.|
|The subject of this article or section has changed dramatically and requires updating. Please keep in mind that some of the information or images may not be accurate or relevant to the current version of Scratch, the Scratch website, or the article subject. (December 2019)|
Specifically: Does not work
Tower defense games have taken an incline in popularity due to Scratch 2.0's cloning features. 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 visualization of exactly how the game is desired 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 a main menu is desired (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 [Main Menu 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 the next round can be begun 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:
The only private variable above is "progress". Each 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. Make a block called "change y by () and update" that makes the sprite move and increase its progress. 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) and update // custom block; speed may be modified mathematically according to costume # change [progress v] by (2) check end define change y by (pixels) and update change y by (pixels) change [progress v] by (pixels) define check if <touching [projectile v]?> then if <(costume [number v]) = > then if <(progress) = (lead progress)> then set [lead progress v] to  set [lead x v] to  set [lead y v] to  end delete this clone end switch costume to ((costume [number v]) - (1)) if <(progress) > (lead progress)> then set [lead progress v] to (progress) set [lead x v] to (x position) set [lead y v] to (y position) end
Your Tower Defense game should be ready to go. Now it's time to go on your own. Add whatever you want! Test new ideas! Share it to the website!