Category: openrndr

Today I want to try to think about the decentralized version of this program, why I like it so much, despite that it is clearly harder to understand.

We have three versions for a reason: comparison of their designs. Let's do a bit of that today.

Let's give a splat to the Saucer and maybe to splits.

There's supposed to be a graphical effect when the ship explodes. Let's produce one.

Yesterday as I was summing up, I had an idea for a different way of handling the multiple shapes for asteroids. Let's try it.

It seems that it might be interesting to make the Asteroids spin. I don't think they spun in the original game, but hey this is the 21st century or something. But wait! You also get varied Asteroid shapes!

Today I am quite tired of Asteroids, and particularly tired of this version with its very weak structuring. The foregoing does not constitute a plan.

A bit of duplication starts me off this morning. A nice result, I think. YMMV.

We need to fix safeToEmerge and let's do zigzag. Features! Woot!

Let's get started on the saucer firing at the ship, which I think is the largest remaining "requirement". Added: My testing game is weak today.

I just noticed an opportunity for improvement. Will I stop at just one?

This code is hard to navigate. What can we do to make it easier? Nothing to see here except ... Squirrel!!

This morning we'll try to do the "safe emergence" feature for the Ship. I am filled with troubled antici ...

This morning I'll just continue applying the new Timer, plus whatever catches my eye. At least that's my plan here at the top of the article.

Let's start moving our new Timers into a separate table. That should be "easy".

OK, you talked me into it. Let's see about doing the System part of Entity - Component - System, just to see what it's like. Plastic Sliders??

Now that we've got the PluggableTimer working, let's make two that should be a bit more useful. Added in Post: You may touch the hem of my garment.

My "Jira" is some sticky notes on my keyboard tray. Maybe yours should be as well. Anyway there are some things we might do.

Let's think a bit about making a saucer timer and/or a ship timer, using our rudimentary component system. I think it'll be easy and perhaps educational.

Well, of course I've made a mistake, rather good at it in fact. But have I broken the saucer timing?

Let's see if we can shoot down the saucer. That shouldn't be too difficult, except that I can't remember what the score is supposed to be.

Let's compare the asteroid implementation in the flat version versus the centralized object-oriented version.

Let's just do some little things. Rotate the asteroids, maybe add in the other shapes. But no: A refactoring goes awry. Or agley, I don't know.

Last night we briefly discussed a comparison between my versions. Let's think about that. Alligator?

I think it's time to start on the saucer. What do you think?

There's duplication in the collision logic, and I manage to eliminate most of it with some very simple steps, almost all automated. Nice!

Let's do the drop in animation and the slowing down due to inexplicable friction in outer space's near complete vacuum. Ooo! A lesson unlearned! I wish I were more wise.

After yesterday's social concerns, I'd like to turn my attention back to happier matters, the kill-or-be-killed environment of the intrepid men and women who shoot down asteroids in the interest of humankind.

We're keeping score in our head. Let's display it. I fully intend to steal the code for this from another version. We also handle ship-asteroid collisions and provide respawn.

I've forgotten that the ECS technique provides for a bit of polymorphism. We need some and will soon need more. Let's see if we can make that happen.

Today I plan to implement the ship's flare. My reasons are not all good ones.

It's past time for some cleaning, and if I'm on my game, some tests.

Rather than clean up the code more, I intend to bash in asteroid splitting. This is not wise but should be amusing.

ECS is supposed to be more performant because of memory locality. Does memory locality matter on my computer? Let's try a simple way to find out. Also: We kill some asteroids.

I have some thoughts on Entity Component Systems design for this program, and perhaps in general.

I'm not sure what to do this morning. Maybe an asteroid. There are other options. Also: Beck's Rules of Simple Code.

Some design thinking leads the cat's servant to think we can improve our nascent ECS component.

I may be moving toward Entity-Component-Systems design. Let's find out. Further Cat Scripture.

Kotlin's `object` could help me clean up the globals a bit. Shall we allow it? Also: more Cat Scripture.

I think I'll do a bit of cleaning this morning, then maybe other things. I've been given an idea.

I just punched in some code to aim the missiles. Let me share it with you.

Today we'll start bringing things a bit more into a sensible structure. Just a bit.

Perhaps we'll try to fire a missile today. Unless something else comes up.

It seems clear that this 'flat' no-objects version of the game wants to know certain key objects. Let's see how we might deal with that.

The new flat version can draw a ship and an asteroid, both poorly. It can move them along the screen. Let's see if we can 'refactor' toward an actual design for the game.

Let's add a simple object type to SpaceObject. That should let us do drawing in a more generic fashion. Update: Found a better way.

I think we'll do a bit on the ship. That will require me to think a bit about coding standards up in this um program. In Post: This is actually getting interesting!

I often predict in these lines what I'll do, and only rarely is that what actually happens. today I don't even know what I'll try next.

I'm going to try Asteroids in a third fashion, this time more procedurally. I just want to see what it would look like.

I'm working toward some small improvements to the delegation code. I'm not sure it's worth it. I think we'll have to try it to find out.

I think there's a simplification to be had, and none of you people suggested it to me. TAP TAP. Is this thing on?

Let's keep simplifying and see what we can find. Let's work to eliminate the Collidable collection.

'Your scientists were so preoccupied with whether they could, they didn't stop to think if they should.'

In our Zoom meeting last night, I got some possibly conflicting advice. I have an idea for how to resolve the conflict.

It is not given to us to be perfect, nor to do perfect work. But this program, surely it's close? Let's talk about the value of tiny improvements.

Now that the Collision Strategies area all broken out, let's have a look and see what we think about them. Am I reversing yesterday's work? Yes, some of it. That's OK. (Ninth decade? Really?)

After an idea that doesn't pan out, we complete the installation of CollisionStrategy objects. We begin assessing what we like — and what's troubling.

We'll try another one of our CollisionStrategy things. I was hoping for some reuse but am not clear yet how to get it, nor whether its really worth it. I think we'll complete all four Strategies and then look around.

Delegation using Kotlin's `by` seems not to be quite the thing, though I believe I could make it work. I think that late yesterday I invented the Strategy pattern. Let's find out.

As promised, we'll discuss `by` delegation, but I now think that it isn't going to be as useful as I had hoped. I could be wrong, and — oddly enough — hope that I am.

Let's simplify some tests. I think we can get `knownObjects` out of Game.

Let's see how we like the look of the new GameCycler, and review how it went. There are things to do. Could we get more objects to be immutable? That would be interesting.

Let's move some more code over into GameCycler. We complete the Strangler!

Let's look at cohesion, duplication, and other considerations. Maybe we can get a bit more gilding on this lily.

I've gone back and forth on how much type information to preserve. Let's try to compare the two.

With the simpler SpaceObjecgCollection in place, it's time for Transaction. Do we just check out the old version? No, we do not. But why not? Also: You are waffling, sir!

I think we're ready to try the new simpler collision scheme, which is really the old collision scheme from before we started this centralized version. We'll discuss further whether this is a step backward or forward.

I really thought I was finished improving the centralized version, but these small changes will, I think, make things much simpler overall.

There's a lot to like about the centralized version, but this morning I realized that it's far from ideal. Let's explore why and what to do.

Let's explore some possibilities for improvement. Maybe we can even reduce some duplication. That would be nice. Added in Post: Almost a complete waste of time! Dammit! My hopes are dashed!

Last night, I made a change that I now believe to be a mistake. In fact, I did it twice. Further: We begin to draw a conclusion.

With changes to Transaction, I think I can get rid of most of the type checking in the system. I could be right ...

I think that code in Missile is a bit too clever. I may have a better idea. Let's find out. Also: remarks on Jira.

Let's rename all the `interactWithThisAndThat` to `interact`. I think that will reduce unnecessary noise. We'll see.

The new Interaction object is in place. Now let's work to unwind the calls through Subscriptions, moving toward simplifying the hierarchy. Added in Post: Woot!

Let's do interactions in our new type-sensitive style. Let's do it with an object. Let's test-drive the object.

Let's try replacing interactions all at one go. It might not be too difficult. In Post: I do it, it works, I roll it back.

I think we just have one more `finalize` to remove. After that, well, I hope not the Deluge. Also: Do you have a lessón for your minkey?

I'll take another run at finalize. I expect to succeed this time. I could be wrong.

Today, probably, we'll push on with making things more cognizant of type. Probably in Transaction. But let's think first. (Added in Post: we don't do what I thought.)

I'm rather sure there is no active use of the `attackers` and `targets` collections. Let's remove them.

We're engaged in a somewhat extended diversion in our centralization effort, aimed at making better use of Kotlin's strict typing. Let me explain.

Last night, in a stroke of good fortune, I was schooled by GeePaw Hill. I may have learned an idea, and I may be able to learn to apply it. Also, ducks, and an oblique reference to a koala bear. Added in Post: Nice result so far.

Let's experiment today with the sketched collision logic that I threw in a number of days ago. Maybe it has been long enough to see its flaws. Hypotenuse!

This morning, we Big Plan a bit, then do small changes. We're refactoring toward a new design: we're not doing a big rewrite. It's going quite well.

I think we can simplify things a bit by adjusting the hierarchy of our space objects, now that a number of subclasses have been removed. Let's see if I'm right. It could happen.

I had an idea the other day, something I should probably have done a while back, so with a little time this afternoon, I'll try it now.

I plan to wrap up the centralized version of Ship creation this morning, with the concomitant removal of two classes from the mix and the system.

I have a cunning plan for doing the ship insertion in the centralized version. I predict that this is going to be nice.

I have a little time. Let's try another experiment.

It's time to address centralizing creation of the Ship, including hyperspace. This is one of the more complicated bits in the game. (Ron keeps a spike. Shall we withhold his treats?)

I have a test that sometimes fails. I have no notion of how that can be happening. Let's find out.

As we centralize more and more code, the Game class is getting messy. Should we start to improve it now, or let it get worse before it gets better? Some thoughts about thinking.

I have a little time. Let's see if we can take a few small steps toward wave-making. Should be possible, I had it working yesterday.

Today, I was hoping to finish up the new centralized wave-making. But first I need to bring my testing up a bit. Added in Post: Includes Ron's Jira.

Today, I think I'll start on moving the WaveMaker logic into the game. There are issues.

I'll begin this new year as I ended the old one, programming and writing about it. Today, I think we'll work on score.

Now on a somewhat better build, I'll begin by redoing yesterday's changes, and then continue with the centralizing work. Bison?

Continuing to work on creating a centralized version of Asteroids, for comparison with the current decentralized design. Amazing the things I don't know how to do.

I think I can start on a collision detection thing. Shall I test it, or spike it?

An insight and an idea show me a way to approach centralized control. I think it'll be quite nice.

Let's try another way of decelerating to see if we like it better.

While I muse about a different design, there are a few things that we need to do, and I need something to distract myself. Things go oddly but turn out OK. Details in Summary.

Not that this version is exactly done, but I was thinking: Would it be interesting to start over and do Asteroids in a different style?

Going to try for a light morning, as I have an appointment. Let's check the checklist and pick some small but beneficial changes

Yes, I know there's a closed-form solution for targeting. Let's see if there's something simpler. But first, a bit more safety.

The Saucer can fire targeted missiles. Let's explore what we might do about that.

'When things get too complicated, add simplicity.'' Let's try that.

An issue in the design troubles me. I'm not sure whether it really should trouble me, but I think something needs to be done. I really find this hard to think about. I'll discuss why at the end. And I'll tell you what you should do.

The Kotlin game appears to me to have a different scale factor between asteroids and ship. I don't see yet what's going on. I discover that I've done a very poor job. Don't read this, it embarrasses me.

Can you believe that I forgot the flare of the ship's exhaust when it accelerates? No wonder I can't win this game.

The original game spawns more and more asteroids. I'm terrible at the game but I guess we need the feature. Just a little afternoon playing around.

The game should display some info about the keys to operate it. Not that I don't know, or the other person, but there might be one more person ...

When it's GAME OVER and we want to go again ... where do we put the quarter? A HARD DECISION: which way would you go?

I'd like to clean up ship emergence. I believe it can be more clear and if it can be, it should be. BONUS: A movie of the most interesting bug so far.

I think I've thought of a defect. Let's find out.

Best laid plans scarcely get past the first paragraph.

This morning, out of the blue, I plan to assess a core aspect of my Asteroids design: the subscription model. The conclusion surprised me. (Yeah, click bait. Skip to the end if you're that way.)

the OneShot and DeferredAction are looking for places to be used. It's 'small boy with hammer' time!

In which, our intrepid hero has yet another idea. Will this one be better, or just another idea?

Got this thing, might as well use it. Let's eliminate WaveMaker.

Where do ideas come from? I don't know. Where do they go? Into the code, of course.

The game is supposed to give you a finite number of ships. And it's supposed to be possible to earn new ships at certain levels of point score. How could my 'independent' objects do that?

Finalize existed because an object could be destroyed by another object. The unwritten rule now is that objects do not destroy other objects. Can we get rid of finalize?

I improved the Splats a bit last night. I report on last night, think about design, improve Saucer some more, and feel rather ashamed of myself. But good, too.

Let's have the saucer fire randomly. Should be about what I need for an afternoon session.

Let's give the Saucer some more capability. And a question/request to readers.

Too much duplication in colliding. Let's sort it a bit.

As much fun as I'm having with the odd simplicity / complexity mix of this program, it's time for a feature. We'll do the Saucer ... or at least start on it.

Still thinking about the essence of this design and what it implies. This time for the game, not the world. I am fascinated and love what it is ... and isn't. In a real sense ... it isn't a game at all.

I'm renaming Interactions to Subscriptions. IDEA helps. What else?

Now that all the SpaceObjects are broken out, we have duplication. Let's see how much and how we might improve things.

I think I'm ready to create a Ship class and remove SolidObject (or turn it into ship, whichever works. Let's do this!

I'd like to get my version of this thing closer to the state of Hill's, so that whatever changes he comes up with are easier to assess, and to learn from.

GeePaw Hill and I paired remotely for about three hours on the new 'Interactions' idea that I am borrowing from him. It went rather well, though differently than I had expected.

I feel that I understand something when I can do it, not when I can just use it. Let's try to learn Hill's latest idea.

I want to break all the Solid objects out into separate classes. Have not yet found a smooth way to do that.

An imaginary chat leads to a determination to push this design as far as it can go. Along the way I face an apparent fact.

In which our intrepid author expresses frustration and then gets down to making the program better.

Let's see if I can sort out the HyperspaceOperation a bit.

Fundamental theorem or not, implementation inheritance the tool of the devil or not, what we have is better than anything I can foresee. Full speed ahead! (Three false starts, then success.)

The Fundamental Theorem of Software Engineering is 'We can solve any problem by introducing an extra level of indirection'.

Hill has been learning the code with an eye to helping me understand why he is right and I am wrong. I fully support this and have some comments.

Having written up the theory of the game this morning, this afternoon I feel pretty certain that what's supposed to happen isn't really happening. We need to see what's to be done about it.

Implementation inheritance, or delegation? I've chosen the former in a fairly big way. Why? It seems that I'm evolving a sort of 'framework', and to make it do what I want, I think I need this inheritance. Some may disagree.

A change improves many objects. Summary follows.

Kent Beck has me thinking about cohesion and coupling. Let's look at the ShipMaker with that sensor turned on.

We replace ShipMonitor with ShipChecker and ShipMaker, about the same number of lines but far less intricate. A win.

Tidying. Why are we all setting asteroid velocity?

I'd like to push the new interaction scheme a bit further, returning something less basic than a Pair. A day to make the code a bit better.

Sometimes you just know you have a good idea. Sometimes you're even right. Is today one of those sometimes?

What if we run out of asteroids? What shall we do? Is a GameGod trying to be born? Sorry. Nope. Won't do that. Minor deities, that's one thing. One thing to rule them all? Nope.

I have dedicated the next portion of my life to implementing that cool hyperspace emergence rule. It means that I have to be able to count asteroids. So be it. But how? You'd think it'd be easy. It isn't.

Info from a viewer leads to a question. The answer leads me to a bigger question: Why didn't I think of that? THEN THIS ARTICLE GOES SIDEWAYS.

Let's do hyperspace ... and try to do it right.

My Zoom Buddies made an interesting observation. I choose to respond productively.

Things are a bit ragged here and there. Let's just trim them up a bit.

When things get bad in space, your ship has a hyperspace capability that will remove you from normal space and, after a delay, insert you back somewhere else. There is a chance that you'll not survive the attempt. Our mission today: implement this capability. There are issues.

Before a respawned ship appears, the game is supposed to check to be sure that it won't emerge colliding. How, in our distributed system, can we do that? At this writing, I do not know.

In Asteroids, after your ship dies, if you are allowed any more, a new one appears ... somewhere. Let's see how to make that happen.

No, not young people tweens. Tweens are little objects that do interpolation for us. I think we should have them. P.S. Dealt with that little lifetime issue.

It's 0500, way too early to be awake. I am awake. To keep the demons away, I think I'll see about narrowing the Flyer creation interface. As one does.

Hill tweeted something. Perhaps it had been mentioned at the Zoom Ensemble but if it was I missed it. It seems like a good idea. Spoiler: It was!

Options abound. further cleanup of Flyer seems prudent. But it might be fun to do the Splat. So many choices. Splat wins.

Looking at Flyer collisions, I wonder how it would look if it didn't look like it does. P.S. Two more little refactorings. Free of charge!

I think something needs to be done about the growing mess in the flyers. Let's take a look and see what we see. I'm trying to honor GeePaw's concerns ... and yet ... and yet, I go a different way than I anticipated, with better results.

It's about time ... to work on time. I think the code is telling me something, but I'm not sure just what it is. Shadows in the mist.

I have in mind some learning to do about Interfaces, and possibly abstract classes. I want to work on scoring, and I have in mind a way to do it with a flyer. Spoiler: He shoots! He scores!!

We have an interesting architecture going here, unlike any I've used in these games before. Let's see if it can go all the way.

What shall we do today, Brain? Let's see if we can get this baby under some semblance of control. Spoiler: It's ALIVE!!!

I believe I learned enough yesterday to make a good job of the ShipMonitor today. One question is whether to start over, or move forward. I make the right decision, of course.

I have what seemed, in the early morning hours, to be a good idea. Is it? Let's find out. ARRGH: What we may have found out it that it's too cute to live. HOWEVER: There may be a clean way out.

Let's get the display loop running on a Game instead of a couple of ships. Then I'll see if I can figure out the keyboard connection. Probably.

OK, I've seen it move. Should I plug in drawing for each element? Or test controls?

Creeping up on actually having to display some objects. Maybe I should just do it today?

We're like ten articles in on a video game with no video. This is rather interesting. I'll try to explain why.

I may not get much coding in today, but I have some ideas and will set them down in the few minutes before I have to head out.

The Zoom team 'might have done differently' but agree that current code isn't signalling very strongly how it wants to be. I guess today I have to add more of a mess.

This morning I'm wondering whether I made a mistake yesterday. Well, I must have made some mistake, but I have a particular possibility in mind.

It's lonely in outer space. We need some other stuff up here.

Space objects, as everyone knows, have a maximum speed limit. This morning, I plan to implement it.

Space objects, as everyone knows, have a maximum speed limit. This morning, I plan to implement it.

I seem to be zeroing in on an asteroids kind of game in this exercise. That's probably good, because I've done asteroids at least once before.

I managed to make a test work in the Ship project (its new name). Let's see what we can predict about a game design.

A growing list of questions, and hopefully answers, as I learn about Kotlin, IDEA, OPENRNDR, and all that jazz.

I want to play further with OPENRNDR. I've skimmed the docs. I'm impressed, and probably dangerous.

Yesterday, the OPENRNDR starting project ran on my machine. Today, before studying the system, let's take a look at the code and tweak it a bit.

This morning, I'm going to try to get OPENRNDR running with Kotlin on my machine. I've seen it done on a Mac and on a Windows machine. What could go wrong?