How to Make a Tower Defense Game

Шаблон:NotUseful Шаблон:Outdated Tower defense projects are games where towers aim at enemies and try to destroy them. They are often hard to make, as they need advanced cloning, aiming, and tower building.

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

Planning Out

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:

Файл: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.

Programming

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.

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]
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) = [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". 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]) = [1]> then
if <(progress) = (lead progress)> then
set [lead progress v] to [0]
set [lead x v] to [0]
set [lead y v] to [0]
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

The tower defense game is complete.