Landers | Moving the invaders.

In the assets panel, in the 'main' folder, double click, 'swarm.script'.
Change the update function to move the invaders.

function update(self, dt)
	-- move invaders left and right
	local move_down = false
	for key,invader in ipairs(self.swarm_table) do
		local pos = go.get_position(invader)
		pos.x = (pos.x + self.direction * self.speed * dt)
		go.set_position(pos, invader)

		-- should invaders move down?
		if pos.x >890 or pos.x < 60 then
			move_down = true
		end
	end

	-- move all invaders down if one had hit the edge of the screen
	if move_down == true then
		self.direction =-self.direction
		for key,invader in ipairs(self.swarm_table) do
			local pos = go.get_position(invader)
			pos.y = pos.y - 20
			go.set_position(pos, invader)
		end
	end
end

What does this code do?

A local Boolean flag variable called move_down is set to false. The assumption is that the invaders will not move down the screen in this frame.

We then iterate over the swarm_table. Remember this is an associative array, and therefore all the elements of the array are stored as a key and value pair. In this case the key is the index in the array, and the invader is the Id of the invader we stored when it was spawned.

When an invader is destroyed both the game object and the Id in the spawn_table are removed. It is interesting to know this is how the space invaders got faster in the original game. It was actually a consequence of not having to iterate over so many objects. Therefore less processing was required and more frames per second could be achieved!

We get the position of the invader in a local variable called pos and change it depending on the speed, direction and delta time.

If the invader is about to move off the screen we set the move_down flag to be true.

If the move_down variable is true we iterate back through the objects changing their y position. Reducing it by 20 pixels. This has been hard-coded because it is unlikely we will change this value. Using hard-coding here again gives us a performance boost because the ALU can use immediate addressing rather than fetching the value from the cache. If the invaders jump too much it would feel odd, so it is better to spawn them nearer the player, speed them up or make them fire more frequently to increase the difficulty.

Note we didn't change the y position of the invader during the first nested loop, instead opting for a second nested loop instead. Although this is computationally very expensive, having a time complexity of 2xO(n²), because we need to move all the invaders, we need to start from the first one again anyway.

Save the changes by pressing CTRL-S or 'File', 'Save All'.
Run the program by pressing F5 or choosing, 'Debug', 'Start / Attach' from the menu bar. You should see the invaders moving on the screen. They will continue to move off the bottom of the screen because we haven't coded a game ending script.

The next stage is to fire at the invaders. Stage 5 >