Category: asteroids

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.

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.

Somehow I am enjoying working on, refining, polishing this Asteroids game. I don't want to stop. I have at least two silly features in mind. And, are there still lilies to gild? We discuss inheritance. Basically done?

Is this program as perfect as I can make it? Is there anything left to do? When your best idea is spinning asteroids ...

Tomas Aschan inspires me to try an object. I don't think I'm going to do exactly as he said, but when this works, he deserves much of the credit. If, perchance, it doesn't work, it'll be Chet's fault. But it will work.

What if we made all three `draw` commands look alike?

On our quest to improve SurfaceMaker right out of existence, let's try a LinePainter object to replace it. Except that I change my mind almost immediately. Notes within on hints that I wasn't working ideally.

Now that we've improved SurfaceMaker, can we improve it all the way to nothing? Let's find out.

I've implemented the SurfaceManager to allow callers to specify extra room for fat lines. That was not a good idea.

We've improved the SurfaceManager a lot. We'll do a quick review of that, and then see what we've missed. Why? It's good for us and for our organization. Late note: Ron was too clever.

At the time I worked out how to draw the game objects, I was new to Pygame and all its works and all its pomps. We deserve better. Refactoring FTW!!

The screen objects are too big for the amount of screen space we have. We need a global change of some kind! (Turns out to be disappointingly easy.)

We'll start with some philosophizing, and then we'll do a review of the saucer's missile-firing logic. Fun is actually the point.

I have no particular goal in mind this morning — yet. We'll look at our recent work and then beyond it. My initial concern: Aliasing.

I'm going to take another try at improving the ShotOptimizer code. Not because we really need to, but because we want to learn how to make code better. That's my story and I'm sticking to it.

I see the issue and fix it. An aliasing issue. I haven't had one of those for a very long time. Still no committed code change but some good ideas. Next time?

It's 0430 hours, commonly called oh dark thirty. I have a desperate need to clear my mind and get back to sleep. I try some things and settle on none. I learn some things but no net code change.

This morning PyCharm and my code rubbed my nose in the notion that a "static method" signal may mean that the method in question really belongs on some other class. Let's explore that idea.

Today I think it might be fun to extract a SafetyChecker class from ShipMaker by refactoring. First I get a better idea, and then the code tells me what it really wants. Fascinating!

Just for fun, I add a cheat code. Might not be my last one.

It's funny how thinking about one thing can give you an idea about another thing. Just a little fun today.

OK, let's see if this baby will fit where we intended it to fit.

Because I injected a defect into my two-player game, and because it could be better anyway, let's make it better.

After all that happiness, I realized that free ships go to the wrong player in the two-player mode. Bummer. In fact: Dammit!

Let's review how we added a two-player mode to the game. Let's look at how it was done. Frankly, I am pleased. EXCEPT: A Defect!!

If things go roughly as I expect, we'll have the two-player game today. Sometimes things do go as I expect. It could happen. It DOES happen!

Yesterday, an idea. Today, an experiment. Your intrepid author is optimistic. Things go very nicely.

Let's think about a two player alternating game and how we might do it. A bit of design thinking seems to pay off.

I think the coin test is better than it was, but it isn't what it could be. Let's do better, just for the practice. I surprise myself with a challenge.

I thought this morning that I had broken the game. Why am I even doing this seemingly useless changing? How do you get to Carnegie Hall?

I'll just have a look in and see what might need a little tidying, then, shall I?

Zoom report. I notice a thing. What is to be done about it? Something nice. Repeating the Faulkner quote from yesterday.

Sensible thoughts lead me to wild speculation about the future of this tiny program. Who knew? Then, I create something nice: a Transponder!

Let's continue the scoring improvements, with a little help from our friends.

Working with Saucer has me thinking that scoring is unnecessarily complicated. Let's look into that. Isn't it amazing how much a tiny program like this one can be improved? And I didn't even try to do a poor job.

Saturday: Remove unneeded abstract method. Discuss design. Sunday: a nice refactoring series.

As small as this program is, it shows us examples of issues that arise in larger applications, and suggests similar changes to those we'd make in the wild.

I really don't like the fact that I am either too dull or too lazy to derive the quadratic targeting calculation. Either it goes, or I do, and I get to choose.

I'm just going to look at random bits of code and see what they suggest to me. Watch me if you care to.

Bill Wake gives me some thoughts about a static method. We'll look at that, and see what else may need a bit of improvement.

Last night, I showed my friends two largish methods. Soon, everything was different.

This morning, I woke up thinking something was broken. Fortunately, I was mistaken. Let's fix it anyway. Also, thanks to a reader!

This afternoon, I notice something that could be better. Let's see if we can find a bit of improvement.

The final of four articles covering a single refactoring session. It has gone ever so nicely.

We continue a long refactoring session. It goes so smoothly that it all happens in one stress-free morning.

I begin a long refactoring session. I'll split the article another time or two. I am a merciful person at heart.

Again today, I plan to make the necessary adjustment to missile velocity to improve targeting. Again today, I have an idea. (First of a few articles all reflecting one morning session.)

I've left in two tests that aren't testing anything, and I still want to improve targeting. Let's see what we can manage. (Answer: Not much. Final thought on story estimation.)

This morning I discover that the code doesn't do what I thought it did, nor what I now want it to do. Inching toward better.

The new targeting code seems to work, though I could not derive it. I want to refactor so that it makes more sense, and I have an idea for a bit more testing.

I get some good advice from a reader (!) and ten (unrelated) consider a demonic idea. I lift a solution from the Internet. Some nice little refactoring. A few tests. Saucer is deadly. Could be more deadly.

The small saucer should always target the ship, while the large one targets randomly. Let's see how we might manage this. The Gunner does know the saucer ...

I think today I'll put in the small saucer, because the game is already too hard for me.

Let's begin by getting rid of the Explosion Flyer, at least the Flyer part of it.

We think about our design, do a feature, recognize a potential concern. Not what I planned, but that always happens.

Must think about, maybe spike about, an idea from GeePaw Hill. How pure do I want to be, on what dimensions? In the end, "No!" and I'll tell you why.

Observations from Rickard. And let's remove some Flyer subclasses. I still think I've gone too far.

SaucerMissile must go: it is not bearing enough weight for the trouble it causes.

A Mastodon exchange with Rickard makes me wonder whether this program violates Kent Beck's "Rules of Simple Design". I need to think about this.

I think I've gone too far ... I discuss, speculate, wonder, and do not as yet know what to do. Ideas welcome, as always.

At least I'm trying ...

Yesterday's experience causes me to question a central design notion.

Last night, Hill observed something notable. We worked on it then, and I'll do more now.

Looking at Game, and it seems we can improve quite a bit. Great outcome, nearly perfect!

Let's go after Fleets and Fleet. There's too much there for what we need. And, perhaps, too little. Discovery: I like it!

What shall we do now? Think about splitting Gunner? Discover something different in there? Create a debug keystroke? Why not all the above?

I am slightly irritated by the fact that my lovely Gunner object would really benefit from an additional change.

OK, lily-gilding aside, what are we really doing to do with `nearest`?

I'm going to do the tiny object for the `nearest` code. I just want to see how it looks. Talk about gilding the lily.

I had an idea last night as I was dozing off. If I can remember it, I'd like to try it out. This turns into a long series of revisions of about ten lines of code. Fun for a Saturday.

As a lark, I plugged in the Gunner. Doesn't seem to work. Let's see what's up.

I've received a PR or two from Jani, and then on to more work on Gunner,

I am trying to do little things in a house full of banging. I found something possibly worth thinking about. And maybe I go off the rails. I'm not sure.

A toot from Jani led me to see the defect allowing ships to shoot themselves down. The question is what to do about it.

We are getting a new roof today. Might be hard to concentrate. Fortunately, I try never to need deep concentration anyway. Shall we work on Saucer today? We shall. (TDD really works nicely here.)

A couple of small changes, then we'll see what's next.

I did a bit last night. Let's see if we can finish the HG this morning. I bet we can, but then, I read ahead in this article.

Let me do a little background TDD here, see what I come up with.

I need all the help I can get playing this game and I'm thinking I'd do better if I could shoot down the Saucer's missiles. Also, some thinking, and hyperspace recharge cycle.

We want the game to start in "Attract Mode". Should be trivial. Shall we do a Seed? No, something more fun. Also: I make a mistake. Not the first time, just the most recent.

Jira is the name of the area on my keyboard tray where the yellow sticky notes live. It's getting messy. Let's see if there's anything on there we can scratch off, or if all else fails, actually do.

The Game knows the objects that need to be loaded into the mix to start the Game. Let's fix that up.

A Timer-related idea. I have a little time, let's try something. It goes very nicely, I think.

No, I mean REALLY look at it. Did you think I was finished with Thumper?

Did you ever look at your code, man? Like, really look at it?

I think we should break out the thumper logic into a Flyer and simplify Fleets accordingly.

This morning I have concerns about the order of events, and what they are. Let's see if we need more clarity there. It goes well. Important footnotes.

This morning I thought I'd clean up Fleets a bit. Is now the time for that?

As usual, what happens today isn't what I planned. I recognize a design issue, implement a very interesting test, then generalize what happened to consideration of real teams. Watch how my thoughts evolve.

We need a GameOver object and a Quarter object. Let's try one or both of those.

I think there's just one more smart Fleet to remove and then we can greatly simplify Fleets and its interface. I wonder what other specific Asteroids notions may be lurking in the upper levels.

I think I'll move to replace another Fleet subclass. People I trust are tired of Asteroids. I briefly address that concern.

While I believe that my preparation work the last few days has been valuable, it doesn't feel much to me like real progress. Today I want a better feeling. And I get it!

Some thoughts on tests and code, inspired by shipping a defect and by ideas from Rickard. And then some changes. I have a nice one in mind.

I think I can do better than I've done with the Fleets object. Let's think about it.

Let's start with a question from Rickard, and then have a look at the Fleets / Fleet setup, to find one or more small steps toward our desired design. ALSO: Big mistake! Released broken game!

Let's see if we can reduce accesses to the specialized lists in Fleets. As so often happens, the next step isn't in the direction I expect. That's OK.

I think I'll start by counting missiles in the Ship and probably Saucer. Then we'll see what's next. The thing is to keep stepping toward the larger goal. Some interesting [mis-]steps.

What additional special objects do we need, and how might they work?

Let's put the full interaction protocol in place, so that more of our special Flyers can operate.

While sitting in a mostly boring on-line session, I'll do some small safe changes.

I am going to do a thing, and then another thing. Don't tell Hill about the other thing.

I am oddly without a plan this morning, even my tentative sort of plan. Be prepared to read my sort of thinking. I hit a few bumps but not major ones.

We make more small changes in the direction of independent objects interacting to make the game emerge. Let's experiment with full interaction.

I'll do a small change, then see what comes to mind. As long as we keep moving in roughly the right direction, we're good. Thoughts on small steps.

As I move toward the decentralized model, I need some thinking about next steps. But first, an interesting test.

The double dispatch is doing its job. Let's see about cleaning up the references to fleets and whatever else comes to mind.

-ralization. Just a picture of the relationships of some of the objects to start. Then a question: a world record? Guinness, where are you? And then: progress!

Some detailed thinking on how to refactor to a decentralized model. With any luck, some starting code. But I do feel the need of the thinking part.

I really liked the "decentralized" version of Asteroids that I did in Kotlin. Thinking about doing it again, in Python. Refactor to a new design? Why not?

I've been perusing the ancient scrolls, i.e. the Github repo of the original asteroids code. Some notes on what I think I understand so far, then some code. Repeat. Success!

Let's put in some more sounds. I anticipate little trouble. Even here, we learn some interesting lessons.

TIL that I had my speakers swapped left for right. And how to do stereo in pygame.

As one would hope, sound generation in pygame is pretty simple. I managed to work out the basics all by myself. Well, myself and the entire Internet.

Let's see if we can make hyperspace more dangerous.

I need another distraction. What's in "Jira"?

I need a distraction. Let's look for one.

We'll continue plugging in the MovableLocation, but I think it may need a better name.

I want to while away a little time. What can we find that's right-sized?

What if there was some sort of Position object?

We want to get rid of the GFragment class. To do that, we have to get a little head.

While I am OK with the subclass design, I think we can do better. Also "Replace polymorphism with data."

Just the before and after versions of the refactored Fragment classes. Lurvely.

I want to take a look at the explosion, especially the draw method and see how we can clean it up. Many many tiny steps FTW!

Today I plan to add gold to the gilded lily, in the form of still more enhancements to the Ship's explosion. Unjustified, but I plan to be amused by the result. And I am.

We have some rudimentary fragments. Let's make some better ones. I spend ages tweaking numbers.

I almost always have fun here, actually, but today let's explode the ship. That should be a good exercise for the Fleet-based design.

I have some loose end notes in my keyboard tray Jira. Let's have a look at some of them.

I learned something new, and apply it. Also I have an idea of my own. Will wonders never cease!?!?

Thinking about some design issues, some good, some maybe not so good. Seven footnotes, none useful.

We do a bit of review of the code today, and we find some nice improvements.

We'll finish up our refactoring of the checking methods down into Fleets and lower. Quite a few odds and ends, none of them difficult. A noticeable improvement to Game.

It's afternoon and I have some distractions. I'd be wise not to try anything, but maybe I can find some tiny safe steps.

We must be pretty close to done in our quest to move responsibilities down to Fleets, Fleet, and flyers. Also some generic Python thoughts.

Let's move some more Game responsibilities closer to where they belong. (It goes better this time!)

I was off my game yesterday, and want to do better today. I can't be smarter, but I can go slower. I think that, plus experience, will serve. (I still manage to get in trouble.)

Let's push more behavior down into the objects. There's plenty of room at the bottom. (I nearly interfere with the canine, but finally make a little progress. Don't read this article.)

Some of what I did last time needs improvement. This is no surprise, but, really, I coulda shoulda woulda done better. I forgive me.

Are there still easy ways to make use of our Fleets and Fleet classes? The remaining cases may be a bit more difficult. "Repeat, not quite the same way."

There isn't enough simplicity in here yet. Let's add some more.

Colin Chapman's motto at Lotus might apply here. Let's see if we can simplify this code. That will help us add lightness, I think.

I am concerned about an aspect of the design which is inviting mistakes. How might we address it? I surprise myself with a much simpler change than I had expected to make today.

In for a penny and all that, I do the Ship's spawning Timer, somewhat the same but slightly different. I mention a Fundamental Learning.

Now that I have my nifty timer object, I want to use it. Is there a rationale for this? I'll find one.

A test suggests that calling a method from the Timer works just fine. I confess that I find it a bit hard to grok at first.

Features are important, but I learn more from code review, so let's see what we can see. Timer object: Ron does not kill his darling.

There are things not to like. There always are. Let's find some and improve them.

After Hill's good advice yesterday, the Zoom group last night came up with something even better.

I don't know why I needed a hint for this test, but I'm glad to have had it.

The Saucer missile should usually be random, but sometimes aimed. Let's see about aiming. (It goes very smoothly, but I'm a bit light on tests.)

In the unlikely event that I shoot down the saucer, I'm supposed to get points. Let's make that happen.

The saucer's missiles just emanate from center screen. Time to fix that. I'm not sure how to test it. Oh, wait, I have an idea.

I kind of spiked something. I apologize.

Looks like it's time to deal with missiles and the saucer. It fires, and the ship can shoot it. Which should I do first?

My browser was open to the `random` page, and for a moment, my mind was open too.

The Saucer is a saucy little minx. Let's add some more sauce.

Continuing the saucer implementation in a second contemporaneous article, just to spare your eyes.

I remark on some things I learned from Rickard, and then get started on Saucer. I'm so successful that I had to split the article into two to spare the reader.

Let's see about pulling collision logic off into its own class. Should be easy, he said...

I may have casually been referring to the yellow sticky notes in my keyboard tray Jira as "stories". That's not consistent with my classic advice about stories. And my first-ever pull request!

Today I'll keep moving things into the Game object. Probably boring. One Learning: the current_instance trick was useful. Mentioned at the top for your convenience.

I'll just peck away at moving top-level fuctions into my game class. Tedious unless I get a clever idea. Very boring, do not read.

I think it's time to start moving the main loop code to an object. Very rambling and ambling flow this morning. Lots of thinking, small steps. One roll-back.

OK, let's do collisions differently and see what we think.

I'll pick something off the yellow sticky-notes Jira on my keyboard tray.

Let's see about displaying the available ship count, little ships in a row.

I've done what I intended with the billiards diversion. Let's see what we need here in Asteroidsville. Just small stuff. PyCharm impresses me greatly today.

Let's clean up that level handling a bit.

Unfortunately, we need to take things to whole new levels. This'll be fun. (Later: not as interesting as some, but it has its moments.)

Let's get some more modernization up in this baby. I'm sure it's the only reason we aren't selling millions.

Let's see about reducing a Singleton or two, and maybe some more modern graphics.

Our marketing people have a challenging request: modernize the look of this game.

It could happen: I've figured out a good way to handle these callbacks.

We'll continue our code review, with particular attention to our tweens, especially that tricky one.

I feel like reviewing some code. What I learn? Kill your darlings.

We're nearly done here!

Some tweaks to hyperspace seem in order, but I feel that this thing is nearly done.

Enhance Hyperspace?

Perfect saucer shots and a start on hyperspace.

Let's put in some options.

Let's clean up the Aimer and look around. I think we need options.

I really want to crack missile targeting. I've made some observations.

Two things go right. One thing goes horribly wrong

Free ships. Beyond that, maybe some reorganization? No, more like confusion.

Let's finish up the small saucer, and how about testing it this time?

Ships Remaining Indicators. After that, who knows?

After some discussion of things we might do, we decide to do GAME OVER. The results will surprise you.

Run tests automatically, dribs, drabs, and oddities. Pretty calm.

Today I plan to give the saucer the ability to aim its shots. I anticipate zero trouble.

A bit of planning and a bit of doing.

Not really an answer, but just a bit of fun.

Some sound, and saucer needs to stop helping so much.

Let's do collisions. And try to TDD them.

We move saucer and ship in the direction of our new scheme, and get rid of the cloning of the collection. Also took a nice walk.

We made a number of useful changes last time. Let's harvest some value.

I'm sure my double dispatch approach will work fine. But the pattern seems simpler than that ...

Some thinking and working on collisions. Is Ron converting to London School???

I've determined that it's time to collapse some 'technical debt', in small, incremental steps.

We need to improve collision detection. I think we have to do it in one go.

I think this afternoon I'll just push a little further on the saucer. Maybe make it dangerous.

I've decoded how to draw the saucers. Let's see about making them fly. That will require some research.

Some rationale, an experiment, some learning, some protection.

We start asteroids on the edge, which gives us an edge on refactoring.

A new approach to steering. And an apology.

I found some better recordings of the Asteroids sounds. And it's time to trigger new waves.

Stereo, because I can.

Based on the 'learning' from #25, let's just make bigger buttons.

Today I decided to experiment with improved controls. The experiments, um, succeeded oddly.

New ship, new sounds, learn new tricks, amaze your friends, confuse your enemies. Apply now! UPDATED!

I think today we'll do waves of asteroids. And some tests.

I've made yet another mistake. Will the embarrassment never end?

I reckon it's time to kill the ship when it's hit by an asteroid. I have a clever way to do it and a direct way. Which is best?

I'm feeling like coding a bit this evening. So stand back.

Thinking about tests and refactoring. The boss wants a feature.

I think it's time to move more toward objects. Part of our mission is to decide what we like. And: 'No large refactorings!'

I thought I knew what we had to do today but I was a bit mistaken. We need more, and better thinking ... and code.

Just arriving 'at work' this morning, I'm thinking we'll make the Ship move. We need a safe place to land first. EDIT: Arrgh, a defect!

A report on last night, and a 'major' refactoring. P.S. There is no such thing as a major refactoring.

A quick report on a short project last night, then let's try to get something nearly playable.

I looked up tween and my tween example and it seems like just the thing. Let's find out.

First, I'm really feeling the need to improve this code. But maybe it's too soon to do good work? Plus explosions.

Displaying different shaped asteroids is nice, but we have an issue of size we might work on for a bit. And let's split them!

Having converted the 6502 asteroid shapes to Codea style, let's plug them in. This design is starting to bug me, and we'll think about that too.

Dave1707 offers a much better idea for the conversion of Asteroids graphics into Codea. Let's explore it.

I found the definitions of the asteroid shapes in DVG language. Let's draw them in Codea.

I spent last night decoding some graphics chip code on computerarchaeolgy.com, and I managed to draw an Asteroid in the classic style. Today, a look at what I found out. Updated: New Resource.

I've decided how buttons should work. It only remains to make it so.

To move forward with this project, the ship needs to be able to move forward. And turn. And fire ...

OK, Asteroids doesn't have a horizon, but today we'll start on the ship. Shouldn't be too hard: it's a triangle.

I needed to test some floats the other day. Let's improve CodeaUnit to help with that.

Today we'll clean up the code a bit. It really needs it.

Today I decided to draw two square asteroids at random angles. All's well that ends well, but I did get confused.

For something to do, and because it might be helpful to new Codea users, I'm going to implement an homage to the old Asteroids game.