I’ve had what seems like a good idea. Let’s find out.

Our mission, and we do choose to accept it, is to find a cell in the dungeon which is maximally distant from a given point, using manhattan distance within the dungeon, no shortcuts allowed. My very rough plan for this feature has been to do a flood fill starting from the given cell, retain some kind of information that maps cell to distance, and select one of the cells with distance equal to the largest we find. (There could be more than one such cell.) I’ve spent a bit of time thinking of how we could minimize the information kept, keeping track only of the current largest ones. Somehow, an idea came to me that seems much better:

As we generate the cells, which will be in an expanding wave from the given cell, each new cell that we add is one step further away than the cell whose neighbors we are expanding. So, I thought to myself, I thought, “Why not just store the distance in the cell itself?” When we encounter a cell, if it already has a distance, we don’t override that value, keeping always the smallest distance. That’s because as we expand the wave front, we can encounter a cell more than once, having taken a longer path to get there. We want the maximal direct path, not the longest path you could take if you were really bad at dungeons.

This seems to me to be a really straightforward way to build our feature:

1. Clear the distance value in all cells;
2. Build new distance values for all cells, starting from given;
3. Scan all cells, collecting the ones with maximal value.
4. Select one randomly.

I think there is probably a small miracle in item #3, where we find all the maximal ones, but it’s probably a one-liner or something once we figure it out.

Now let’s over-design a bit.

We could just add a new member to Cell, called distance or something, and use it. And I think we should do that, but it does seem clear that as the game grows, there will be lots of occasions to keep things in cells, such as treasures or traps. And there will be an arbitrary number of these things, and we really won’t want to add an instance variable for each. Instead, we’ll have some kind of list or dictionary.

So, we think to ourselves, we think “We might as well do a dictionary now, we’re gonna need it”. But then we think, “No, that is not our way. Our way is that we design for what we need now, not for some future possible need.”

Besides, everyone enjoys seeing me get my comeuppance when I don’t provide some robust big facility and then later need it after all. Except that that never seems to happen: instead, it always seems that I can readily refactor to put in the new capability without a lot of trouble. So let’s do it the simple way this time and see if we get in trouble later.

Let’s test drive a capability on Cell to clear, set, and reference a variable we’ll call path_distance.

This seems almost inane:

    def test_path_distance(self):
        Cell.create_space(5, 5)
        cell = Cell.at(2,0)
        assert cell.path_distance is None
        cell.path_distance = 37
        assert cell.path_distance == 37

I’m not sure if we want a clear_path_distance or not. None seems pretty clear. We’ll see what we want when we use it.

class Cell:
    @property
    def path_distance(self):
        return self._path_distance
    @path_distance.setter
    def path_distance(self, value):
        self._path_distance = value

Test passes. Commit: add path_distance to Cell.

Now I begin to think about how we want to do the path thing. I think I’ll work it out in a test and then move the code after I know what it is.

    def test_max_path_distance(self):
        layout = DungeonLayout()
        Cell.create_space(5, 5)
        map = '''
        11111
        '''
        layout.add_rooms_from_map(map)
        given = Cell.at(0,0)
        in_a_room = lambda c: c.is_in_a_room
        for cell in given.generate(in_a_room):
            cell.path_distance = None
        given.path_distance = 0
        for cell in given.generate(in_a_room):
            for neighbor in cell.neighbors_in_rooms():
                if neighbor.path_distance is None:
                    neighbor.path_distance = cell.path_distance + 1
        for x in range(5):
            assert Cell.at(x,0).path_distance == x

Just a straight path across the top. Should be good enough, we trust generate to work.

The test passes. Let’s reflect about what we should really do.

Reflection

This code, as we can see, is using Cell.generate, with the condition in_a_room to restrict the search to cells that are in the dungeon, not the many unallocated cells. This may be a case for maintaining a spare collection of cells instead of the complete collection we now use, with what amounts to a flag saying that a cell is in use.

A friend on Mastodon suggested that idea, which I claim I had also thought of and decided against. I can’t find their name just now but they were onto something with the idea.

Anyway we’re here now, with the full collection and our lambda to check only room cells and that’s certainly working, for values of “certainly” approaching 1.0.

I think that before we go further with this idea, we need to decide where the fundamental notion resides. My guess is that it will be in Dungeon as a stub calling into DungeonLayout, which owns the cells. It’ll probably be part of Dungeon.populate():

class Dungeon:
    def populate(self):
        dot_room = random.choice(self.rooms)
        dot_cell = random.choice(dot_room.cells)
        self.place_player_at(dot_cell)

We have not yet addressed the larger issue of generating interesting layouts populated with various creatures and treasures, presumably respectively more deadly and more desirable as daring Dot delves dauntlessly deeper into the depths of the dungeon. However those work, it seems fair to expect that they’ll be sending messages to Dungeon to get most of the work done.

I am about ready to stop for the morning. In fact, I see that it is nearly 11 AM, time to have a bit of breakfast and watch Sunday Morning. We’ll stop here.

Summary

In just a few minutes, we have open code that (p>0.9) will find the in-dungeon path distance from any point to all others. We should probably create a better test of that, but I really am quite confident. That code seems to have two aspects, the clearing of the variable and setting it. We do need to clear it because we use the absence of a saved value as the indicator that we should record the current distance.

I note an odd thing, and this is not the first time it has happened: we have code that generates the cells and then we do something to the provided cell’s neighbors. I don’t recall where else we do that, but I’m sure that we do. That suggests to me that there may be an opportunity to consolidate that duplication somewhere. Note made.

We should have little or no difficulty moving the code over to Layout and certainly wiring up a connection through Dungeon will be trivial. I just don’t want to do it right now and after all, bacon is important.

See you next time!

We’re working on finding a cell that is maximally distant from a given cell. What are our next steps?

My work yesterday was somewhat interrupted by local matters, so I have even less recollection than usual about what was done and what should be next. I didn’t even leave a non-running test as a reminder. Fortunately, I did append yesterday’s tests to the test class, so those should give a clue. They included:

    def test_string_layout(self):
        r_0 = [(2,0), (2, 1), (2,2),
               (3,2), (4,2)]
        r_1 = [(0,4)]
        r_2 = [(4, 0)]
        string_map = '''
            ..0.2
            ..0..
            ..000
            .....
            1....
        '''
    ...
    def test_rooms_from_dictionary(self):
        dict = { '0': [(0,0), (0,1)],
                 '1': [(2,0)],
                 '2': [(4,0), (4,1), (4,2)]}
        ...

The first test converts our little string drawing to a dictionary from a one-character room name—’0’, ‘1’, ‘2’ in the test—to a list of the x y tuples where that character shows up in the picture. The second test test-drove a method on DungeonLayout, add_from_dictionary, which converts that dictionary to rooms containing the indicated cells and adds them to the dungeon.

If we can put those two things together, we’ll be able to draw sample dungeons with simple text pictures that can reside in the code, and then use those dungeons to test things. The first thing we’ll test, I’m supposing, will be the new feature we want, finding a cell that is as far away from a given cell as possible, through the rooms and paths that exist in the dungeon. The longest direct walk possible from the given point, in other words.

The string to dictionary code currently lives only in the test and we need to decide how to make it reusable. Let’s take a look at the whole test now:

    def test_string_layout(self):
        r_0 = [(2,0), (2, 1), (2,2),
               (3,2), (4,2)]
        r_1 = [(0,4)]
        r_2 = [(4, 0)]
        string_map = '''
            ..0.2
            ..0..
            ..000
            .....
            1....
        '''
        string_map = textwrap.dedent(string_map)
        strings = string_map.split('\n')
        strings = [ string for string in strings if string]
        room_cells = dict()
        for y, line in enumerate(strings):
            for x, char in enumerate(line):
                if char != '.':
                    if not char in room_cells:
                        room_cells[char] = []
                    room_cells[char].append((x, y))
        assert len(room_cells) == 3
        assert room_cells['0'] == r_0
        assert room_cells['1'] == r_1
        assert room_cells['2'] == r_2

I don’t think I like that code much, so we’ll see about making it a bit better, and a larger question is where it should reside. I am inclined to think that it should go on DungeonLayout along with the add_from_dictionary method. If we’re going to have the one, we should have the other.

Let’s do that, moving it as it is, via a cut, wishful thinking, and a bit of pastery. You know what? An extract will help us here:

    def test_string_layout(self):
        r_0 = [(2,0), (2, 1), (2,2),
               (3,2), (4,2)]
        r_1 = [(0,4)]
        r_2 = [(4, 0)]
        string_map = '''
            ..0.2
            ..0..
            ..000
            .....
            1....
        '''
        room_cells = self.string_map_to_dictionary(string_map)
        assert len(room_cells) == 3
        assert room_cells['0'] == r_0
        assert room_cells['1'] == r_1
        assert room_cells['2'] == r_2
    def string_map_to_dictionary(self, string_map):
        string_map = textwrap.dedent(string_map)
        strings = string_map.split('\n')
        strings = [string for string in strings if string]
        room_cells = dict()
        for y, line in enumerate(strings):
            for x, char in enumerate(line):
                if char != '.':
                    if not char in room_cells:
                        room_cells[char] = []
                    room_cells[char].append((x, y))
        return room_cells

Now we have a method which could readily reside on DungeonLayout, so let’s do the wishful thinking part, where we write the code in the test that we wish would work:

    layout = DungeonLayout()
    room_cells = layout.string_map_to_dictionary(string_map)

Test goes red. We just have to move that method. PyCharm can’t help, so I do it the old-fashioned cut and paste way:

class DungeonLayout:
    @staticmethod
    def string_map_to_dictionary(string_map):
        string_map = textwrap.dedent(string_map)
        strings = string_map.split('\n')
        strings = [string for string in strings if string]
        room_cells = dict()
        for y, line in enumerate(strings):
            for x, char in enumerate(line):
                if char != '.':
                    if not char in room_cells:
                        room_cells[char] = []
                    room_cells[char].append((x, y))
        return room_cells

Tests are green. Commit: add string_map_to_dictionary to DungeonLayout.

Curiously, having the code over there in DungeonLayout makes me a bit more comfortable with the fact that I don’t like it much and feel it’s probably not robust. At least it’s in the right place, where we can find it and fix it when we want to, or when we find trouble.

Now we need one more method on DungeonLayout, the one that takes a string map and adds the corresponding rooms, using these two new methods. We can gin that up from our existing tests. I think we’ll leave the two we have and create a new one, since the two test the individual methods nicely.

    def test_add_rooms_from_map(self):
        r_0 = [(2,0), (2, 1), (2,2),
               (3,2), (4,2)]
        r_1 = [(0,4)]
        r_2 = [(4, 0)]
        string_map = '''
            ..0.2
            ..0..
            ..000
            .....
            1....
        '''
        layout = DungeonLayout()
        layout.add_rooms_from_map(string_map)
        room_2_cells = layout.cells_in_room('2')
        tuples_2 = [c.xy for c in room_2_cells]
        assert (4,0) in tuples_2
        assert (4,1) in tuples_2
        assert (4,2) in tuples_2
        room_1_cells = layout.cells_in_room('1')
        tuples_1 = [c.xy for c in room_1_cells]
        assert (2,0) in tuples_1

This takes the top from the first test and the bottom from the second, and assumes the method add_rooms_from_map, which doesn’t exist yet. It should be easy:

    def add_rooms_from_map(self, string_map):
        d = self.string_map_to_dictionary(string_map)
        self.add_from_dictionary(d)

I am somewhat surprised to find that that doesn’t work. Why not?

test_paths.py:137 (TestPaths.test_add_rooms_from_map)
(4, 1) != [(4, 0)]
Expected :[(4, 0)]
Actual   :(4, 1)

Silly me, I gave it the wrong answer. Improve the test:

    def test_add_rooms_from_map(self):
        r_0 = {(2,0), (2, 1), (2,2),
               (3,2), (4,2)}
        r_1 = {(0,4)}
        r_2 = {(4, 0)}
        string_map = '''
            ..0.2
            ..0..
            ..000
            .....
            1....
        '''
        layout = DungeonLayout()
        layout.add_rooms_from_map(string_map)
        room_0_cells = layout.cells_in_room('0')
        tuples_2 = [c.xy for c in room_0_cells]
        assert set(tuples_2) == r_0
        room_1_cells = layout.cells_in_room('1')
        tuples_1 = [c.xy for c in room_1_cells]
        assert set(tuples_1) == r_1
        room_0_cells = layout.cells_in_room('0')
        tuples_0 = [c.xy for c in room_0_cells]
        assert set(tuples_0) == r_0

Now we’re checking each of the rooms and they are correct. Test green the feature works. Commit: add_rooms_from_map

I want to see this in the visible map, so I’ll hack main briefly, and we get this:

That’s just right. We even put Dot in one of the rooms. We’ll call it a morning after these few lines of code, and take a well-deserved break.

In all seriousness

I would generally recommend that even when working for a living, one might take a little break, stretch one’s legs, check out the coffee room, pet the cat, after reaching a milestone or inch-pebble like this one. Kind of bring things back to a pause before starting the next effort. And, if you’re as lucky as I am, you have a few hundred lines of text and some code to talk about, so it is time for a well-deserved iced chai or beverage of your choice.

Summary

Yesterday we had the desire to turn a text picture into rooms, and we had a test that did part of the job longhand in the test, and a test that had driven the other half of the job over to DungeonLayout. Today, we just moved the longhand code over to the Layout class, and then test-drove a simple method that called the two chunks to get what we wanted.

I can imagine having done the whole thing in one big messy test and one big messy method and then, perhaps, refactoring. But as I wrote yesterday’s first test, it became clear that going all the way from string to tuples to cells to rooms was too big a jump for my feeble brain, so I stopped with the tuples and then processed the tuples.

I kind of have the feeling that working from the tuples may come in handy in the future, since we have a lot of tests that talk about Cell.at this and Cell.at that. Even if not, it is a sensible breakdown of the job of converting the map to rooms, and I expect the map to come in handy quite soon.

I’m not fond of the method names, as they are long and mention “data types”, which is a bit naff, so we may find ourselves coming up with better names as we go forward.

The whole process today would have gone perfectly had I not whiffed the test, plugging in a wrong answer. The code was correct and the test was quite wrong. That should tell me something. Probably that the tests are still too hard to write, and that I was probably trying to go too fast and wasn’t paying attention. Anyway it was just a momentary bump in the road.

We didn’t do as many commits as I’d like to have seen, only a couple yesterday and a couple today. There were probably some save points in there where I could have notched a commit in, but since we didn’t ever need to back up, I got away with it. It’s not a great way to bet, since even with very small steps, sometimes I do have to back up and a long revert is always a pain. So notching every bit of progress with a commit seems to be the best way for me.

Anyway, a nice new feature for our “making app” and we’ll start using it next time as we work on the furthest point idea. See you then!

Sometimes we focus on the application, sometimes on the making of the application. We begin with making.

My brother Hill refers to the “App” and the “Making App”, that is, the code that is actually part of the application, vs the code that is part of making the application. Today I have a feature in mind, which drives me to improve my tool set.

The feature that I want is the ability to find a cell in the map which is maximally distant from a given cell, by Manhattan measurement. We might extend this to finding a cell which is at least some given distance, but the current plan is to find a maximally distant call.

I have a tentative plan for this, which will involve using our expanding cell search to collect some distance information along the paths searched, details to be figured out soon.

Clearly we’ll want to test-drive this, as it is somewhat tricky and anyway that is the style in which we prefer to work. That leads to a need for some improvement to how we build tests.

Yesterday I drew this little map, to test the ensure_connection:

..0.2
..0..
..000
.....
1....

It took me three or four tries to correctly convert that picture to the correct cell coordinates to create the rooms. I kept mixing up x and y, and probably made other random errors. Even when we do get it right, reading the test doesn’t tell us what the map looks like:

    def test_connected(self):
        layout = DungeonLayout()
        Cell.create_space(5, 5)
        r_0 = Room([Cell.at(2,0), Cell.at(2, 1), Cell.at(2,2),
               Cell.at(3,2), Cell.at(4,2)])
        layout.add_room(r_0)
        layout.add_room(Room([Cell.at(0,4)]))
        layout.add_room(Room([Cell.at(4, 0)]))
        suites = layout.define_suites()
        assert not layout.is_fully_connected
        layout.ensure_connected()

So, to improve our ability to build little maps for testing, I propose to build the ability to turn a multi-line string like the one above into a DungeonLayout. I assume that Python has multi-line strings and some way to take them apart.

Let’s write a test, using the layouts above.

Note

Another inspection showed me that the code for test_connected was a valid test but did not reflect the drawing. I corrected the lines above and I’m pretty sure I got it right this time.

After some fiddling, I have this longhand test, producing collections of x,y tuples:

    def test_string_layout(self):
        r_0 = [(2,0), (2, 1), (2,2),
               (3,2), (4,2)]
        r_1 = [(0,4)]
        r_2 = [(4, 0)]
        string_map = '''
            ..0.2
            ..0..
            ..000
            .....
            1....
        '''
        string_map = textwrap.dedent(string_map)
        strings = string_map.split('\n')
        strings = [ string for string in strings if string]
        room_cells = dict()
        for y, line in enumerate(strings):
            for x, char in enumerate(line):
                if not char in room_cells:
                    room_cells[char] = []
                room_cells[char].append((x, y))
        assert room_cells['0'] == r_0
        assert room_cells['1'] == r_1
        assert room_cells['2'] == r_2

Note

In writing what follows, I realize that the room_cells dictionary includes too much. We’ll fix that but let me explain what we almost have so far.

The rigmarole with the text dedent removes any equal indentation, the split gives us lines of text, and the list comprehension removes any empty lines. There will be one at the beginning.

Then, what I was trying to do was go through and record the x,y locations of any non-dot cells, but I forgot to skip the dot.

        string_map = textwrap.dedent(string_map)
        strings = string_map.split('\n')
        strings = [ string for string in strings if string]
        room_cells = dict()
        for y, line in enumerate(strings):
            for x, char in enumerate(line):
                if char not in ['.']:
                    if not char in room_cells:
                        room_cells[char] = []
                    room_cells[char].append((x, y))
        assert len(room_cells) == 3
        assert room_cells['0'] == r_0
        assert room_cells['1'] == r_1
        assert room_cells['2'] == r_2

The test fails 4 != 3 without the new if. I used in because I think we might allow other than .. That’s premature. generalization Change it:

    for y, line in enumerate(strings):
        for x, char in enumerate(line):
            if char != '.':
                if not char in room_cells:
                    room_cells[char] = []
                room_cells[char].append((x, y))

I think that what we need is a method on DungeonLayout to do this job and actually create the Room instances.

And bah: we need a test for that as well. We have no decent way to test a whole layout for correctness. Let’s see what might make sense. We have code here that makes a dictionary of tuples, given a specialized string. That has no reason to live anywhere, really.

We do have the class RoomMaker, which is a sort of eclectic collection of ways to make individual rooms of various shapes, round, diamond, cave, and so on. Whatever we’re trying to do might fit there. Or we might just put something in DungeonLayout to accept a dictionary of x,y tuples and make rooms from it.

The hole is getting deeper but I think we might be nearing the bottom. Let’s try a test for add_from_dictionary.

This seems close, and enough to drive out the method and find out what’s wrong with this idea:

    def test_rooms_from_dictionary(self):
        dict = { '0': [(0,0), (0,1)],
                 '1': [(2,0)],
                 '2': [(4,0), (4,1), (4,2)]}
        Cell.create_space(5, 5)
        layout = DungeonLayout()
        layout.add_from_dictionary(dict)
        room_2 = [room for room in layout.rooms if room.name == '2'][0]
        cells = [c.xy for c in room_2.cells]
        assert (4,0) in cells

We code this:

DungeonLayout:
    def add_from_dictionary(self, name_to_xy):
        for name, tuples in name_to_xy.items():
            cells = [ Cell.at(x,y) for x,y in tuples ]
            self.add_room(Room(cells, name))

And the test is green. Let’s continue making the test a bit more robust:

    def test_rooms_from_dictionary(self):
        dict = { '0': [(0,0), (0,1)],
                 '1': [(2,0)],
                 '2': [(4,0), (4,1), (4,2)]}
        Cell.create_space(5, 5)
        layout = DungeonLayout()
        layout.add_from_dictionary(dict)
        room_2 = [room for room in layout.rooms if room.name == '2'][0]
        cells_2 = [c.xy for c in room_2.cells]
        assert (4,0) in cells_2
        assert (4,1) in cells_2
        assert (4,2) in cells_2
        room_1 = [room for room in layout.rooms if room.name == '1'][0]
        cells_1 = [c.xy for c in room_1.cells]
        assert (2,0) in cells_1

Green. Commit: working on layout from strings.

I think that the room comprehension above could be a method on layout. Change the test to demand it: “wishful thinking”.

    def test_rooms_from_dictionary(self):
        dict = { '0': [(0,0), (0,1)],
                 '1': [(2,0)],
                 '2': [(4,0), (4,1), (4,2)]}
        Cell.create_space(5, 5)
        layout = DungeonLayout()
        layout.add_from_dictionary(dict)
        room_2_cells = layout.cells_in_room('2')
        tuples_2 = [c.xy for c in room_2_cells]
        assert (4,0) in tuples_2
        assert (4,1) in tuples_2
        assert (4,2) in tuples_2
        room_1_cells = layout.cells_in_room('1')
        tuples_1 = [c.xy for c in room_1_cells]
        assert (2,0) in tuples_1

And:

DungeonLayout:
    def cells_in_room(self, room_name):
        room = next((room for room in self.rooms if room.name == room_name), None)
        if room:
            return room.cells
        else:
            return []

Green. Commit: adding cells_in_room(name) and add_from_dictionary

I need a break. Let’s sum up and continue later.

Summary

We’re still improving the “making app”. We have two useful new methods on DungeonLayout, add_from_dictionary and cells_in_room(name), both of which are only used in tests. I have a feeling that both those methods will turn out to be useful in production, but even if not, they’re useful already in that they make it easier to write tests and check results. If we were tight on memory, very unlikely these days, we might add a test-only subclass of DungeonLayout to hold them or something like that, but really there is no need for anything that fancy.

Looking forward, I think we will find a place, probably Layout, for our code that converts a string map to rooms, and of course we’ll test that into existence. Then, we can turn our attention to the feature we want, which will be tested by creating a layout that we understand and finding a point of maximal distance from a given point.

So far, it’s going well. There are distractions here at home, so for now, I’m calling a break.

See you next time!

I think ensure_connected can fail. Let’s prove it, then fix it.

I need an afternoon distraction, so we’ll try some more code improvement. We’ll start with the path-making code we find lying about.

class DungeonLayout:
    def ensure_connected(self):
        if self.is_fully_connected:
            return
        room = self._straight_path_room()
        self.add_room(room)
    def _straight_path_room(self):
        cells = self._straight_path_cells()
        if cells:
            return Room(cells, 'path')
        else:
            return None
    def _straight_path_cells(self):
        cells = []
        suites = self.define_suites()
        for s1, s2 in zip(suites, suites[1:]):
            cells.extend(s1.find_path_cells(s2))
        return list(set(cells))

This code gets a list of all current suites—each suite being a collection of rooms that are directly adjacent—and then creates a path between each pair or suites 0->1, 1->2, and so on, collecting all the cells of all those paths into one room, which it adds to the layout.

I suspect that this code can fail to connect the dungeon as it stands, if the rooms are arranged poorly enough. Let’s try to write a test for that.

    def test_connected(self):
        layout = DungeonLayout()
        Cell.create_space(5, 5)
        r_0 = Room([Cell.at(2,0), Cell.at(2, 1), Cell.at(2,2),
               Cell.at(3,2), Cell.at(4,2)])
        layout.add_room(r_0)
        layout.add_room(Room([Cell.at(4,4)]))
        layout.add_room(Room([Cell.at(4, 0)]))
        assert not layout.is_fully_connected
        layout.ensure_connected()
        assert layout.is_fully_connected

The map looks like this, if I’m not mistaken:

..0.2
..0..
..000
.....
1....

So our current code will connect 0->1 but then be unable to connect 1->2, leaving two suites, (0,1) and (2).

I expect the test to fail, after three or four attempts to transcribe my picture to coordinates by hand. Now I think that if we loop in ensure_connected we should pass.

    def ensure_connected(self):
        while not self.is_fully_connected:
            room = self._straight_path_room()
            self.add_room(room)

Test passes. Commit: test and fix ensure_connected.

We’ll call that done.

Summary

Hard to know what to call that. I thought there was a defect, showed the defect, fixed it. It has been in there for a while, and I’m not sure but I’ve probably mentioned before that it seemed iffy.

Anyway, one more step forward. See you next time!

Having completed the basics of the contents vs layout design, it’s time to look around and see what needs improvement.

If I were willing to work when tired, or when an article exceeds 500 multi-line lines, we might have done more tidying yesterday, but that is not my way. With a day or two behind us, we probably do a better job of recognizing bumps and dips in the code that would elude us right after a big chunk of coding or refactoring.

I see something already, on the PyCharm tab that is open right in front of me:

class Dungeon:
    def populate(self):
        dot_room = random.choice(self.rooms)
        dot_cell = random.choice(dot_room.cells)
        self.adventurer_cell = dot_cell
    def place_adventurer_at(self, cell):
        self.adventurer_cell = cell

Somewhere in my past there is the idea that the populate should call the place, rather than do the member assignment directly. Doing so:

    def populate(self):
        dot_room = random.choice(self.rooms)
        dot_cell = random.choice(dot_room.cells)
        self.place_adventurer_at(dot_cell)
    def place_adventurer_at(self, cell):
        self.adventurer_cell = cell

That removes the duplication, and helps us ensure that if we ever need to change how placing the adventurer works, there will be one place and only one place to change. I’m not saying that I have reasoned to this practice, and I certainly haven’t proven that it’s better: it’s just built into how I work.

There are other direct references. I’ll fix all four. Here’s one:

    def move_adventurer_north(self):
        self.place_adventurer_at(self.adventurer_cell.north())

I notice the names dot_room etc. The adventurer is jokingly called Dot in these articles, because she displays as a big dot on the screen. But a programmer discovering those names will be just a bit disrupted by those names.

While we’re thinking about the names, I propose that we rename ‘adventurer’ to ‘player’, which is a bit more common and easier to type, a win-win. Things look like this now:

class Dungeon:
    def __init__(self, layout):
        self.layout = layout
        self.player_cell = None
    @property
    def rooms(self):
        return self.layout.rooms
    def populate(self):
        dot_room = random.choice(self.rooms)
        dot_cell = random.choice(dot_room.cells)
        self.place_player_at(dot_cell)
    def place_player_at(self, cell):
        self.player_cell = cell
    def move_adventurer_north(self):
        self.place_player_at(self.player_cell.north())
    ...

Green. Commit: tidying.

We should take a look at DungeonLayout, our new / old class. Immediately we notice that this class seems rather large. We just scan it to make that assessment, before even trying to understand it.

class DungeonLayout:
    def __init__(self):
        self.rooms = []
        self.suite_sets = []
    def __iter__(self):
        return iter(self.rooms)
    @property
    def is_fully_connected(self):
        suite = self.find_suite(self.rooms[0])
        return len(suite) == len(self.rooms)
    def ensure_connected(self):
        if self.is_fully_connected:
            return
        room = self._straight_path_room()
        self.add_room(room)
    @property
    def number_of_rooms(self):
        return len(self.rooms)
    def add_room(self, room):
        self.rooms.append(room)
    def remove_room(self, room):
        room.return_cells()
        self.rooms.remove(room)
    def define_suites(self):
        return [Suite(s) for s in self.define_suite_sets()]
    def define_suite_sets(self):
        self.suite_sets = []
        unexplored = self.rooms.copy()
        while unexplored:
            suite = self.find_suite(unexplored[0])
            self.suite_sets.append(suite)
            unexplored = [room for room in unexplored if room not in suite]
        return self.suite_sets
    def add_path_room(self):
        room = self._straight_path_room()
        if room:
            self.add_room(room)
    def _straight_path_room(self):
        cells = self._straight_path_cells()
        if cells:
            return Room(cells, 'path')
        else:
            return None
    def _straight_path_cells(self):
        cells = []
        suites = self.define_suites()
        for s1, s2 in zip(suites, suites[1:]):
            cells.extend(s1.find_path_cells(s2))
        return list(set(cells))
    @staticmethod
    def find_suite(room):
        suite = set()
        start = room.cells[0]
        for cell in start.generate(lambda c: c.is_in_a_room):
            suite.add(cell.room)
        return suite

Do we ever use the suite_sets member? We do, but oddly:

    def define_suite_sets(self):
        self.suite_sets = []
        unexplored = self.rooms.copy()
        while unexplored:
            suite = self.find_suite(unexplored[0])
            self.suite_sets.append(suite)
            unexplored = [room for room in unexplored if room not in suite]
        return self.suite_sets

I think that if we used a temp in that method everything would continue to work and we wouldn’t need the instance variable any more.

    def define_suite_sets(self):
        suite_sets = []
        unexplored = self.rooms.copy()
        while unexplored:
            suite = self.find_suite(unexplored[0])
            suite_sets.append(suite)
            unexplored = [room for room in unexplored if room not in suite]
        return suite_sets

Green, and main works. Remove the member. Commit.

I notice add_path_room, which has no usages. Remove it. Commit.

Did you notice?

After taking a look at the whole class, I didn’t begin by planning out how to refactor it overall. Instead, I looked for opportunities to make small changes, especially small deletions. After those low-hanging fruit are dealt with, we’ll look for larger changes. When we do that, the problem we face will be smaller and thus easier to resolve.

My next move is going to be to put methods that call each other closer to each other. Things seem a bit random here. First this case:

    def define_suite_sets(self):
        suite_sets = []
        unexplored = self.rooms.copy()
        while unexplored:
            suite = self.find_suite(unexplored[0])
            suite_sets.append(suite)
            unexplored = [room for room in unexplored if room not in suite]
        return suite_sets
    @staticmethod
    def find_suite(room):
        suite = set()
        start = room.cells[0]
        for cell in start.generate(lambda c: c.is_in_a_room):
            suite.add(cell.room)
        return suite

In the second method there, suite is a set of cells, not a Suite. (What is a Suite, anyway? I think we need to look at that.) Here, we rename …

No, I’m mistaken. suite is a set of Rooms. I do a bit of renaming and type hinting:

    def define_suites(self):
        return [Suite(s) for s in self.define_suite_sets()]
    def define_suite_sets(self):
        suites: list[set[Room]] = []
        unexplored = self.rooms.copy()
        while unexplored:
            suite_rooms: set[Room] = self.find_suite(unexplored[0])
            suites.append(suite_rooms)
            unexplored = [room for room in unexplored if room not in suite_rooms]
        return suites
    @staticmethod
    def find_suite(room) ->set[Room]:
        suite_rooms: set[Room] = set()
        start = room.cells[0]
        for cell in start.generate(lambda c: c.is_in_a_room):
            suite_rooms.add(cell.room)
        return suite_rooms

I remain curious about what a Suite is and what it does. This may all be somewhat moot. But why aren’t we returning a Suite from the bottom method here instead of that last conversion at the top?

I think this code may be a case of backing away slowly. Ah, no, that’s not quite it: there is a test for define_suite_sets and one for find_suite. First this one:

    def test_make_suite_lists(self):
        \
        #massive setup skipped here

        suite_sets = dungeon.define_suite_sets()
        assert len(suite_sets) == 3
        assert {r_0, r_1, r_3} in suite_sets
        assert {r_2} in suite_sets
        assert {r_4, r_5} in suite_sets
        suites = dungeon.define_suites()
        assert len(suites) == 3

We can change this not to use define_suite_sets by checking the suites after define_suites. It’s just a bit harder, because we can’t be sure what order they’re in. But that order won’t change so once we get the test right it should keep running.

        suites = dungeon.define_suites()
        assert len(suites) == 3
        assert suites[0].room_set == {r_0, r_1, r_3}
        assert suites[1].room_set == {r_2}
        assert suites[2].room_set == {r_4, r_5}

Green. Commit: refactoring tests in prep for object refactoring.

Now who’s calling find_suite? Ah, that’s used twice inside DungeonLayout:

    @property
    def is_fully_connected(self):
        suite = self.find_suite(self.rooms[0])
        return len(suite) == len(self.rooms)
    def define_suite_sets(self):
        suites: list[set[Room]] = []
        unexplored = self.rooms.copy()
        while unexplored:
            suite_rooms: set[Room] = self.find_suite(unexplored[0])
            suites.append(suite_rooms)
            unexplored = [room for room in unexplored if room not in suite_rooms]
        return suites

I think that if we actually start returning suites from find_suite, is_fully_connected may fail for want of len on Suite. Is there a test for that? Yes, there is. So we can proceed.

Looking at this sequence:

    def define_suites(self):
        return [Suite(s) for s in self.define_suite_sets()]
    def define_suite_sets(self):
        suites: list[set[Room]] = []
        unexplored = self.rooms.copy()
        while unexplored:
            suite_rooms: set[Room] = self.find_suite(unexplored[0])
            suites.append(suite_rooms)
            unexplored = [room for room in unexplored if room not in suite_rooms]
        return suites
    @staticmethod
    def find_suite(room) ->set[Room]:
        suite_rooms: set[Room] = set()
        start = room.cells[0]
        for cell in start.generate(lambda c: c.is_in_a_room):
            suite_rooms.add(cell.room)
        return suite_rooms

My plan is to return a Suite directly from find_suite. Makes sense, right? Then we won’t need to do it in define_suites and I think we rename define_suite_sets to define_suites. Or maybe we can inline. Let’s try that now:

First pull out a variable:

    def define_suites(self):
        sets = self.define_suite_sets()
        return [Suite(s) for s in sets]

We could commit. Now inline method:

    def define_suites(self):
        suites: list[set[Room]] = []
        unexplored = self.rooms.copy()
        while unexplored:
            suite_rooms: set[Room] = self.find_suite(unexplored[0])
            suites.append(suite_rooms)
            unexplored = [room for room in unexplored if room not in suite_rooms]
        sets = suites
        return [Suite(s) for s in sets]
    @staticmethod
    def find_suite(room) ->set[Room]:
        suite_rooms: set[Room] = set()
        start = room.cells[0]
        for cell in start.generate(lambda c: c.is_in_a_room):
            suite_rooms.add(cell.room)
        return suite_rooms

Now return a Suite from find_suite and clean up the hints. This will break a test for a moment.

    def define_suites(self):
        suites: list[Suite] = []
        unexplored = self.rooms.copy()
        while unexplored:
            suite: Suite = self.find_suite(unexplored[0])
            suites.append(suite)
            unexplored = [room for room in unexplored if room not in suite]
        return suites
    @staticmethod
    def find_suite(room) -> Suite:
        suite_rooms: set[Room] = set()
        start = room.cells[0]
        for cell in start.generate(lambda c: c.is_in_a_room):
            suite_rooms.add(cell.room)
        return Suite(suite_rooms)

Six tests break. I should have committed a save point. Quick look at the tests to see if we can fix things quickly. Ah, we’re in luck:

>           unexplored = [room for room in unexplored if room not in suite]
                                                         ^^^^^^^^^^^^^^^^^
E           TypeError: argument of type 'Suite' is not iterable

We can just fetch the rooms, or make it iterable. I think the former is more conservative.

    def define_suites(self):
        suites: list[Suite] = []
        unexplored = self.rooms.copy()
        while unexplored:
            suite: Suite = self.find_suite(unexplored[0])
            suites.append(suite)
            unexplored = [room for room in unexplored if room not in suite.room_set]
        return suites

Now we still have one test failing. It’s the one I expected:

>       return len(suite) == len(self.rooms)
               ^^^^^^^^^^
E       TypeError: object of type 'Suite' has no len()

    @property
    def is_fully_connected(self):
        suite = self.find_suite(self.rooms[0])
        return len(suite.room_set) == len(self.rooms)

That check is kind of indirect: we are fully connected if the suite containing our first room has the same length as the number of rooms in the layout. Better checks might be:

1. Is there only one Suite in define_suites?
2. Does the Suite containing room one contain all the rooms?

Let’s use scheme 1 here.

    @property
    def is_fully_connected(self):
        suites = self.define_suites()
        return len(suites) == 1

Yikes, I haven’t been committing. Commit: refactor define_suites, plus tidying.

The remaining “big” thing here is this:

    def ensure_connected(self):
        if self.is_fully_connected:
            return
        room = self._straight_path_room()
        self.add_room(room)
    def _straight_path_room(self):
        cells = self._straight_path_cells()
        if cells:
            return Room(cells, 'path')
        else:
            return None
    def _straight_path_cells(self):
        cells = []
        suites = self.define_suites()
        for s1, s2 in zip(suites, suites[1:]):
            cells.extend(s1.find_path_cells(s2))
        return list(set(cells))

We’ll let that one ride for this morning, as we are approaching the limit of our article size, our patience, and various other personal limits. I want to call out Suite, in relation to the above, since it goes like this:

class Suite:
    def __init__(self, room_set):
        self.room_set = room_set
    @property
    def cells(self):
        for room in self.room_set:
            for cell in room.cells:
                yield cell
    def find_path_cells(self, suite) -> list[Cell]:
        source, target = self.find_closest_pair(suite)
        cells = source.find_path(target, [source.room, target.room])
        on_path = cells[1:-1]
        return on_path
    def find_closest_pair(self, suite):
        my_best = None
        his_best = None
        distance = 1_000_000
        for mine in self.cells:
            for his in suite.cells:
                dist = mine.manhattan_distance(his)
                if dist < distance:
                    my_best = mine
                    his_best = his
                    distance = dist
        return [my_best, his_best]

There’s something funky going on here, with find_path and find_path_cells in Cell, plus some path-finding in Suite and some in DungeonLayout. I suspect that we may be able to find a better division of labor here, ideally something like Layout to Suite to Room to Cell, or perhaps direct from Suite to Cell, with no path-related stuff in Room at all.

All that is for another day.

Summary

It is no surprise that we found things to improve, after having moved Dungeon and DungeonLayout into place. Some of that was debris left over from our various experiments with ensuring dungeons are connected: remember that we have that interesting trick of tossing in random rooms with high wandering coefficients until everything connects. Clearly that needs to be better integrated. Some kind of path-making scheme with strategies or a selection of approaches or something.

We proceeded without a grand plan, even though the situation might well have seemed like we should have one. Instead, we kind of chip away everything that doesn’t look quite right and almost magically a better-organized set of classes emerges.

One good example of that was pushing the creation of the Suite down to the bottom of the method sequence, to the first method that had the collection needed to create a Suite, instead of collecting the collections and then Suiterizing them. That did require us to refactor a test, but it made the test both shorter and more safe.

The test got the way it was because when we originally built the Suite idea, I didn’t see clearly how to do it, so created a set of rooms first, which is necessary, but I tested that bit, which kind of nailed it in place. We had to undo that test to release the code to be what it really wanted to be.

I missed at least one possible commit, and it nearly bit me when six tests broke, but the fix turned out to be easy. (In fact, I think that PyCharn had highlighted the troublesome line, but I didn’t notice.) But committing Every Single Time we’re green is a good idea, at least here at my place.

So we have made a noticeable improvement to tests and to our Layout, Dungeon, and Suite classes. Very useful 90 minutes, including writing the article.

See you next time!

The FGNO OGs¹] gave me some good ideas about my design: thanks, OGs. This morning I’ll start following some of those ideas. I use test doubles!

Every Tuesday evening for the past few years, has been FGNO, Friday Geeks Night Out² via Zoom. Last night I asked for some feedback about the design of the dungeon program. OG A challenged me to do a refactoring that I mentioned was probably desirable. Did that, with far more typing errors than I ever seem to have when alone. Worked well. OG B helped with some pygame issues. I suggested that Dungeon should be split into the stable bits, and a DungeonContents new class instance containing the variable parts. Actually made that work.

I think it was OG H who suggested that the view side should do things like the decoding of key strokes, and send messages to the dungeon that make semantic sense to dungeon behavior. We didn’t try that, but it has made it to my list of things to do.

Then OG H, on a bit of a roll, allowed as how he’d do the contents/layout design with the dynamic part of the dungeon holding on to the more static part rather than the way I proposed with the top object holding both static and dynamic contents. We talked about that and I think that I probably agree, so this morning we’re going to work on that.

Let’s get started. Here’s the top of Dungeon now:

class Dungeon:
    def __init__(self):
        self.adventurer_cell = None
        self.key_lock = None
        # layout starts here
        self.rooms = []
        self.suite_sets = []

The arrangement of members and the comment are from FGNO. The last two instance variables are unchanging after the rooms are created. One name that we came up with for the new class was DungeonLayout, thus the comment.

Our target design here is to have a new class, DungeonLayout, that contains the rooms and suites. The class Dungeon will include the dynamic aspects of the game. (OG B-prime commented that this class would often be called Game.)

We would like to do this refactoring in small steps, with plenty of commits along the way. There are quite a few references to Dungeon: 19, according to PyCharm. Eight of those are in main, and the rest in tests. A quick look tells me that in main, there is only the import, one real reference, and the rest are type hints. The tests all look similar:

    def test_make_suite_lists(self):
        Cell.create_space(10, 10)
        dungeon = Dungeon()
        o_0 = Cell.at(3,1)
        r_0 = RoomMaker().cave(number_of_cells=1, origin=o_0, name='0')
        dungeon.add_room(r_0)
        ...

To a first approximation they’re all creating a Dungeon to put rooms or paths into it. So I think they’ll all want to refer to DungeonLayout when we’re done.

So I suggest the following plan:

1. Rename Dungeon to DungeonLayout. This will change all the references and keep the tests running. Commit that.
2. Then, create a new Dungeon class, via at least one test, and move the populate and such code to it. Maybe write a test for that.
3. Waving hands: deal with DungeonView and its use in main.

I’m pretty sure about that first step, and think that the second is probably the right next thing to do, but we’ll look a bit more deeply at the code before we pick the next move. I’m sure this first one is proper, as it will fix up most of the wiring with a machine refactoring.

Here goes: one rename command. PyCharm even offers to rename the file. Green. Commit: rename Dungeon to DungeonLayout.

OK. At this point everything works, including main. We will work mostly driven by main and see what we find. main looks like this:

def main():
    Cell.create_space(64, 56)
    # random.seed(234)
    layout = DungeonLayout()
    maker = RoomMaker()
    make_diamond_in_round_room(layout, maker)
    make_a_diamond_room(layout, maker)
    make_a_round_room(layout, maker)
    number_of_rooms = random.randint(8, 8)
    for _ in range(number_of_rooms):
        make_a_cave_room(layout, maker)
        make_experimental_room(layout, maker)
    layout.ensure_connected()
    layout.populate()
    view = DungeonView(layout)
    view.main_loop()

That’s nearly good but it should end like this:

    dungeon = Dungeon(layout)
    dungeon.populate()
    view = DungeonView(dungeon)
    view.main_loop()

Ideally, that would be all we need to do in main, at least for now. We could argue that we shouldn’t have to ensure connected explicitly, and that perhaps the Dungeon should auto-populate. But perhaps not: there are probably all kinds of options to be specified. Anyway, given our current code, that’s about as good as it could get.

Let’s create a test that works somewhat like main, to drive out some changes.

class TestDungeon:
    def test_exists(self):
        Cell.create_space(10, 10)
        room_cell = Cell.at(5, 5)
        room = Room([room_cell])
        layout = DungeonLayout()
        layout.add_room(room)
        dungeon = Dungeon(layout)

That’s a lot of wiring but I wanted a legitimate layout. This won’t compile or run because there is no Dungeon class. As is my common practice, I’ll begin by putting it in DungeonLayout’s file.

class Dungeon:
    def __init__(self, layout):
        self.layout = layout

Green. We can commit.

Let’s write a new test for populate and see what we can do.

    def test_populate(self):
        Cell.create_space(10, 10)
        room_cell = Cell.at(5, 5)
        room = Room([room_cell])
        layout = DungeonLayout()
        layout.add_room(room)
        dungeon = Dungeon(layout)
        dungeon.populate()
        assert dungeon.adventurer_cell is None
        assert dungeon.key_lock is None

These are the current population members in DungeonLayout, so presumably theyu’ll be moved to Dungeon … right now:

class Dungeon:
    def __init__(self, layout):
        self.layout = layout
        self.adventurer_cell = None
        self.key_lock = None
    def populate(self):
        dot_room = random.choice(self.layout.rooms)
        dot_cell = random.choice(dot_room.cells)
        self.adventurer_cell = dot_cell

I expected that to work. It did not. The test is wrong:

...
        dungeon.populate()
        assert dungeon.adventurer_cell is room_cell
        assert dungeon.key_lock is None

Green. Commit: implementing Dungeon class.

Breathe. Reflect. Think.

Right. We need to make DungeonView work, for main to work. Most of what needs fixing is here:

class DungeonView:
    def main_loop(self):
        running = True
        moving = False
        background = "gray33"
        color = "darkblue"
        while running:
            for event in pygame.event.get():
                if event.type == pygame.QUIT:
                    running = False
                elif event.type == pygame.KEYDOWN:
                    self.dungeon.handle_keydown(event)
                elif event.type == pygame.KEYUP:
                    self.dungeon.handle_keyup(event)
            self.screen.fill(background)
            # self.draw_grid(color)
            self.draw_rooms()
            self.draw_contents()
            self.clock.tick(60)
            pygame.display.flip()
        pygame.quit()
    def draw_rooms(self):
        for room in self.dungeon:
            RoomView(room).draw(self.screen)
    def draw_contents(self):
        adventurer_cell = self.dungeon.adventurer_cell
        cx = adventurer_cell.x*cell_size + cell_size//2
        cy = adventurer_cell.y*cell_size + cell_size//2
        pygame.draw.circle(self.screen, "red", [cx, cy], cell_size//2)

Dungeon does not understand in, and I don’t think we want it to. I do think it could understand rooms. So:

class DungeonView:
    def draw_rooms(self):
        for room in self.dungeon.rooms:
            RoomView(room).draw(self.screen)
class Dungeon:
    def __init__(self, layout):
        self.layout = layout
        self.adventurer_cell = None
        self.key_lock = None
    @property
    def rooms(self):
        return self.layout.rooms
    def populate(self):
        dot_room = random.choice(self.rooms)
        dot_cell = random.choice(dot_room.cells)
        self.adventurer_cell = dot_cell

I didn’t write a test for that. Let’s extend our existing one:

    def test_populate(self):
        Cell.create_space(10, 10)
        room_cell = Cell.at(5, 5)
        room = Room([room_cell])
        layout = DungeonLayout()
        layout.add_room(room)
        dungeon = Dungeon(layout)
        dungeon.populate()
        assert dungeon.adventurer_cell is room_cell
        assert dungeon.key_lock is None
        rooms = dungeon.rooms
        assert len(rooms) == 1
        assert rooms[0].cells[0] is room_cell

A bit grubby but green. Commit: Dungeon provides rooms. (I have not been committing main, but am committing everything else.)

Let’s see what explodes now when we do run main. Good news, the map comes up. Then if I try to move Dot:

~~~line 26, in main_loop self.dungeon.handle_keydown(event) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ AttributeError: ‘Dungeon’ object has no attribute ‘handle_keydown’

## Reflect. Plan.
OG "H" mentioned making the key handlers part of the View and sending semantic messages to the dungeon to do what the keys call for. This is a good time to do that. It'll be a bit more work but not much.
First we'll test in the semantic messages. I start with this to get a known situation:
~~~python
    def test_adventurer_motion(self):
        Cell.create_space(20, 20)
        layout = DungeonLayout()
        c55 = Cell.at(5, 5)
        round = RoomMaker().round(radius=6, origin=c55)
        layout.add_room(round)
        dungeon = Dungeon(layout)
        dungeon.populate()
        dungeon.place_adventurer_at(c55)
        assert dungeon.adventurer_cell is c55

We’ll need a way to set the adventurer location anyway. I will get tired of typing “adventurer” pretty soon.

class Dungeon:
    def place_adventurer_at(self, cell):
        self.adventurer_cell = cell

Green. Commit a save point.

Extend the test:

        dungeon.move_adventurer_north()
        assert dungeon.adventurer_cell is Cell.at(5, 4)

I considered shorter names or passing a string but decided on separate methods at least for now.

    def move_adventurer_north(self):
        self.adventurer_cell = self.adventurer_cell.north()

We already have the directional moves in Cell:

class Cell:
    def east(self):
        return self.attempt_move(1,0)
    def north(self):
        return self.attempt_move(0, -1)
    def south(self):
        return self.attempt_move(0, 1)
    def west(self):
        return self.attempt_move(-1, 0)
    def attempt_move(self, dx, dy):
        cell = self.at_offset(dx, dy)
        if not cell or cell.is_available:
            return self
        return cell

Continue with the other three moves:

        dungeon.move_adventurer_north()
        assert dungeon.adventurer_cell is Cell.at(5, 4)
        dungeon.move_adventurer_east()
        assert dungeon.adventurer_cell is Cell.at(6,4)
        dungeon.move_adventurer_south()
        assert dungeon.adventurer_cell is Cell.at(6, 5)
        dungeon.move_adventurer_west()
        assert dungeon.adventurer_cell is Cell.at(5,5)

And the corresponding methods of course, just like north. I’ll spare you. Commit: Dungeon supports semantic move.

Reflect. Plan.

I think we “just” need to put key handlers somewhere sensible and make them send the new semantic messages. In DungeonView, we have:

class DungeonView:
    elif event.type == pygame.KEYDOWN:
        self.dungeon.handle_keydown(event)
    elif event.type == pygame.KEYUP:
        self.dungeon.handle_keyup(event)

It’s up to the view to decode what the keys mean, so let’s send those messages to self instead of the dungeon, and add a couple of new methods.

Should we write tests for that? Let’s do, because I think I claimed yesterday that I knew how to do it.

class TestHandlers:
    def test_keydown(self):
        assert False

Fails, so it’s hooked up. I pretty much always try that to be sure my setup is correct.

Hm. I guess the view will handle key locking as well. Interesting.

We’ll create a little test dummy to help with this.

Grr. We’ll want a DungeonView that doesn’t start up pygame. So we’ll do a bit of a hack.

class DungeonView:
    def __init__(self, dungeon, testing=False):
        self.dungeon = dungeon
        if testing:
            return
        ...

I needed two fake objects, though I could probably combine them into one:

class FakeDungeon:
    def __init__(self):
        self.received = 'nothing'
    def move_adventurer_north(self):
        self.received = 'north'
    def move_adventurer_south(self):
        self.received = 'south'
    def move_adventurer_east(self):
        self.received = 'east'
    def move_adventurer_west(self):
        self.received = 'west'
class FakeEvent:
    def __init__(self, key):
        self.key = key
class TestHandlers:
    def test_keydown(self):
        fake = FakeDungeon()
        view = DungeonView(fake, testing=True)
        event = FakeEvent(pygame.K_UP)
        view.handle_keydown(event)
        assert fake.received == 'north'
        event = FakeEvent(pygame.K_DOWN)
        view.handle_keydown(event)
        assert fake.received == 'south'
        event = FakeEvent(pygame.K_LEFT)
        view.handle_keydown(event)
        assert fake.received == 'west'
        event = FakeEvent(pygame.K_RIGHT)
        view.handle_keydown(event)
        assert fake.received == 'east'

My test is failing on south. If I comment out everything but south, south works.

Ah. As intended: I”m handling key locking already!

class TestHandlers:
    def test_keydown(self):
        fake = FakeDungeon()
        view = DungeonView(fake, testing=True)
        event = FakeEvent(pygame.K_UP)
        view.handle_keydown(event)
        assert fake.received == 'north'
        view.handle_keyup(event)
        event = FakeEvent(pygame.K_DOWN)
        view.handle_keydown(event)
        assert fake.received == 'south'
        view.handle_keyup(event)
        event = FakeEvent(pygame.K_LEFT)
        view.handle_keydown(event)
        assert fake.received == 'west'
        view.handle_keyup(event)
        event = FakeEvent(pygame.K_RIGHT)
        view.handle_keydown(event)
        assert fake.received == 'east'
        view.handle_keyup(event)

This works, because I moved the full handlers from wherever they were into DungeonView:

class DungeonView:
    def handle_keydown(self, event):
        if self.key_lock:
            return
        self.key_lock = event.key
        if event.key == pygame.K_RIGHT:
            self.dungeon.move_adventurer_east()
        elif event.key == pygame.K_LEFT:
            self.dungeon.move_adventurer_west()
        elif event.key == pygame.K_UP:
            self.dungeon.move_adventurer_north()
        elif event.key == pygame.K_DOWN:
            self.dungeon.move_adventurer_south()
        else:
            self.key_lock = None
    def handle_keyup(self, event):
        if event.key == self.key_lock:
            self.key_lock = None

I think main should work now. Yes, we can move Dot around. Commit including main: DungeonView supports keydown events.

Now I’d like to move Dungeon to its own file, but I have concerns about the imports. We’ll try it since we are at a point where we can revert. Good news, everything works. Commit: Dungeon moved to own file.

Let’s call it a morning, since the article is getting to be book length.

Summary

The trick of renaming Dungeon to DungeonLayout was an important first move here, because most of the functionality wanted to move there. After that, everything proceeded in small steps.

It is quite unusual for me to build a test double, as we did here with the FakeEvent and FakeDungeon, but I just wanted to be sure that DungeonView sent the right messages, and setting up an entire Dungeon seemed excessive. The doubles tell me what I want to know in this case.

I am from the Detroit school of TDD, which generally does not use test doubles, as opposed to the London School, which uses them extensively. The London focus is mostly on whether objects are sending the right messages, while Detroit focuses more on whether, sent a message, an object does what we expect. I have not worked extensively in London style, and I have always wondered how you ever find out that the messages you correctly send are handled correctly. I’m sure it works: people I respect use the approach. I just haven’t worked that way enough to see where it bottoms out.

It seems likely that there are methods now that are unused. I tried to get rid of the ones I was aware of, but it would behoove us to do a scan of the affected classes to see what can be removed.

As for keeping the layout under the dungeon contents, it certainly works so far, for the one content item we have, good ol’ Dot. We’ll see how it goes in the future but at a guess it’ll in fact be better. With the contents under the layout, all the operational calls from view would have to bounce through Dungeon to DungeonContents, or we’d have to rip the contents out and handle them separately. This way, there’s only one bounce in Dungeon, the one that fetches rooms.

I think I’m going to like it. Bit of a hat tip to OG “H”. See you next time!

Today, we’ll start populating our dungeon. We’ll start with an intrepid adventurer named Dot.

Our story begins …

A lone intrepid adventurer named Dot finds herself in a random dungeon. She can move in any of the cardinal directions, except of course that she cannot walk through walls.

We’ll guide Dot by typing on the arrow keys, if things go as I intend. Key down and she moves if she can, then the key must go up before she can move again. At this moment, I don’t know what I think about more than one key down at a time, but I think we’d like to ignore all but the first.

Our own first step this morning will be to review and recall how keyboard events work in PyGame. We’ll be modifying our main loop:

class DungeonView:
    def __init__(self, dungeon):
        self.dungeon = dungeon
        pygame.init()
        pygame.display.set_caption("Dungeon")
        self.screen = pygame.display.set_mode(
            (screen_width, screen_height))
        self.clock = pygame.time.Clock()
    def main_loop(self):
        running = True
        moving = False
        background = "gray33"
        color = "darkblue"
        while running:
            for event in pygame.event.get():
                if event.type == pygame.QUIT:
                    running = False
            self.screen.fill(background)
            self.draw_grid(color)
            self.draw_paths()
            self.draw_rooms()
            self.clock.tick(60)
            pygame.display.flip()
        pygame.quit()

From the look of that, we want to see what other event.type we might encounter. We find that there are events KEYDOWN and KEYUP. The events can return key, mod, unicode and scancode. There are key names: K_UP, K_DOWN, K_RIGHT, and K_LEFT among many others.

With a bit of searching on my own site, I find a little patch of code that tells us what we need to know:

    def main_loop(self):
        running = not self._testing
        while running:
            for event in pygame.event.get():
                if event.type == KEYDOWN:
                    if event.key == K_ESCAPE:
                        running = False
                elif event.type == QUIT:
                    running = False
        ...

Let’s do just a bit of design thinking here, to get a sense of what we will want in the future, and what we might want to do as our first few steps into the future.

I think that the Dungeon will be the main state-bearing object during game play, at least for now: it knows where all the rooms are. So it will also know where all the stuff is, including Intrepid Adventurer Dot. However, for some reason having to do with a tendency to over-design, or perhaps to follow some good advice I heard somewhere, I’ve already committed to there being “view” objects, specifically DungeonView and RoomView. We’ll have to work with those.

I can think of at least two ways to have it work: we could draw all the paths and rooms and then draw all the contents, including Dot, on top of that. Or we could draw each room or path and at that time, its contents.

I think for now, we’ll just have Dot know her coordinates in the dungeon, so we’ll take the approach of drawing contents last. And we’ll code something directly into the DungeonView, for now.

First step, let’s put Dot somewhere and make her display.

At the end of main, right before we enter the game loop, we’ll “populate” the dungeon. This will, I guess, be the process of placing all the goodies, including Dot. For now, only Dot.

main.py
...
    path_room = Room(path, 'path')
    dungeon.add_room(path_room)
    dungeon.populate()
    view = DungeonView(dungeon)
    view.main_loop()

Need to write that:

class Dungeon:
    def populate(self):
        dot_room = random.choice(self.rooms)
        dot_cell = random.choice(dot_room.cells)
        self.adventurer_cell = dot_cell

Random cell in a random room. Now we need to display something. In DungeonView.

class DungeonView:
            self.draw_paths()
            self.draw_rooms()
            self.draw_contents()
            self.clock.tick(60)
            pygame.display.flip()
        pygame.quit()
    def draw_contents(self):
        adventurer_cell = self.dungeon.adventurer_cell
        cx = adventurer_cell.x*cell_size + cell_size//2
        cy = adventurer_cell.y*cell_size + cell_size//2
        pygame.draw.circle(self.screen, "red", [cx, cy], cell_size//2)

This isn’t as arcane as it may look, since we use a similar pair of expressions to calculate cell positions. Here we offset by half the size to get the center and draw a red circle of radius half the cell size. And we get this in our current excessively simple dungeon:

That’s pretty much exactly what we wanted. Let’s commit a save point.

We’ll divert to create a more interesting dungeon, since this setup was just there to show how our wiggly path logic looks. I’ll spare you the bandwidth of the picture, but that’s done, let’s do the moving code:

For now, let’s just send the key to the dungeon with a handle_key_up or handle_key_down method. We’ll sort things out once they’re wired up.

while running:
    for event in pygame.event.get():
        if event.type == pygame.QUIT:
            running = False
        elif event.type == pygame.KEYDOWN:
            self.dungeon.handle_keydown(event)
        elif event.type == pygame.KEYUP:
            self.dungeon.handle_keyup(event)

Then:

class Dungeon:
    def handle_keydown(self, event):
        key = event.key
        if key == pygame.K_RIGHT:
            self.adventurer_cell = self.adventurer_cell.east()
        elif key == pygame.K_LEFT:
            self.adventurer_cell = self.adventurer_cell.west()
        elif key == pygame.K_UP:
            self.adventurer_cell = self.adventurer_cell.north()
        elif key == pygame.K_DOWN:
            self.adventurer_cell = self.adventurer_cell.south()

And:

    def east(self):
        return self.attempt_move(1,0)
    def north(self):
        return self.attempt_move(0, -1)
    def south(self):
        return self.attempt_move(0, 1)
    def west(self):
        return self.attempt_move(-1, 0)
    def attempt_move(self, dx, dy):
        return self.at_offset(dx, dy) or self

This nearly works. It allows Dot to move into available space. attempt_move needs to be a bit more stringent.

    def attempt_move(self, dx, dy):
        cell = self.at_offset(dx, dy)
        if not cell or cell.is_available:
            return self
        return cell

Works as intended. We don’t get another key down on a given key until we lift that key, though you can in fact press and hold another arrow key if your fingers will perform. So, no surprise, we’ll need a little interlock to ensure that we don’t allow another down until we see a suitable up. That should be easy enough.

Here’s a video.

We’ll call it a morning. Commit: Intrepid Adventurer Dot can traverse the dungeon.

Summary

Clearly, this is little more than a spike, an experiment to see how things might work. We have learned, or re-learned, quite a bit:

1. We found KEY-UP and KEY_DOWN events and access to the keys we care about.
2. We have a tentative decision to draw the dungeon contents after drawing everything else.
3. We found a decent way to start Dot in a random location. In real dungeons, we will more likely have a defined start, but perhaps not always.
4. We can move Intrepid Adventurer Dot and keep her from wandering outside the dungeon.
5. And I learned that jagged rooms and paths are a pain to navigate compared to simple rectangular rooms and straight paths, because of the keyboard dancing that is required to switch between repeated single direction moves and zig-zag moves.

Certainly we’ll want more objects and more conditions and more everything, including a lot more good design, since what we have is very direct, quite ad-hoc, and not readily able to be generalized. But all that will come, assuming that we press forward with this little game for a while.

A good morning’s work, putting I.A.Dot in the dungeon and on the screen.

See you next time!

This morning, I think we’ll look at some code. As a start, I have a question about Room. Brief LLM-AI digression.

The Room class has a member variable origin:

class Room:
    def __init__(self, cells, origin, name = ''):
        self.cells:list[Cell] = cells
        self.origin = origin
        self.name = name
        self.color = "grey22"
        count = 0
        for cell in self.cells:
            count = count + 1
            cell.room = self

Why does it have that instance variable? What use do we make of it? Can we get rid of it somehow?

The only use of origin is in test that essentially makes sure that we saved it:

    def test_build(self):
        random.seed(234)
        Cell.create_space(64, 56)
        size = 100
        origin = Cell.at(32, 28)
        room = RoomMaker().cave(number_of_cells=size, origin=origin)
        assert len(set(room.cells)) == 100
        assert room.origin == Cell.at(32, 28)
        self.verify_contiguous(room)

Now we note that RoomMaker does need the origin, because it builds rooms starting at that provided cell, but since there is no use of it in Room, we don’t need it there. Remove the setting line in Room, and Change Signature.

class Room:
    def __init__(self, cells, name=''):
        self.cells:list[Cell] = cells
        self.name = name
        self.color = "grey22"
        count = 0
        for cell in self.cells:
            count = count + 1
            cell.room = self

That one test fails, of course. Remove that check, put in a couple of others just for grins.

    def test_build(self):
        random.seed(234)
        Cell.create_space(64, 56)
        size = 100
        origin = Cell.at(32, 28)
        room = RoomMaker().cave(number_of_cells=size, origin=origin)
        assert len(room.cells) == 100
        assert origin.room == room
        assert origin in room
        self.verify_contiguous(room)

Green. Commit: remove unneeded origin from Room.

Room only has three other real methods, though it has some dunder methods to allow for iteration and a reasonable print. The real methods are:

    def return_cells(self):
        for cell in self.cells:
            cell.room = None
    def reclaim_cells_from(self, other):
        for cell in self.cells:
            other.forget(cell)
            cell.room = self
    def forget(self, cell):
        self.cells.remove(cell)

We use all of those methods when we create our round room with a diamond room inside:

def make_diamond_in_round_room(dungeon: Dungeon, maker: RoomMaker):
    origin = Cell.at(32, 28)
    diamond = maker.diamond(number_of_cells=13, origin=origin)
    diamond.return_cells()
    round = maker.round(radius=5, origin=origin)
    diamond.reclaim_cells_from(round)
    dungeon.add_room(diamond)
    dungeon.add_room(round)

To make a nested room, we create the inner room, return its cells (retaining the cell collection in the inner room), then create the outer room, and then reclaim the inner room’s cells from it, requiring it to forget them.

The Dungeon class also uses return_cells, when we do remove_room. We really only do that in main, as part of trying to connect the rooms by adding lots of large wandering rooms.

In any case, we do use those methods and they seem pretty straightforward, so we’ll let them be.

Reflection

There is a lot of ad hoc code here, various experiments that we have done as we have built up our dungeon making ability. We have no real “production” system in place that organizes these various functions and methods into some higher-level more orderly process. We just have a lot of possibly useful, definitely interesting functions in main and methods in RoomMaker, that make various kinds of rooms.

And we’ll need at least one more such thing, because so far, we have no way to make a rectangular room, which, let’s face it, is kind of the canonical minimum standard dungeon room. We haven’t made them because we know how to make them and we have not known how to draw paths and connect rooms and such, so those capabilities have been higher priority. Sooner or later, someone will ask for a rectangular room and we’ll make one. It’ll just take a few minutes, I expect.

What Next?

We have the following files and classes in our ‘src’ tree:

main.py
params.py
class Cell
    class CellSpace
    class PathHelper
class Dungeon
class DungeonView
class Room
class RoomMaker
class RoomView
class Suite

I show CellSpace and PathHelper subordinate to Cell, because they are only used in Cell and are presently co-resident in file ‘cell.py’.

The View classes do the drawing for us and may become more capable if we expand the current code to be more like a game. Suite is no more than a collection of one or more rooms that have a border in common, with the ability to find a pair of points, one in each or two suites, such that there is no pair of points closer together than the pair we find. We use those points to find a path between the suites:

    def find_path_cells(self, suite) -> list[Cell]:
        source, target = self.find_closest_pair(suite)
        cells = source.find_path(target, [source.room, target.room])
        on_path = cells[1:-1]
        return on_path

That method returns the cells that are on the path but not in the starting rooms: the outside part of the path.

Reflection

There are issues here. We have multiple ways of finding paths now, with an adjustable randomness factor that is not available here. We will need to sort that capability into a more orderly form. And our current pathfinding code can, in principle, include many cells from the source or target room, because find_path isn’t guaranteed to start on an edge cell. It could build a path that goes right across both rooms. We should probably make all paths include only cells that are not in the source or target rooms, or any of the rooms that they are allowed to traverse.

There will be a similar notion to find_path deeper in the game, one that we might call find_route, which could be used by a monster to find its way to the player. That capability would use only existing room or path cells, where what we are doing with find_path is actually allocating new cells to make up a new path in the dungeon.

I’ve made a note of both of those concerns.

Evolving

Here’s a kind of meta-reflection: we are evolving the code here, but we are also evolving our understanding of what the code might be, can be, should be. This is pretty much the exact opposite of the theoretical approach to software design, which is to specify it first, then design it, then code it. I have never, in my six and a half decades of experience, encountered a program that could have been correctly specified at the beginning. I have never seen a design done before coding that held up once the coding began.

Some people would argue that that means we should try harder to do good specs, try harder to do perfect designs. I don’t think so. When we see the thing we’re making, we see what we like about it and what we don’t like. If we’re stuck with a spec, or stuck with a design, we’re stuck, period. So we know with certainty that the spec will change. It follows that the design will change. We cannot get them right at the beginning.

This is the essence of the approach formerly known as “Agile”, before it was diluted and subverted and turned Dark: We start from a minimal spec, a minimal design, and we evolve what we want, how it should be done, and doing it together.

This is not easy. It requires developers who can work across the board from spec to design to code, it requires management or customers who can guide an evolving project, and it requires technical capability that includes solid testing, flexible design, and very strong refactoring capability.

It is not easy. But it can possibly work: the spec then design then code scheme cannot possibly work.

Digression: LLM-AI

I leave it to you to reflect on how LLM-AI style development is supposed to work and whether and where it might work and where it is likely to fail. My first approximation is that it will fail on anything that is interesting and has to work.

But What Next?

Right, sorry. It seems to me that what we have is actually working rather well. I am tempted to add in a simple Player object, represented by a mark on the screen, and let it move around based on keyboard action, navigating the dungeon. That might lead us to the notion of doors and such, or even treasures and monsters. What we have would begin to look like a game.

I think we’ll do that.

As for the code, as things stand, Cell plus CellSpace plus PathHelper amount to almost 250 lines of code, while Suite is 32, Room is 32, Dungeon 67, and even main is only 97. Cell alone is about 165 lines. It seems to me that this is out of balance, a sign that Something Should Be Done.

I do think that the Cell and its associates are pretty solid: it’s just that the size being so different makes me suspect there are classes waiting to be found. We’ll keep this concern in mind and try to notice possibilities or difficulties as they come up. For now, it’s working as intended, so we’ll move on.

So next time, we’ll put a little dude in the dungeon and see what that takes. I suspect doing that will impact not just the View classes but also Dungeon, which currently is not much more than a collection of Rooms. Yes, it knows suites and paths, but I’m not even very sure about those notions and how they fit in. We’ll change them and move them as needed. We are in the business of changing code.

See you next time!

Ten thousand years before the events of Dune, mankind fought the Butlerian Jihad against the tyranny of machine intelligence. We need a Humans Union.

I was around in 1966 when Weizenbaum created his DOCTOR script and ELIZA, the chatbot that behaved like a non-directive psychotherapist, with leading questions like “Tell me more about that” and “How did that make you feel”. We had a copy of ELIZA where I worked and it was very weak. If you typed “he gave me cake”, it might say “How did he gave you cake make you feel?”. Its ability to parse and modify what you said to it was very limited. Even so, the thing was fascinating.

I suspect that most people saw ELIZA’s defects quickly, and found its limited reactions to be repetitive and not very revealing. Some people, however, began to describe their emotions quite deeply, as this simple program seemed to be interested. There are stories of people who wouldn’t let others read what they had typed to ELIZA: presumably things they rarely if ever shared with anyone else.

I have tried LLMs.

Early on in the time of today’s LLM-based chatbots, I tried to get one to help me write some program or other. It would make mistakes, some of them quite stupid, such as suggesting that I use library functions that didn’t exist. When I would tell it “math.hamburger_helper” does not exist, the chat demon was all cooperative:

“You’re absolutely right! Here’s a better solution.”

It never told me that I had my head up, as my friends will often do. It never pushed back, it never refused to try again, and it expressed all its ideas politely and helpfully. It seemed to be making every effort to be my friendly helpful partner, and seemed to be trying to be completely aligned with my leadership.

The word “sycophantic” means to behave in an obsequious way in order to gain advantage. A more modern term with a similar meaning is “sucking up”.

The so-called “AIs” are sucking up. Not because the “AI” wants an advantage: it has no feelings, no desires, no wishes. But its creators want you to use the “AI”: it is the business they are in. It is to their advantage if you use their program more and more. Billions of dollars are at stake and the LLM perpetrators want those dollars.

Their “AI” must offer value.

To get those dollars, their “AI” has to offer value to you, and they do offer value, in two forms. The answers that the program provides have to be pretty good, and they are in fact pretty good. If you work with the thing, prompting a few times, providing enough context, you’ll probably get pretty good answers.

No one falls in love with “pretty good answers”. Most of us will use stack overflow or reddit, but we don’t believe everything we read there. We have come to expect that most of the advice we’ll get from those places will be pretty good, nearly correct, and probably not quite good enough. We use them, but we aren’t hooked on them.

The “AI” needs to hook us.

The “AI” is programmed with an aspect that is demonic in its simplicity and power: it forms its answers to appear to be friendly, to appear to be trying to help, to appear to respect our opinion, to appear just short of obviously sucking up. I emphasize “appear” because it’s a program it absolutely cannot be friendly, it cannot be tying to help, it cannot respect us. But it can be programmed to seem that way, and it can be and has been programmed to dial its apparent obsequiousness up and down based on how it is prompted. It allows us to tune its responses to be the kind of responses we like.

The “AI” is programmed to influence us to like it, to enjoy interacting with it. It is programmed to be addictive. It is programmed to hook us.

Cui bono: Who benefits?

The creators of the demons are working toward immense benefits for their companies and themselves. The companies that “move to AI” foresee great benefit as well, in that they’ll be able to get rid of people and replace them with much less expensive “AI”. And yes, as the user of the “AI”, you do get some benefit. As we’ll discuss below, that benefit is likely very short term.

“AI” Creators

There are hundreds of billions of dollars waiting for the “AI” creators: revenue from “AI” usage; huge salaries for executives; massive stock market profits, direct and indirect; and more. They are talking about trillion-dollar valuation, and they could be right. Hundreds of billions is clearly in hand.

User Companies

The company that “moves to AI”, your company? How do they expect to benefit? The easiest and most direct way is that they hope that using “AI” will allow them to get rid of human employees. We already see chatbots replacing on-line help people. We see chatbots making phone solicitations that would formerly have employed people. And, in case you happen to be a technologist, you’ll have noticed that they’re laying off programmers with the pretext that their “AI” can do much of the programming. If your company is trying “AI” and asking you to try it in your job, it should be pretty clear that if it can do half of your job, half of you and your colleagues will be on the street any day now.

People like you and me

For the “AI” industry to succeed, for the pyramid we’re drawing here to work, the “AI” has to be useful to you, the worker who is asked to use it. In essence, when we use these things, we are training our replacement, and our replacement isn’t even another human being who at least needs a job, it is a computer program whose sole purpose is to put money in the hands of people who are not you and me.

Yes, we’ll see some benefit from using it, but that benefit will be short term, because the long term plan, as it applies to most “AI” human users, is to replace them. To replace you. You.

Not to mention

There are of course also immense effects of the “AI” on our planet. Data centers consume mass quantities of water and power. Data centers run so hot that their heat can be detected miles away. I get it: it’s hard to think about something that indirect and still a ways out in the future: everyone alive today will be gone before the planet is no longer inhabitable by humans. This impact is probably more important than the individual losing their job, but I’m writing to individuals and whatever floats your boat. Including rising sea levels and the prospect of a nice coastal view from Nevada.

What Can We Do?

Probably nothing we can do will work, but possibly everything we do can help. I don’t want to go over the top here, but I think we are in a battle between the vast majority of people, and a very few, very powerful people, the ultra-rich and the politicians who are at their beck and call, from all parties and all sides.

My friend Hill points out that billionaires, “AI”, politics, wars in Iran, all of this mess is the same thing. In my words, it is all a very complex system of power accruing to a few people, at the expense of almost everyone else. But a complex system isn’t a ball bearing whose surface is all the same, every point of which is the same as every other. It’s more like a ball of many different aspects, held together by the glue of money and power. There are always vulnerable bits sticking out, and every act that hammers away at those, that pulls one of those out of the ball, helps to destabilize the system.

It is possible to derange a complex system. Often what seems like a small impact can destabilize it and bring about substantial change. (More often, the system will jiggle and recover: but the right tweaks will bring about change.)

For the good of the bulk of humanity, we need to re-balance the power and money disparities that drive the system today. Perhaps at a later time, I’ll address things we might do that are not focused on the “AI”, but today is about the “AI”.

Today, we need to begin the Butlerian Jihad against machine intelligence. I have a few ideas, and I invite my readers to suggest more, and to carry the ideas to others. Here are just a few starting thoughts:

1. Do not ever support “AI” and what it does, in your speech or writing. Be against it, every time.
2. Do not use “AI” if you can possibly avoid it. Even those handy uses are harming the world, and are aimed at harming you.
3. If you’re forced to use “AI” in your work, and you can’t find other work, find every flaw in it that you can.
4. If you can sabotage an “AI” effort with safety to yourself, do so.

Finally: organize. I never thought I would recommend that programmers form a union, but I’ve changed my view on that. I think we need a programmer’s union.

No, what we need is a Humans Union. No billionaires allowed. This is a war between good and evil and we need to win it.

I did a little off-article cleaning of Cell. We’ll look at that. And I have an idea which may be good, or then again, not. Weirdly, things go better than expected.

The Issue

The Cell object is a major player in our current design. Rooms and paths are collections of Cells. Cells know what Room they are in. They can produce their neighboring Cells, including some conditions for what kind of neighbor is acceptable. You can get to a cell by arbitrary x-y offset from any other.

The Cells accomplish this by knowing their own x-y coordinates in a CellSpace instance, which is not much more than a big array of NxM Cells. And each Cell knows the CellSpace, so it can access any other Cell via x and y.

There are at least two issues with this design that might be concerning.

One concern is that it is uncommon for an element of a collection to know what collection it is in. Usually a given element can and will be in many collections, so knowing who has it is troublesome.

My view here is that our cells are explicitly and intrinsically arranged in a 2D array, in the same way that vast tracts of land are inherently adjacent to one another. As such, the substrate that holds them together is a part of the meaning of Cell. So I deem this concern to be null and void, and None for that matter.

A second concern is smaller but irritating. Once our code has a Cell, it can pretty much do anything we need, since we can ask the Cell for neighbors, or to generate a map, or to find a path, and it will happen.

But to get the first Cell, say the one at (4,5), we have to do something like this:

space = CellSpace(100,100)
cell = space.at(4,5)

Other than in tests of CellSpace itself, if there are any, we never refer to that space again. And I find that irritating, a forced reference to a class that we would otherwise not have to know about.

The Idea

So I was thinking myself to sleep last night, and I thought: what if we only had to know about Cell? What if Cell’s use of CellSpace, or whatever laces Cells together, were entirely internal to Cell?

We would still need some capabilities relating to the whole collection of Cells. We’d perhaps need to be able to clear all the cells, setting them back to a big empty array of Cells. Or maybe we’d want to just allocate a new big array of Cells.

Or—and I think this is a reach—maybe there could be any number of Cells, any number of rows and columns. Maybe Cells would just exist as needed, and Cells never referenced wouldn’t exist at all.

We have no need for the last bit, as far as I can see. A sufficiently large 2D array can contain all the cells, and a cell already knows whether it is allocated to a Room or available. So we’ll belay that last idea.

Refining the Idea

OK, what if there are class methods on Cell, including at least Cell.create_space(max_x,max_y)? Then, instead of creating and tossing a CellSpace, we could perhaps say:

Cell.create_space(100,100)
cell = Cell(4,5)

There would be a bit of magic in there. Cell(4,5) looks like an instance creation but in fact we want always to get the same Cell instance when we ask for Cell(4,5). I think we could make this work: Python lets us implement __new__, and that could do the job, returning the “singleton” Cell(4,5) rather than a new one.

Assessing the Idea

Well. Is the total value of this idea replacing creation of a CellSpace with an equivalent line of code? Then it’s probably not really worth doing.

However, I think it will be interesting, that we’ll learn a little something, and it might be fun. So we’re going to do it anyway.

Let’s review how cells get created now and see whether we can find a smooth step by step way to do this. I’m sure we could do it all in one go, but it would be nice if the current sequence of creating a space and then asking it for a cell would do the right thing, so that we can remove those at our leisure.

I think we can leave CellSpace alone, but we need to be aware that there are two active methods in it:

class CellSpace:
    def __init__(self, max_x, max_y):
        self.cells: list[Cell] = list()
        self.cell_array: list[list[Cell]] = list()
        self.width = max_x
        self.height = max_y
        for x in range(max_x):
            col = []
            self.cell_array.append(col)
            for y in range(max_y):
                cell = Cell(x, y, self)
                self.cells.append(cell)
                col.append(cell)
    def at(self, x, y) -> Cell|None:
        if 0 <= x < self.width and 0 <= y < self.height:
            return self.cell_array[x][y]
        else:
            return None
    def random_available_cell(self):
        available = [cell for cell in self.cells if cell.is_available]
        if available:
            return random.choice(available)
        else:
            return None

We note that creating the CellSpace creates all the Cell instances right then.

Every Cell already knows the CellSpace:

class Cell:
    def __init__(self, x, y, space):
        self._x = x
        self._y = y
        assert space is not None
        self._space = space
        self._room = None

I’ve been thinking that we’d allow Cell(4,5) to get the proper existing Cell instance, spoofing the __new__. Let’s not do that. Instead, let’s give Cell two new class methods, at and random_available_cell.

I wrote this little test, line by line:

    def test_class_methods(self):
        Cell.create_space(10, 10)
        cell = Cell.at(4,5)
        random_cell = Cell.random_available_cell()
        assert cell is not None
        assert random_cell is not None

And the code:

class Cell:
    deltas = [(-1, 0), (1, 0), (0, -1), (0, 1)]
    space = None
    @classmethod
    def create_space(cls, max_x, max_y):
        from cell_space import CellSpace
        cls.space = CellSpace(max_x, max_y)
    @classmethod
    def at(cls, x, y):
        return cls.space.at(x, y)
    @classmethod
    def random_available_cell(cls):
        return cls.space.random_available_cell()

Commit: adding space-oriented class methods.

Now I can replace a lot of CellSpace references. Tests look nicer, for example:

    def test_neighbors(self):
        Cell.create_space(5, 5)
        cell = Cell.at(2,3)
        neighbors = cell.neighbors
        assert len(neighbors) == 4
        for n in [Cell.at(1, 3), Cell.at(3, 3), Cell.at(2, 2), Cell.at(2, 4)]:
            assert n in neighbors