Category: invaders

In the unlikely event that I hit the saucer, it is supposed to display the "mystery score" that applies. I think we can do that.

We continue working on the game's beat sound. I am faced with a dilemma.

The game lacks the terrifying beat sound that characterizes the arcade game. Let's put it in. Begin with a mostly unrelated question.

Despite a lot of musing about the Situation, I've not made enough progress to spike anything. What shall we do instead? A tiny improvement?

Now for something completely different!

I only just realized the name of that bear. But mostly, musing about the Situation idea.

Let's see about this explosion mixin. Now that we've sat on it for a few days, so the glitter has worn off, do we still love it?

I think there's maybe one more explosion up in this program. Let's see if we should add it to our mixin.

There's at least one more place where the ExplosionMixin could be used. Should we use it? Let's find out.

Are mixins a moral issue, or simply a useful tool?

Just one tiny improvement.

The morning goes in a completely different direction than I expected. A good direction, though.

Continued: One of Kent Beck's perceptive Rules of Simple Design is the one about expressing all design ideas. Some code up in this thing bothers me.

One of Kent Beck's perceptive Rules of Simple Design is the one about expressing all design ideas. Some code up in this thing bothers me.

This morning I thought we'd start partitioning the 3 Player classes. The situation suggests otherwise. Some simple refactoring. It's all good.

Dude, did you ever look at your hand? No, I mean really look at it?

Let's look today at three classes that are similar but different. Make similar code more similar. Soft, gentle, geek joy.

Today we're going to resolve the issues with invaders getting low enough to end the game.

A report on a PyCharm Live Template for starting TDD. Some experimentation. No yippee.

I look back at what one might have learned along the way here. Joy: highly recommended. Find yours.

When the invaders fire on the robot, it does not explode. When it gets a new batch of invaders, they don't fire on it. This cannot endure. Results: good. Code: OK.

Can we figure out a decent way to improve the attract mode? Should we make the robot player a better player? Perhaps not.

There are issues. A long, slightly fruitful refactoring. A much more deadly attract mode that plays better than I do.

Trying to keep the Driver-Player simple. How well can I manage that?

Sometimes I get ideas that are really tasty but impractical. Let's try something practical.

I have an idea for a step toward attract mode. I plan to try part of it.

Let's at least deal with the invaders falling off the bottom. Maybe a first step toward a better attract mode. Pretty ragged.

Today, just a simple Game Over screen, so that we can at least see our final score.

I plan to implement a Game Over screen soon. The first one will just display GAME OVER. But could we build a somewhat smart attract mode? One that learned to play the game? Let's think.

How many ways can we think of to do a thing? How can we decide among them? CW: Ignorant Savages.

We'll make sure that our tests check the production generator function, but mainly I want to talk about small steps and TDD.

Bill Wake suggested a generator function for my invader starting heights. I think this will be a keeper.

Will a tiny object help clarity in the InvaderFleet setup? Let's find out.

Today I propose to make the invaders advance down the screen. I have the details. I am not entirely happy with the result, but it is solid.

... the thing I call TDD might not quite be TDD. Also some speculation, and some other speculation. Pure musing no code.

I think today we'll deal with the possibility of running out of invaders. Today we bite the bear. Take that, bear!

Let's find something to improve the program, but small enough to be suitable for an early Sunday morning. I think we did something right!

The Invaders game, while playable, isn't quite as done as it might be. It's well past time to be adding some capability. We briefly discuss the point of software development.

I've run into a small issue with the Sounds object. I think I have a solid idea for it.

Working on sound, we encounter an interesting refactoring, done in a very zen-like fashion. Small steps, add duplication until it resolves. This was really quite nice.

I have a somewhat more expressive way to, well, express what we did yesterday. Do we prefer it? Let's find out. Short, and sweet.

I propose to remove some if statements today. Why might we do that? Do we like the result? Readers may disagree. I might even disagree with myself.

I'm pleased that Invaders has been implemented without framework changes. And I see what I think is a desirable change. I learn otherwise.

I want to talk today about Programming by Intention, a notion I learned from Kent Beck and Ward Cunningham.

Seeking something to do, I'm back on my Invaders [DELETED] again. I do tidying. It comes down to joy.

I have yet another idea for how to get rid of the conditionals in the saucer code. This one might actually be pretty decent.

I have an idea for how to get rid of the conditionals in the saucer code. It is a nasty idea. I must try it.

Time to look at the Saucer and see if it needs some improvement. I feel sure that it does. A very nice refactoring sequence appears.

It's Sunday morning and I have a little time to play. Let's see what's left for the Saucer.

Let's see what's left for the saucer and what we can do. It's late Saturday morning: maybe we won't do much.

We'll continue with the Saucer. We'll look at what's left and pick something. Includes thrilling video.

Yesterday I was running faster than my feet. Let's see how the Saucer code looks and how to improve its tests and the code itself.

Let's see about doing the saucer. How hard could it be? Well, not hard, but ragged and chaotic. I moved away from my A game for some unknown reason.

I think about screen layout. I look at the list of things to do. It's the Jira Trap!! It all seems so reasonable ... until it isn't.

My keyboard tray Jira is getting too messy. I'll clean it up and go to a much more high-tech solution. Also: a tiny tweak to screen layout. Also: robots

There's some duplication between the BottomLine and Shield. Enough to fix? Let's have a look. Outcome: This goes ever so nicely! Sweet!

I found a way to damage a Surface, given a Mask. I don't exactly like it, but it works. Now what?

Yeah, let's do the bottom line. Might be just the right size for the afternoon.

I think there are very few things left to do with Invaders. One of them is scoring.

More waffles, about the tensions between design alternatives for the Flyers. What if we were to open the doors as widely as possible? I think this is my last waffle on this topic. I like the outcome. Today.

I gave abstract method a chance, for almost 24 hours. I hated changing all my classes to implement all those pass methods. Let's try a different dispatch. Waffles?

Now that we have this metaclass, and now that we have this decorator, what shall we do? The answer may surprise you.

We continue learning decorators using tests. Our simple decorator doesn't handle parameters in the wrapped function. Lets figure out how to do that.

Never heard of him. Let's learn about decorators, using tests.

The Python "decorator" is less bizarre than metaclasses and might be just the thing for our needs. Let's try one.

There are surely ways to provide my `ignore` feature without using metaclasses. I can think of one. Maybe it will help me think of another.

Having found a way that I think will work, I'll try again today to install the 'ignore' capability. Hamsters. And success!

Today, I plan to install the new metaclass with the `ignore` feature. Result: Bears discovered deep in the bag of tricks. They bite. Later: I know what caused it.

Today, in the spirit of meta, I work on a metaclass for ignoring methods. I start on Wednesday and finish on Thursday. It's scary weird.

What shall we do today, Brain? The same thing we do every day, Ron. Find something interesting to do. Things get very meta ...

The Invaders team has encountered a troubling issue, and have been making some troubling decisions. We need to explore this and deal with it at its root. Spoiler: It's not the programmers. People over process.

Let's do ReservePlayer. It has essentially no behavior. We'll TDD it anyway, and will be glad we did.

Thinking about how we'll replace a destroyed player has led me to a strange idea. Perhaps too strange, yet fascinating.

The words "time capsule" popped into my head last night. Have I told you my favorite thing about this program's design?

Bill Wake's comment suggests more use of the new Masker. Looks useful.

In which, a small object helps improve our code.

Part two, following P-247. Another idea. And we still have more opportunities to improve! Wait, SQUIRREL! Two of them!

In my quest to spend way too much time on ImageMasher, I have another idea. I should also mention why this exercise is a good one: changing code is our job.

Let's take a look at the ImageMasher. We'll see how far toward perfection (or lily-gilding) we can push it. We go a long way—and at the end I think I see still more that we can do.

It's oh-dark-thirty but I think I've got the answer.

An early idea got me up, to get it down, as it were. Too interesting for me to go back to sleep. Yes, I am strange.

I didn't see it on my drawing, I didn't see it in my code, but then I saw it in the code in my mind. The lessons today, oddly, are about dozing, and estimation.

I believe I'm close to understanding masks well enough to build a little object. Another test or two and then I hope to try something. Chaos may or may not ensue.

Before I try to improve the way the Shield adjusts its image and mask, I feel that I need a better understanding of how things work. We'll use tests to learn and record.

Some reflection, and an exchange with Rickard, makes me think that my lovely little Tasks object isn't as great as I initially thought it was. Let's think, code, think, and learn.

Let's do some tasks, now that we have the Tasks object. We'll see how we like it.

Not my ideas, mind you. Two good ideas from Tomas set me on a course for last evening and this morning. Are there rats in here?

Let's see if we can add lightness to our reminder facility.

My timing defects have caused some thinking, some of it mine. There might be a better way. (This is long, because there's a lot of design thinking. Then some rather interesting doing.)

There's a second "timing" defect in Invaders. This one is harder to forgive. Mea culpa. Plus: At least one other defect. And I allowed myself some fun writing this one, too. Same as it ever was.

Let's clean up the shields code and improve the damage. I've found a missing piece, the explosion part. A rather nice refactoring sequence ensues.

Let's clean up the shields code and improve the damage. I've found a missing piece, the explosion part.

It's 3 AM. The power's out, the phones are down. Of course I'm going to program a bit.

I have the facts. Let's draw four shields. Then shoot them a bit.

The Invaders game has shields, four of them. They take damage from invader shots, but are not destroyed in one go. This will be interesting. What do we need and what are some small steps?

Let's start transitioning away from inherited `interact` methods, making them abstract as originally intended. I'll try to devise a sensible way of proceeding,

Let's explore last night's matrix idea. There's got to be a pony lesson in here somewhere.

Last night, some topics came up that I'd like to consider a bit this very early morning.

If I'm right, which assumes facts not in evidence, this next step is going to be surprisingly easy. This often happens. There may be a reason.

I had an interesting realization about the shot patterns. And we have a hanging commit, some broken tests, and more to do before we are done.Things go well. Thoughts on small steps.

Let's find another small step toward invader shots. Maybe even more than one. Very long, I'm not sure why. And no commit at the end. Afternoon distractions. Not delight, just distractions.

Invader shots emanate from invader columns, according to a pattern. How are we going to do that?

Everyone needs them. Let's make that happen. Then, let's explode some invaders.

I think first I'll have the invader and player shots destroy each other if they collide. I had hoped for more. This caused enough trouble. Mostly resolved, I think.

I think today I get to start on the invader shots. How much of the original game's pattern must I follow? Probably it's too soon to ask. Squiggles!

There's reason to believe that there's an object in here. Let's bring it out. I feel I picked a poor path. How could I know?

At least two collision issues face me. One is how to stop the shot after it hits an invader. Another is that I see an object trying to be born.

Let's see about how to detect collision between the invaders and the player shots. I think we want to do actual bit overlap.

In response to a question from Bruce, I find myself looking askance at one of my darlings. Should I kill it?

We have a start at player shots. Let's get one on the screen .. and then off the screen.

I think I'd like to try the player shot. Names are becoming an issue. For once I do the right thing.

It's time to make the game look a bit more like a game. I'd like to think briefly about what to do and how to do it.

Having used the BitmapMaker in the game code, I envision a better way of using it.

I think the bitmaps are ready to be moved into the Asteroids-Invaders repo. I hope to actually use a couple of them in this session. Success! And an amusing mistake.

I've been pecking away at making the bitmaps for Space Invaders. Let's take a look at where we are. Gross ad-hocery and a lot of pasted data and bitmaps. Not very interesting, even for me.

There may be room for more refactoring in the fleet/group area. What even are those two objects? New CSS, consider clearing browser caches.

Let's continue to look at InvaderFleet and see whether some handy little objects might help us out.

It seems to me that InvaderFleet may be asking for some refactoring. Let's start with some thoughts on TDD, and a look at the tests and code.

I would really like to move this game along a bit. But there's a matter of scale that needs attention: the reversal points. And that fills the morning.

Let's continue with moving the invaders. We have some issues to deal with, and for at least one, I have no solution in mind. Lots of thinking tells me there's something funky in here.

I believe that I've made a mistake. This will not be my first, nor, I fondly hope, my last. CW: Contains brief Jira abuse.

It's time for a README file. Well past time, to be clear. And I have an ulterior motive, which will become apparent in due time.

Let's take the next steps to, um taking the next steps.

Bruce gave me a very nice idea: Bumpers! I think I'll try it.

I've decided to extend the Asteroids program to include Space Invaders in addition to Asteroids. I expect this to be—well—not easy but not too difficult.

We've managed to import some bitmaps and display them. It's time to start sketching and executing a plan. Then I ask myself a hard question, leading to a complete change of direction!

We do a quick bitmap experiment, and then create some alien surfaces from the original Space Invaders arcade source code.

Further setup for the record. PyCharm pleases me.

Today I plan to set up a new Python project. This one will be a Space Invaders replica. I'll say a bit about the idea, but this is mostly just a record of how setup went.

As requested.

Today, some code review. No big plans. We'll see what we see. I expect to mention Beck's Four Rules.

We'll look at using invader count as a flag to start a new rack. I don't promise to change it.

I don't feel very bright this morning. Let's see if I can prove it.

I have an idea and I can't wait to try it out. Niagara Falls.

Today's plan: Code review, and targets of opportunity. Short morning, just one new class.

Displaying two player score. Beyond that, we'll see.

Attract mode needs to be turned back on. Maybe we should show both players' scores. What about those buttons?

Let's do more on the two-player game mode. We're probably getting to the hard part.

It's time to start on the two-player option. I have ideas but not precisely a plan.

A lesson from history, a surprise refactoring, and, apparently, a sermon.

Not really, but the saucer is looking to score.

Users observe the need for more racks of invaders. That's going to get ... interesting. Also Game Over if they reach bottom.

I've convinced myself that a global would be a better way to handle constants than the singleton. Kill your darlings.

Users have detected a problem. Users, do you hear me? Users!

Improving zombie behavior. Sound adjustments. Maybe more. Maybe less.

Let's take a look at a simple attract mode. Zombies!

More with Singletons. And distractions. And no singletons.

Improving our Singleton and using the idea elsewhere.

There's no reason to think that I'm smarter today than I was yesterday, but I am a bit more experienced.

Touch to Start has me thinking that attract mode might be within reach. Things go Very Wrong.

Saucer Scoring, then whatever makes sense to me at the time.

Another day of improv. Let's see what looks worth doing. (Wow, a factory object!)

What shall we do today? I honestly don't know.

Remarks on a Twitter comment from Jez Higgins.

Another defect. I'm starting to feel ... afraid. That's not a good sign.

Things we might do. And I'm thinking about conditionals. The next trick may surprise you.

I have an idea. Let's find out if it's a good idea.

Maybe some tuning. Do we need more start-up settings? Should the test results disappear? What about a FireControl object?

The world is burning, and I'm really just trying to ignore reality, but in addition, I've made a mistake. Another mistake, that is.

If nothing else, you have to admire me for getting over 100 articles out of ancient video games. Let's do another today.

Better scaling, then more with the saucer, I guess. Plus whatever opportunities we spot.

More with the saucer, that's my plan.

I know the voices in my head aren't real, but they're sure ticked off at me for the past few days of messing up.

Well this goes entirely not as planned. Double Arrgh.

No, not space pirates all of a sudden. I released a fatal defect yesterday. What's up with that?

A couple of small changes to CodeaUnit and my CUBase template. Then let's see what we can improve about Space Invaders. (Saturday: Arrgh, a defect!)

More to do with bombs, especially targeted ones. We need some refactoring as well. The results may surprise me.

I think today we'll work on the bomb timing, and targeting the rolling bomb. Often, what I think will happen is what actually happens.

Let's continue the bomb dropping logic. Our current design can't do what's required.

Speed indicator; Bomb dropping order; Free player, maybe.

Some recovery from repo problems, some work with the clock, whatever else seems right.

The web site with sounds came back, so I'm scarfing them down and starting to install them. Should be mostly straightforward, he said. Except when my repo locked up.

If you're like me, you're wondering what space invaders eat. The answer will surprise you.

Let's damage shields from below, and try to continue small steps toward 'better', whatever we mean by that.

Let's make missiles explode, and continue improving this design.

I want to figure out why this program makes me feel bad. Then do something about it.

Some improvements. But first, a word about less technical matters, the book `x + y`, by Dr Eugenia Cheng.

A bit of planning, a bit of action.

Let's get a start on scoring. This should be easy enough. But--when is too much way too much?

I woke up this morning certain that some of my bitmap calculations were STILL off. Something has to be done.

A bit more exploding. I'm going to continue to let things get messy.

Let's do some damage

It's my ball and if I want to play with it you're not the boss of me.

One of these two things is not like the other ...

If the world isn't flat, how come these invaders keep falling off the edge?

Today we'll try to fix the collision logic to accommodate our origin changes, and to make the invaders explode.

I've moved the good iPad into the TV room and while waiting for our Sunday festivities to start, I'll set up the project's bitmap assets.

Having decided to move to CORNER mode from CENTER, we've got some work to do. I'm hoping this one isn't interesting.

Is it worse luck when Friday the 13th comes a day early? Or a near miss? Time to dig further into bombs failing to miss shields. (Added Friday: It was worse luck.)

I had no plan. Now I have a plan. Check code clarity, then work on shields. Things go ... oddly

Maybe make the invader bombs do some damage? Or what?

My plan for the day is to retrain myself by reading this code that I've not touched for two whole days, and then to see about moving things forward. My guess: invader missiles.

I think today I'll work on making the invaders march back and forth. Right now they just march forth and forth and forth ...

It's 6 bloody AM and I'm programming. What's up with that?

Let's see about extending our square invaders game-like thing to be a bit more like a game.

Twelve articles and no product. What's up with that?

In the real game, the invaders' missiles eat away at the shields. How can we duplicate this effect?

An experiment and some planning. Then even some doing.

Learnings from the ancient scrolls. What shall we do about them?

This one is mostly for the record, if it goes as planned. I'm just going to import some more bitmaps. I recommend against reading this.

Let's see what happens if we try to refactor our little spike into something reasonable.

A bit of an idea about marching, and thoughts about spikes.

I need an idea. Representation is important.

I'm wondering how to move these invaders. Let's do an experiment.

Dave1707 from the Codea forum shows a much better approach to converting the bitmaps.

Importing Invaders. How hard could this be?

I'm having so much fun with Asteroids that I thought I'd look at the old Space Invaders game. I'm sure I'll learn something.