Category: kotlin

Part of a short series on design, static vs dynamic languages, god objects, and our ability to understand the code.

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?

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.

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

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?

Let's see if we can figure out a clean way to accomplish yesterday's accomplishment.

I think I'll do a bit more on darkness. With some TDD, of course.

Two stories loom before me: some kind of a magic bridge, and darkness. One of these is easy.

I have in mind recreating, or ripping off, some special rooms from the old adventure. Ideally, I'll be able to build these with no new features. Whether we have all that we need, I'm not sure. We'll find out.

In honor of the occasion, I think I'll sum up my current thoughts, feelings, notions, regarding Kotlin, IntelliJ IDEA, and all that jazz. I admire good work. These are good.

Why am I putting so much wonderful capability into a game-making system that will never be used to make a game people will actually play? To tell the truth, I kinda lost track ...

Sometimes something really simple is not obvious. This may be a case for pair and mob and ensemble programming.

Further thoughts on the past few days' transformation, followed by looking for similar opportunities.

Can we remove the duplication of the action methods from World and Room? Let's try.

More world-building.I'll try to devise some affordances.

A bit of world building. Will it point up any notable needs? Oh, yeah!

What shall we do today, Brain? Same as every day, Pinky, try to create a world.

It's 0420 and I have an idea. I figure never pass up an idea, so here I am at the keyboard.

I think the Covid jab hit me this time. Just a short article. Anyway, it's Saturday, what do you expect? (We do stumble on a nice result.)

Typing 'go blue' instead of something like 'go east' results in a runtime exception. I take exception to that. Let's fix it.

Converting the enums to Kotlin's preferred rules. Published for the record, whatever that means. Probably means, scan or don't read at all. Nothing to see here, move on ...

Just a bit more play with the Direction and Room enumerations and related code. Should I work out why 'e' doesn't work, or just make it impossible?

I don't know quite what we'll do this morning. Something fun. Let's start by talking about good times.

Often tiny changes can have very desirable effects. When that happens, it may be a sign that things are in decent shape.

Feeling rather done with Gilded Rose, I take another look at the text game building code. There are issues.

It seems to your faithful author that we've done nearly all we can with the Gilded Rose. We'll take a final look. Or maybe not final. Who knows?

I want to try another approach to the product-type lookup. I have to try it to see if I like it.

We'd like a better way of getting from an items name to its type. We'd like it to be bullet-proof, but not difficult to manage.

I was glancing at yesterday's article last night, and noticed some truly odd code that IDEA generated for me. We'll start there, and I have some improvements in mind.

We are supposed to implement a new feature in the Gilded Rose program. Let's do that ... and let's take a look at where we are ... and where we might go. (Final: We go somewhere rather nice!)

The point of a kata is that we do it again and again, practicing to get better. This isn't really a kata, but it's somewhat like one. (Outcome: Two points to GeePaw.) (UPDATE: Not a bug! Woot!)

I do some microtests. Didn't even take an hour, including writing.

Let's see if we can wring a bit more out of refactoring the Gilded Rose. (Some wiggling back and forth to slightly better code.)

Continuing the long refactoring from the previous article.

One course seems obviously better. I shall choose the other.

Articles 76 and 77 are a long, tiny-step refactoring. Here, we'll preview where we started and where we wind up.

Yesterday the FGNO / Zoom Ensemble played with the Gilded Rose. This morning we'll look at it here.

Mostly I plan to solve the water problem this morning. But I'm wondering about concision. When is enough too much?

Two small changes for your amusement. UPDATE: No, three! Thanks Christian!

Wrapping collections keeps the tricky stuff inside and offers nice clean easy stuff on the outside. That's why we do it, right there.

This morning I plan to encapsulate my map of Item instances, and show why I think it's a good idea. In addition, I'll clarify what I mean by 'always' and 'never'.

Let's keep banging away at the new Item. We'll make them a bit smarter.

Yesterday's work on using the DSL turned up some issues. None of them surprise me—but that doesn't mean I know how to deal with them. Or ... do I? (And: I seem to be feeling whimsical.)

Let's do some world-building, with tests. OK, I admit it: no tests yet. Barely made it work.

Let's fix one of those 'lateinit' variables. They're definitely a code smell.

Some things seem to me to be happening at the wrong time. One issue is the GameResponse. Another is in building the world. What ever shall I do? (I 'discover' TODO.)

Some tidying, but I do need to find a smooth way to do it.

There's not really much left to do here, if my purpose is to build a DSL for Zork-like games. That's a big problem. Today: A nice refactoring in tiny steps.

A quick test of a simple idea seems good. I am pleased.

Let's make some progress toward Room actions. Some fairly nice refactoring and feature addition in here. Includes: praise for IDEA and Kotlin.

Let's see if we can untangle things a bit in and around Imperative, Phrase, and the like.

Back to the Phrase-matching find. I'll grow it incrementally this time ... and it works! Life is good.

OK, with that off my chest, we can do some code. Let's keep after Actions and the associated items. Things do not go as I expect.

I think this morning's thinking was good enough to deserve a chance. Could my thinking be wrong? It has happened before.

In which, our intrepid hero realizes that while thinking is good, clear thinking is better than muddy thinking.

A really nifty idea collapses. Yet, I ain't bovvered! Come read and find out why.

Let's do a bit more on the SmartMap, and then try to get it in play. (Spoiler: It works nicely! I am pleased.

I have what I think is a very nice idea. Let's talk about it and then start working toward it. Is this BUFD?

Now I'll try adding something to my actions collection, first in regular code, then tomorrow I'll try to add the capability to the DSL.

Let's look at the Actions in the new Imperative. Advice from my betters suggests I could do, well, better.

Report and confession on last night and some behind the scenes grunt work.

Let's make the Actions in the Lexicon do their job. There are some issues ... do we resolve them? We do and it's great! A big lesson is relearned.

This time around, I'll plug the Imperative into the game, or know the reason why I couldn't. I'm hoping for the former. (Spoiler: works!)

Let's find more small steps toward replacing the old Command idea with Imperative. I have in mind providing a Lexicon in the existing structure.

I want to move the testing bits for Imperative back down to the test branch, segment, section, whatever it's called. IDEA impresses me.

This morning, I want to try a different way of mating the new Imperative to the existing scheme. First, I'll have to figure out what that scheme is, and whether there's anything in it to like. I suspect there is.

Let's put this in context. No, I'm not explaining. We're going to put all this into Context. Includes Shiny Squirrel pattern.

Let's see about converting the `when` to a table. Sounds easy enough.

A bit more work with the new Imperative. In reviewing the code, I'm not sure what else it needs to do the job. After a bit of testing and enhancing the tables, I'll think about whether and how to use it.

This morning I plan to share some early thoughts and perhaps turn them into code. (To enjoy this article, please set your expectations to 'I wonder how Ron might go from a vague dreamy idea to something that might actually be useful'.)

I think I'll experiment a bit with a Command object and its context. I'm not sure where this will lead. Perhaps to the bit bucket.

Some interesting insights from last night's Zoom inspire me to morph my design. A lot of thinking, a little coding. A decent direction, I think.

A fix for the warnings, but do I like it?

Today's plan: plug in the new parser. We'll need to refine it just a bit, but I'd like to get it in play this morning. Best laid plans ...

Let's see about cleaning up that `expand` method.

It's 0525. I want to begin to try something before actually starting my day. This may go somewhere interesting, or crumble to sand in my hands. (Spoiler: I think it went rather well.)

Refactoring in the direction of what we think we might prefer. Beck said: Make the change easy, then make the easy change.

I get good advice from my betters. In the face of that, I forge ahead.

Let's do some very simple parsing.

A little refinement, and then let's press forward on Picov Andropov objects.

At a more civilized hour, I have an improvement in mind. And it's really time to start doing something about inventory. And, curiously enough, I am rather successful.

It's 0415 and I'm awake, with what seems to be a good idea. Is it a good idea to program at 0415? That remains to be seen.

Let's push the Spike in a little deeper. I've got some ideas for how it could be quite nice. Good ideas? We'll find out.

Yesterday, in an astounding flurry, I made a magic word open a lock. I also made a bit of a mess, which is partly good but probably mostly bad. Today, I set out to improve the code—and the feature. (As usual, that's not what happens.)

I want to set up a test world where you have to say a magic word to open a door, or something like that.

Still working toward the View displaying our new 'say' text. Might make it this morning.

I think the next thing I need is for a message to come out in response to a command. We need an extension to GameResponse. (For once, reverting would have been the wrong thing to do ... probably.)

I have some design thinking to report, but my hope for today is to have an operating grate somewhere in the world. I manage a good first small step.

I need smaller steps. The Game sends the command to the current rRoom. But the World knows the rooms, and neither the Game nor the Room do. Let's try passing the World to the Room.

In order to find out what our DSL should be like, I propose to code up a few scenarios 'by hand'. I make some progress but not as much as I'd hoped for. Lost thread. Reverted. Good man!

Now that the game can be played, more or less, it's time to think of some scenarios that we need our DSL to support.

Inching forward. Pretty sure I can make a TextField work. Final Result: The Game is Playable!

There must be text things in JavaFX/TornadoFX. Everyone has them. How hard can it be? Wow, I hate being ignorant. But I love learning!

How bad is it when you actually EXPECT your own article to be boring? I'll do my best to say something interesting. Includes a very long sentence and a small but important win.

Time for a little planning, and some worrying. How far can I go before making this thing somehow playable? How far should I go? Bonus: A devil duckling!

I wonder what we can do about output without actually having a way to play the game ...

I'm psyched after two consecutive sessions with some success and no big troubles. What could possibly go wrong?

How about a bit of code improvement? That might be fun.

Let's parse a bit more of the DSL (Dungeon Scripting Language?) and then see what happens. I have high hopes, tempered by decades of experience.

Let's try something specific with the DSL builder idea. I have in mind a text game like ADVENTure or ZORK.

In which your intrepid author suddenly realizes something, and decides to do something he rarely does.

I want to understand DSLs and builders. First, I have to figure out how to make a new project with tests in it. I anticipate an onset of grumpiness as I learn new things.

OK, I'm feeling like working on acceleration.

I have tidying to do, and some stories to implement. At this writing (0815), no actual plan.

So few lines, so many design questions. We'll work more on Ship motion. (I manage some whimsy. Must be getting more comfortable with IDEA/Kotlin.) P.S. Learned a thing.

OK, let's see if we can code up an operator in this baby. Overall Result: Much more comfort.

Let's plug away, learning IDEA, Kotlin, and whatever, while also seeing how much TDD we can do on an essentially graphics-oriented game.

First some grumbling, then an idea for something useful that I've not done before.

I'm inching forward in my learning of Kotlin and TornadoFX. Progress is happening, but so slowly that I can't write as I usually do.

We've all agreed to fork the repo. I'm on my own, more or less, and already confused even though I haven't even started.

After more than a little hassle, my colleagues and I have a Kotlin shell that we can pass around. Today, for fun, I'm going to try to write some tests and code.