Category: arcade

I was watching Antiques Roadshow, as one does, when it came to me that a tiny object might be just the thing for DungeonView. Let's find out.

I've decided to commit this and refactor. Can always reset if I have to. General rule: try always to move forward.

OK, let's do the thing we love: find something to improve, and improve it. Shall we start where we left off? Result: Not as joyful as some days.

About programming. A few thoughts on what I do, and why I enjoy it so much.

Writing a note to ask for ideas, I got an idea. Let's see what happens with it. Result: I think it turns out nicely.

Received wisdom and personal experience tell me to cover built-in collections. Here's why.

Resource designation is awkward, and I think we're loading them multiple times. Let's see what we can do about this. Arcade helps out!

I have one. Very small but I think it'll make things just a bit nicer. We'll see.

I have an on-line meeting that I can pay only small attention to. Herewith, a report on whatever tiny changes I find.

Let's see if I can tire myself out with code. I enjoy crafting code and ain't no oligarch-feeding resource-consuming job-stealing computer program gonna take that away from me.

Let's see about removing those skulls from the path. Currently we just remove the sprites. This is more tricky than it might be.

We're on the hook for extending illumination, and we need some way to remove the Necrotic Path of Skulls.

Let's get back to work on displaying the path to things. We need a different Flooder setting for sure.

I have a bit of time where I can't concentrate deeply but can probably do some easy things. A new class reduces DungeonLayout.

We need to deal with the illumination issue in our breadcrumbs feature. Should be easy. Need to quell a rumor first.

OK, let's learn how to do the thing we already did. I plan to go in Very Small Steps. The morning's spike pays off, it seems to me.

I've thought of what may be a fun idea for the game. Let's talk about it, maybe do some of it. Spike written, thought about, tossed.

I need a little something to do. Here's something that could be done. Better code, not as easy to understand as it might be.

We'll glance at Flooder, to see if it needs any improvement (it surely well), then improve it. (Brief oblique cut at LLMs, oligarchs, etc.)

We need to improve Flooder, to allow constraining it to follow legitimate pathways. I am expecting it to be straightforward.

An upcoming feature demands a capability we don't have. Let's improve the Making App a bit. A good first step.

Knowing the fix, let's install it properly. Then maybe an idea.

Let's fix the defect. Bear bite costs me two hours.

No, a DEFECT, and a serious one. All hands on deck! Red Alert! OWOOGAH OWOOGAH!

With a reasonable design, reasonable changes are generally reasonably easy. So keep the design reasonable.

... if we can gin up something that's kind of fun. I have a simple idea that seems promising. Turns out to be Very Pleasing!

I see one more thing that needs doing. And then I propose that we have a little fun. What am I saying, programming IS fun for me. CW: Brief LLM excursion.

Let's figure out the new interaction feature, test, and do it. Success but with a reset and a general feeling of clumsiness.

We improve some code, reduce overall size and breadth of interfaces, make things better. CW: Brief LLM-"AI" remarks.

The recent refactoring around Layout and Cell gave me a very appealing idea. Let's discuss and quite likely try it."What kind of person wears Louboutins into a dungeon anyway?"

This afternoon I want to explore some alternative notions around the Cell topics raised this morning. Very promising results!

Speed report, and I noticed what looks like Feature Envy. Let's see where it leads. One serious mistake, quickly corrected. Very nice result. Some speculation.

We have a tricky problem ahead of us, but first: the tests are too slow. Nice result, very pleased.

Rested, I feel ready to do the passage-generating code. I'll TDD what I can. Maybe random seed will help.

I have a somewhat complex idea about passages, but a simpler scheme might work. Let's find out. Anticlimax: I stop just before the thrilling conclusion.

Some thoughts on how I work. It takes me a while to get there. If I got there. There must be an idea in here somewhere.

Some ideas about doors, and with luck, a bit more code.

With Content in good enough shape, I think doors can be next on the agenda. (I delete 235 lines from this article.)

A quick report on removing the old content objects in favor of the new. It goes quite well.

I think that the animated spikes are the last challenge for the new content scheme. Are we up to it? Let's find out.

I was going to say 'work', but this isn't work, it's fun. I continue to be pleased.

Not even that devious: this seems like a decent idea for the simplified Content. Decent progress.

I think we can do without the `info` object entirely. Let's find out. Bear takes a nibble but I think we're OK.

The new scheme for Content seems to be working out well. Remaining are two concerns ...

I think he's got it! We'll find out. Also: design documentation. Results: very favorable.

I think the new Content scheme isn't good enough. Planning to reset. Might save the tests.

This morning we made something work. Will it support everything we now need? Why didn't I ask that first?

With respect to Leonard Cohen, I want it simpler, not darker. Let's see what we can figure out. I am pleased.

I feel that I'm in a bit of a hole and still digging. Let's see how we might turn this around. We find ways to keep our oppressors off our backs.

I've made a notable change to PubSub, with more to come. Keyword arguments. Small apology for poor testing. We'll do better.

The new conditional-entry logic is clearly a hack. Let's provide a little improvement. Some thrashing. Method object. Satisfactory but not amazing.

While I'm in another world, let me muse about Content.

A few improvements, a bit of design thinking, and a plan takes shape. A good morning.

Let's give the spikes the ability to respond differently to control state, rather than the current fixed arrangement. Artisanal hand-crafted code, of course.

Still working on Lever-Spike connection. I was right not to panic yesterday, the snag wasn't a snag.

The spikes go up and down in the view. They need to react to a lever, and should also Deal Damage to Dot. We hit a snag, but do not panic.

Not the experimental kind, the stabby kind. Though there will surely be experimentation involved.

Let's add a Lever to our content objects. Herein, I make a prediction. Will I be correct? This one is darling, and I'm not going to kill it.

With the new event modifier, I think we can completely eliminate the button_pressed event.

I have in mind a caller-id feature for PubSub. Good time to do this, when users are few. Bears arrive unexpectedly.

I found a 1x1 transparent PNG. Let's use it for AppearingContent. A sweet little improvement.

I see opportunities for consolidation. Can we take advantage of them? Let's see. We change something unexpected. Is it too clever? Nahhh!

I think I'll try making the Button show up and down states. Sounds easy enough to spike something.

During a boring on-line meeting, I went ahead and put in the visibility logic. Let's see how things look now.

Dungeon content has aspects of model and aspects of view. Let's wrap it in a ContentView and then evolve to something more cohesive. Sort of Part I.

A few little changes to content this morning trigger some further improvement this afternoon. It's better than it was, and more capable too.

There's something not quite right about the design. Can we suss it out, or should we make it a bit worse? Lots of musing, very little code.

Sprites, yesterday and today. Refactoring the Content design, because Sprites.

PubSub could hold onto objects that should be dead. Two attempts and much fumbling later, I've learned a bit but have no solution that I like.

Amid horrendous technical difficulties, I propose to build a Strategy-based content item. In an astounding plot twist, we drop the Strategy idea!

Having chosen Strategy over Mixin, we'll get down to doing it for real.

I made some changes to the scaling of images. I'll report on that, but what I really want to do is to eliminate some duplication. I surprise myself.

The 'art' that I have for the game comes at various scales. We need some way to accommodate that. Outcome: OK, but there's a tiny telltale scent of corruption. Squidgy.

A couple of little changes from yesterday. Mostly just speculation, vague design thinking. I create an abstract class and draw an up-button.

Yesterday's idea for selecting random tiles seems tasty. Let's try it. Is it a kind of Composite Pattern? Answer: a firm 'kind of'.

I made one new texture last night, on my iPad. So I think I'll point the game to the recently-purchased set.

There is Massive Duplication in my texture-finding code. I plan to remove that. It goes rather nicely.

Today I propose to change the Border code to return a 'meaningful' string rather than those 0-15 integers. I figure I can handle something that tricky, probably.

We've agreed that our current borders scheme works, but isn't quite what we need. Let's see how to make some progress in how we make this dungeon. This pass, we prepare the soil.

Having 'done' borders, I'm learning what I want. 'Making App' vs 'Shipping App'. A bit of philosophy, a bit about why I write these words.

I have a bit of time this afternoon. Let's see what we might do about borders that would be better.

I found some of my favorite tiles and did an experiment yesterday. We have some interesting work ahead. We spike a border!

I have no idea what we might do this morning. I'm sure I'll have at least one notion quite soon. Things get a bit weird.

Let's deal with some of the PubSub issues and needs.

Things happen. People have to know about them. What shall we do about this?

A small improvement; a confession. I wind up thinking in public about how I live. CW: LLM-AI, Jesuitical

Based on a thing I did yesterday, I have an idea that I think will be quite nice. BorderedText, good yesterday and gratuitously better today.

I'm not sure what I'll do this morning. Look for something that interests me, I guess. We follow our nose. Refactoring for fun and profit.

We'll glance at the scrolling code, see what we can improve, and use it on our existing treasures.

Let's experiment with scrolling text. A bit of thrashing but a fairly decent object emerges.

We have a thin treasure/inventory capability wired in. Let's review our notes and pick something to add. We add visible treasures and console announcements with just a little code.

We have some content that is fixed throughout game play, and some that varies. We're getting close to needing to handle that. Perilously close.

I have a bit of time at the keyboard. Let's improve the dungeon contents code a bit.

Let's take a look at what might be good next steps toward a game. I'd like to get to some code today. A second personality emerges from my mind, the PDP.

This morning I'm going to put a Camera2D into my dungeon and see if I can figure out how to zoom and pan and such. I am hopeful but also expect confusion.

Let's see what we can figure out about the Arcade camera. I think we'll look at an example, and maybe bash it a bit to see what it does.

I think Arcade is in place. Do we like it? Is the code where we want it? What are our longer-term ideas?

I've added in Dot and it's clear we have work to do. Result: 1000X faster.

I think we'll take a cut at converting from pygame to Arcade today. I have a tentative idea, and I'm prepared to fail spectacularly.

Let's explore the Arcade platform, which we plan to use in our dungeon program. Here's how I like to learn a new system: by example.