Category: pygame

Changing the rules a bit, yesterday, limits the richest player to around twice the starting amount. But are there still permanent winners and losers?

Bruce Onder appears with an interesting idea. It does make a difference.

Here's what my little simulation makes me think. Reflect upon the ideas of Richard Skelton and Robert Fitzooth. And maybe upon mine as well.

Let's clean up this code just a bit and then draw some conclusions about programming a thing like this. Clickbait: The technical conclusions are not what I thought they would be.

We recover quickly from a mistake last night, and get a nice histogram. I'm surely reading too much into this little simulation. Or am I?

Let's tune this thing up a bit. And let's try to avoid momentum calculations. P.S. The rich get richer.

I've been pecking away at the little simulation. Here's a report on status. We get some early results: the rich get richer.

"The rich get richer." I propose to pivot to implement a simple but interesting simulation. A good start after the usual trouble creating a new PyCharm project.

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.

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.

Rightly called on my B.S., I strive to improve by running some timing tests on this tiny patch of code.

I'll point you to a fairly famous anti-clean-code video screed, comment on that, and explore the efficiency, or lack of it, in our little billiards program. I notice something surprising. And something important.

Rotation of vectors isn't second nature to most folks. Let's describe how my little Python billiard ball reflection program works.

Today let's review the code and improve it a bit. I think PyCharm can help with that. Same refactoring, four times!

We should probably keep score. Shouldn't be terribly difficult. Just some text ... how hard could it be?

For the next day or two, I'm going to do a little exercise on the game of billiards. Very simplified, of course.

Let's add the help messages to the GAME OVER screen, and, time permitting, work on quarter insertion. I expect the first bit to be mostly tedious.

Let's clean up startup and maybe we can come up with a finite supply of ships and maybe even GAME OVER.

I think it's time for asteroid waves. Let's review stories. We create some questionable code and question it. It confesses and tries to reform. What do you think?

Let's do safe entry. Should I put this thing up on GitHub? No one has asked for that.

We'll review and refine the list of things to do and pick something. Doubtless fun of some kind will ensue. Loving PyCharm's auto-run of the tests!

Just some random cleanup, unless I get an easy idea.

Today's story is to make the missiles damage asteroids. But I have a larger question. P.S. I am the Cat ...

Let's see if we can make this thing fire a missile.

Our fun with delegation, plus an early call to breakfast meant that yesterday I didn't get to collisions. Let's work on that today. [Ron makes a rookie mistake.]

It's time for more features and less playing with drawing. This leads me to think about common behavior in motion and collisions. Ron learns something about inheritance and delegation!

Let's do to the ship what we did to the asteroids. And some thoughts about the future.

My search for why the window is double-sized caused me to observe that I can't scale my objects to arbitrary sizes. I think part of the issue is coupling, so that's interesting.

I noticed a graphical anomaly and think I can fix it. And another that confuses me.

One more tweak on the SurfaceMaker, then lets see about using it to make more asteroids.

I'm still pecking away at improving the surface creation. I'm wondering if my caching object, tiny as it is, is more than I need. We'll see. I think I should take advantage of the limitations of the current situation.

I have an idea, or some fraction of an idea. Let's see what we can make of it. (As often happens, I don't go where I thought I would.)

Some advice for a better way sends me scurrying to read about list comprehensions.

We don't even have 200 lines of code yet. How can refactoring make any sense already?

I'm at a low energy point but maybe I can get an asteroid up.

My plan is to wrap the flight path, which I realized last night is 100x easier than I've been doing it. But I was reading about the Rect object ...

Let's just inch forward by making the Ship turn ... and inch forward. I think we basically know how to do this. (I do quite a bit of refactoring, an odd thing to do in a spike.)

I've learned two ways to make the ship transparent. One of them is a good way.

OK, let's fare off on our own here and see about drawing a ship. As I am new to Python, this will entail learning how to create a list or array or one of those things.

I've decided to work with Python a bit. I think I'll enjoy it as much as Kotlin, and I'll certainly enjoy being further away from Gradle.