Space Invaders 31

A bit of planning, a bit of action.

Its 0930, I’m back with my chai, and after picking up a scrip. It’s 80 degrees (almost 30C) and humid. My hair’s a mess and not long enough yet for a ponytail. I’ve got some steam left in my sails, so let’s see what we can do in an hour or so.

It seems to me that the saucer is the big missing piece in the game, but I want to do some outside reading to figure out when it appears: there is some trickiness involved in it, including that it replaces one of the invader bombs. I think I’ll skip that bit.

The invader bombs follow a pattern in the original, and it may be worth at least understanding the grand plan. Again, outside reading. We’ll also want to be sure that they only drop from the lowest invader in their column, not plunging through them as they do now. That will require a bit of knowledge of the column contents, I’d guess.

Beyond that, we’re pretty close. It’s possible that we’re not damaging the shields quite enough: I’ll watch some old videos and try to get a sense of that. It might just be that we don’t drop enough bombs.

Oh, and the gunner can damage the shield from the bottom. That should be dealt with.

What else? A two-player mode, perhaps, but there’s no one here but me that wants to play Space Invaders.

And cleanup. Since I’ve already released a minor improvement today, I think I’ll just try to continue my momentum on cleaning things up.

I’ll start where I left off, with the bomb code that assesses damage.

I had this idea …

I was thinking on the way over to the *$ that Codea has this nice logical or that short-circuits and doesn’t check subsequent sections when it knows the answer already. That might be useful here:

function Bomb:checkCollisions(army)
    if self:killedShield() then
        -- intentionally blank
        -- would be better to move shield damaging up here.
    elseif self:killsGunner() then
        Gunner:explode()
    elseif self.pos.y < 16 then
        self:damageLine(self)
    else
        return -- without exploding
    end
    self:explode(army)
end

Our first branch actually has the shield damage inside the killedShield method. If we did that with the other two, killsGunner and the line damage, we could rewrite this method rather neatly.

First let’s move the gunner explosion inside:

function Bomb:killsGunner()
    if not Gunner.alive then return false end
    local hit = rectanglesIntersectAt(self.pos,3,4, Gunner.pos,16,8)
    if hit == nil then return false end
    return true
end

That’s easy, we just move it right before the return true:

function Bomb:checkCollisions(army)
    if self:killedShield() then
    elseif self:killsGunner() then
    elseif self.pos.y < 16 then
        self:damageLine(self)
    else
        return -- without exploding
    end
    self:explode(army)
end

function Bomb:killsGunner()
    if not Gunner.alive then return false end
    local hit = rectanglesIntersectAt(self.pos,3,4, Gunner.pos,16,8)
    if hit == nil then return false end
    Gunner:explode()
    return true
end

So that’s nice. Now extract the Line case:

function Bomb:killsLine()
    if self.pos.y > 16 then return false end
    self:damageLine(self)
    return true
end

That leaves us with this:

function Bomb:checkCollisions(army)
    if self:killedShield() then
    elseif self:killsGunner() then
    elseif self:killsLine() then
    else
        return -- without exploding
    end
    self:explode(army)
end

We rewrite that this way:

function Bomb:checkCollisions(army)
    if self:killedShield() or self:killsGunner() or self:killsLine() then
        self:explode(army)
    end
end

That works a treat. We notice the naming asymmetry and fix that:

function Bomb:checkCollisions(army)
    if self:killsShield() or self:killsGunner() or self:killsLine() then
        self:explode(army)
    end
end

function Bomb:killsShield()
    for i,shield in ipairs(Shields) do
        local hit = self:damageShield(shield)
        if hit then return true end
    end
    return false
end

Much nicer overall. Commit: refactored bomb collision code.

It’s still only 1000 hours. What else counts as low hanging fruit for a quick harvest?

There are some utility functions lying about, including two here in the Bomb tab:

function rectanglesIntersectAt(bl1,w1,h1, bl2,w2,h2)
    if rectanglesIntersect(bl1,w1,h1, bl2,w2,h2) then
        return bl1
    else
        return nil
    end
end

function rectanglesIntersect(bl1,w1,h1, bl2,w2,h2)
   local tr1 = bl1 + vec2(w1,h1) - vec2(1,1)
   local tr2 = bl2 + vec2(w2,h2) - vec2(1,1)
   if bl1.y > tr2.y or bl2.y > tr1.y then return false end
   if bl1.x > tr2.x or bl2.x > tr1.x then return false end
   return true
end

Let’s consolidate those, for now, over in main tab, where there are only naked functions, no objects.

I’ll do a quick scan for others. There’s this in Bomb:

function createBombTypes()
    BombTypes = {
{readImage(asset.plunger1), readImage(asset.plunger2), readImage(asset.plunger3), readImage(asset.plunger4)},
{readImage(asset.rolling1), readImage(asset.rolling2), readImage(asset.rolling3), readImage(asset.rolling4)},
{readImage(asset.squig1), readImage(asset.squig2), readImage(asset.squig3), readImage(asset.squig4)}
    }
    BombExplosion = readImage(asset.alien_shot_exploding)
end

I moved it into the Bomb tab because it clearly relates to Bomb, but with this new scheme coming into being, I moved it back to Main tab.

In Shields, I find these:

function createShields()
    local img = readImage(asset.shield)
    local posX = 34
    local posY = 48
    Shields = {}
    for s = 1,4 do
        local entry = Shield(img:copy(), vec2(posX,posY))
        table.insert(Shields,entry)
        posX = posX + 22 + 23
    end
end

function drawShields()
    pushStyle()
    for i,shield in ipairs(Shields) do
        shield:draw()
    end
    popStyle()
end

For now, I’m going to stay consistent, but what we really have here is a call for some kind of class methods or constructors. But for now, consistency of finding seems better to me.

I’m starting to wonder about this idea. Leaving things where they are is possible but messy. This is neater, but not really quite right. Carrying on …

Gunner tab is all naked functions. I’m leaving that alone. Gunner is trying to evolve into an object. One iffy thing is that the touched event function is in Gunner. The good of that is that only Gunner uses it. The bad is that it’s a global official kind of thing and we usually expect to see it in the Main tab. I think that’ll go away when Gunner becomes an object.

Everything I see is done now. Commit: move naked functions to Main.

Still only 1006. See how little time these things take? Even when you’re writing an article at the same time.

How about making Gunner into a class? Let’s at least take a look at it:

-- Gunner
-- RJ 20200819

function touched(touch)
    local fireTouch = 1171
    local moveLeft = 97
    local moveRight = 195
    local moveStep = 0.25
    local x = touch.pos.x
    if touch.state == ENDED then
        GunMove = vec2(0,0)
        if x > fireTouch then
            fireMissile()
        end
    end
    if touch.state == BEGAN or touch.state == CHANGED then
        if x < moveLeft then
            GunMove = vec2(-moveStep,0)
        elseif x > moveLeft and x < moveRight then
            GunMove = vec2(moveStep,0)
        end
    end
end

function explode()
    Gunner.alive = false
    Gunner.count = 240
end

function setupGunner()
    Gunner = {pos=vec2(104,32),alive=true,count=0,explode=explode}
    GunMove = vec2(0,0)
    GunnerEx1 = readImage(asset.playx1)
    GunnerEx2 = readImage(asset.playx2)
end

function drawGunner()
    pushMatrix()
    pushStyle()
    tint(0,255,0)
    if Gunner.alive then
        sprite(asset.play,Gunner.pos.x,Gunner.pos.y)
    else
        if Gunner.count > 210 then
            local c = Gunner.count//8
            if c%2 == 0 then
                sprite(GunnerEx1, Gunner.pos.x, Gunner.pos.y)
            else
                sprite(GunnerEx2, Gunner.pos.x, Gunner.pos.y)
            end
        end
        Gunner.count = Gunner.count - 1
        if Gunner.count <= 0 then
            if Lives > 0 then
                Lives = Lives -1
                if Lives > 0 then
                    Gunner.alive = true
                end
            end
        end
    end
    popStyle()
    popMatrix()
    Gunner.pos = Gunner.pos + GunMove
end

function fireMissile()
    if Missile.v == 0 then
        Missile.pos = Gunner.pos + vec2(7,5)
        Missile.v = 1
    end
end

The initialization and handling is in Main, I think:

function setup()
    runTests()
    createShields()
    createBombTypes()
    TheArmy = Army()
    setupGunner()             -- <---
    Missile = {v=0, p=vec2(0,0)}
    invaderNumber = 1
    Lives = 3
    Score = 0
    Line = image(208,1)
    for x = 1,208 do
        Line:set(x,1,255, 255, 255)
    end
end

function draw()
    pushMatrix()
    pushStyle()
    noSmooth()
    rectMode(CORNER)
    spriteMode(CORNER)
    background(40, 40, 50)
    showTests()
    stroke(255)
    fill(255)
    scale(4) -- makes the screen 1366/4 x 1024/4
    translate(WIDTH/8-112,0)
    fill(255)
    drawGrid()
    TheArmy:draw()
    drawGunner() -- < ---
    drawMissile()
    drawShields()
    drawStatus()
    popStyle()
    popMatrix()
    TheArmy:update()
end

That’s all there is except for a bunch of tests. I’m not going to worry about those, I’ll just fix them as needed.

Speaking of which, there are some failing now. Let’s fix that, we’re on a clean commit.

10: bombs get deleted -- Bomb:63: attempt to index a nil value (global 'Line')

Yes, well, that’s been failing a while, hasn’t it. We need a more visible display when the tests have failed. Remind me to work on that.

Why doesn’t Bomb:63 crash at runtime?

function Bomb:damageLine(bomb)
    local tx = bomb.pos.x - 7
    for x = 1,6 do
        if math.random() < 0.5 then
            Line:set(tx+x,1, 0,0,0,0)
        end
    end            
end

Ah. We just don’t have a line created when we run the tests. Let’s do:

        _:before(function()
            createBombTypes()
            Line = image(1,1)
        end)

10: bombs get deleted -- Actual: 1, Expected: 0

        _:test("bombs get deleted", function()
            Shields = {}
            Gunner = {pos=vec2(112,10)-vec2(8,4),alive=true,count=0,explode=explode}
            local army = Army()
            local bomb = Bomb(vec2(122,10))
            army:dropBomb(bomb)
            _:expect(countTable(army.bombs)).is(1)
            for i = 1,10 do
                bomb:update(army,1)
                _:expect(countTable(army.bombs)).is(1)
            end
            bomb:update(army,1)
            _:expect(countTable(army.bombs)).is(0)
        end)

Ah. This must have been failing ever since bombs exploded. What’s happening, I’m sure, is that the bomb is exploding, and not yet deleted. We need either to update him a lot more times, or to check the alive bit in the countTable. I’d rather do the latter but do we use countTable elsewhere?

We use it only for bombs, so I’ll just patch it.

OK, something weird. I did this:

function countTable(t)
    local c = 0
    for k,v in pairs(t) do
        if v.explodeCount <= 0 then c = c + 1 end
    end
    return c
end

Suddenly CodeaUnit is showing 1 passed 14 failed … but the individual tests mostly look OK. What up with that?

I’m not at all sure. First, I’m going to move the naked functions out of the Test tab into main, because CodeaUnit is clearly looking at one of them.

It’s still saying 14 failed, and I really can’t think why. It appears from the detailed print that they are all running correctly. I don’t really have time to chase a CodeaUnit bug just now. Let’s change the countTable back and instead force updates.

Changing the function gets me back to 5 legit fails. Now to work through them:

10: bombs get deleted -- Actual: 1, Expected: 0

This one is a rather large issue. The bomb is updated in the draw function, so it explodes only after drawn. This isn’t good, but it’s a larger fix than I want to do in mid flight. Against best judgment, ignore this test.

11: Bomb hits gunner -- Actual: false, Expected: true

This one has a number of fails:

        _:test("Bomb hits gunner", function()
            Gunner = {pos=vec2(50,50)}
            -- gunner's rectangle is 16x8 on CORNER
            -- covers x = 50-65 y = 50,57
            local bomb = Bomb(vec2(50,50))
            -- bomb is 3x4, covers x = 50-52 y = 50-53
            _:expect(bomb:killsGunner()).is(true
            bomb.pos.y = 58
            _:expect(bomb:killsGunner()).is(false)
            bomb.pos.y = 57
            _:expect(bomb:killsGunner()).is(true)
            bomb.pos.x = 48 -- covers x = 48,49,50
            _:expect(bomb:killsGunner()).is(true)
            bomb.pos.x = 47 -- 47,48,49
            _:expect(bomb:killsGunner()).is(false)
            bomb.pos.x = 65 -- 65,66,67
            _:expect(bomb:killsGunner()).is(true)
            bomb.pos.x = 66 -- 66,67,68
            _:expect(bomb:killsGunner()).is(false)
        end)

I suspect our refactoring of the collision stuff has fouled this up. But maybe not:

function Bomb:killsGunner()
    if not Gunner.alive then return false end
    local hit = rectanglesIntersectAt(self.pos,3,4, Gunner.pos,16,8)
    if hit == nil then return false end
    Gunner:explode()
    return true
end

I wonder whether we don’t have to set the Gunner back to alive on every step.

Doing that has me down to two tests failing:

11: Bomb hits gunner -- Actual: false, Expected: true
11: Bomb hits gunner -- Bomb:72: attempt to call a nil value (method 'explode')

Let’s look at Bomb:72 first.

function Bomb:killsGunner()
    if not Gunner.alive then return false end
    local hit = rectanglesIntersectAt(self.pos,3,4, Gunner.pos,16,8)
    if hit == nil then return false end
    Gunner:explode()
    return true
end

Ah. We have no explode method in our fake Gunner object. Let’s initialize him correctly.

        _:test("Bomb hits gunner", function()
            setupGunner()
            Gunner.pos=vec2(50,50)
            ...

That fixes both test failures. I’m not sure why, for the second one, but I also don’t care. I’m sure that the collision code is working and feeling badly that I didn’t keep the tests up to date.

We still have a couple of ignored ones, but let’s commit: made old tests new again.

Now to see if I can make test failures more visible. I’ll test an idea here, but if I like it, it’ll have to be added to CodeaUnit as well. We have a function showTests:

function showTests()
    pushMatrix()
    pushStyle()
    fontSize(50)
    textAlign(CENTER)
    text(Console, WIDTH/2, HEIGHT-200)
    popStyle()
    popMatrix()
end

This just displays the global value Console at the top of the screen in large but not very intense print. Console contains the short summary of the test results. Let’s agree that it should include, whatever else it says, the string “0 Failed”.

Looking at that, I’m not at all clear why the test display turns out in a light grey color rather than vivid white. We may want to chase that depending on what this does:

function showTests()
    pushMatrix()
    pushStyle()
    fontSize(50)
    textAlign(CENTER)
    if not Console:find("0 Failed") then
        stroke(255,0,0)
        fill(255,0,0)
    end
    text(Console, WIDTH/2, HEIGHT-200)
    popStyle()
    popMatrix()
end

With that added, and a test that fails, we see this:

redbar

Nice. Let’s extend that:

function showTests()
    pushMatrix()
    pushStyle()
    fontSize(50)
    textAlign(CENTER)
    if not Console:find("0 Failed") then
        stroke(255,0,0)
        fill(255,0,0)
    elseif not Console:find("0 Ignored") then
        stroke(255,255,0)
        fill(255,255,0)
    else
        fill(0,128,0)
    end
    text(Console, WIDTH/2, HEIGHT-200)
    popStyle()
    popMatrix()
end

Now we can get a (not very vivid) green bar:

green bar

Or, with ignored tests, a yellow bar:

yellow bar

That should help me be a better citizen. Let’s commit that and put it over in CodeaUnit for future use.

Commit: show red, green, yellow test for CodeaUnit.

Let’s sum up.

Sum(Up)

So. A little bit of refactoring leads to what the team here chez Jeffries think is better code. Some unnoticed failing tests result in a more vivid display of unsuccessful results.

That’s good.

I do have two ignored tests to deal with, and I’ll do that in good time. Until then … thanks for reading and I’ll see you next time.

Invaders.zip