Remarks on a Twitter comment from Jez Higgins.

In Invaders #52, I plugged in that drawing strategy for the Player, where it displays the normal player, the explosion, or nothing. The article blurb said:

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

Jez Higgins replied:

I think it is. I would have leant in harder because the different things you’re drawing have different behaviour associated with them - e.g. you can’t move while exploding. So normal play is an object which responds to touch events, missiles, etc …

while exploding ignores touch events, and just manages the explosion. The pause states tracks its own timer countdown, and draws nothing. We could apply movement states to the army too - moving left, moving down, moving right.

At the time, I replied with this:

Yes, we could certainly go there. I like to begin with a minimal design, then evolve it as the needs arise. Just now, I’m not seeing that the code is asking for that level of breakout. Or if it is, I can’t hear it yet.

Thanks!

I’ll start this morning by commenting a bit further on this topic. Let me begin by agreeing strongly with Jez’s observations about the opportunities for more of this notion of switching behavior using some kind of state logic. So far, all we’ve done is to plug in one simple selection of display type. It worked nicely, and I’m tempted, as Jez put it, to lean in a bit more.

I’m trying to be a bit messy

If we look back at one of the objectives for this game, compared to the Asteroids one, I have intentionally written it in a more “procedural” style than I usually would. The idea was to see how the code would look if we did that, and to see whether, when it starts to get gnarly, we could de-gnarl it readily. So that is one reason why I’ve not gone wild with some kind of state-oriented breakout: I want to explore how we recover when code gets nasty.

I try to build a thing when I need the thing

Another for not “leaning in” is that I try not to build a structure before I really need it. So while I might foresee the need for a class or a strategy cluster or whatever, it is my practice not to build it in anticipation of the need. (I freely grant that sometimes I break this rule when something seems just to fascinating, but generally I try to build just enough to fit current needs, while keeping the code well structured.

My belief is that if we keep our code well-structured at all times, doing just what is needed so far, without speculative “we’re gonna need this anyway” schemes built in, when the time comes, the scheme we actually need will plug in easiiy enough. The result is that we save time now by not building what we don’t need, and we don’t slow down later when it is needed.

The above is certainly true sometimes. I try to work that way most of the time, because I want to find out when, if ever, it doesn’t work to build well-structured code for today. So far, I’ve not encountered bad situations. In part that’s why I’ve let Invaders get a bit messier than I otherwise would, to see what would happen.

Does today’s work deserve this solution?

There is one final concern that I’d like to address. Jez is perfectly correct that we could plug in elegant solutions to the topics like those he raises. They’d be quite nice. I think we’d quickly encounter another opportunity, which would be corralling those differing elegant solutions into some kind of larger constructs, but if we did, it wouldn’t be too difficult, and if we proceeded with care, any needed corralling might just drop out.

But the question in my mind is “does this program deserve that kind of treatment”? Does it need that sort of structure, or is the fact that this is a small game mean that building a large number of classes, objects, and other structures just isn’t appropriate?

On the one hand, a perfectly good Space Invaders was written in assembler with nothing much more clever than subroutines and block copy. So, no, it doesn’t need much high tech software. On the other hand, we’re here not just to write a tiny program, but to explore how larger programs are just made of lots of tiny programs. So, yes, we should use these tools so that we can see, in this small space, how they might work in a larger one.

Programming is tricky, innit?

Those are just a few of the forces I’m trying to balance in these articles, and surely there are other forces to which I respond without recognizing it. I believe that this is the most consistent aspect of programming in the large or small: we are faced with many forces, many opportunities, many problems, and if we’re good at what GeePaw Hill calls “harvesting the value of change”, we mostly do small opportunistic things that add up to a working program, day in and day out, hour in and hour out. from day one to day N.

Let’s wrap this up and start a separate article for code. See you there!