Meaning

Warning: There is this known phenomenon where, when certain words are repeated over and over, they cease to have any meaning and simply become odd sounds. If such a thing occurs in what is to follow, it is recommended to step away for a while until meaning returns.

I’d like to start out by asking a simple question. The reasons why will come up later, but I think the question in and of itself is interesting. The question is this:

What does the word “mean” mean?

Now, I know there are probably any number of people out there (like me) who will immediately point out that the word “mean” can have many different meanings. I’m really interested in the meaning of “mean” that has to do with meaning, though, not with with things like mathematical averages or people who aren’t very nice. So let’s restate the question in a way that is perhaps a bit more mind-bending but hopefully more precise:

What does the last word in this question mean?

Perhaps you are able to come up with a definitive answer immediately and can spit out verbatim a dictionary definition of the word “mean”. Perhaps you could come up with something after a bit of thought. Perhaps you weren’t able to come up with an answer at all. If I can be honest, I was a bit in that last camp myself.

Here is the thing, though: even if you had a tricky time coming up with an answer – or, in fact, couldn’t work up any answer – you still knew what the question was asking. It’s actually a fairly straightforward and common thing to do, to ask what words mean. This means that

even though you couldn’t come up with an answer in words to what “mean” means, you knew what it meant anyway. You just couldn’t express it using other words.

You understood the question, even though you couldn’t actually answer it, even though it was talking about a part of itself, which was something you understood.

Mind buzzing yet?

This raises something I realized at some point, which is that the meaning that we assign to words is not necessarily what is given in dictionary definitions. We typically don’t learn words by looking up their definition. I know that, personally, the vast majority of words I know I learned implicitly, through hearing or seeing them used in context. I know what those words mean, even if I can’t give you a dictionary definition of them. The word itself is how I describe that meaning. Maybe someone can give you its meaning in different words, but that doesn’t change the fact that I use that word to convey that meaning that I intend, because that is the word I use for its meaning.

Sometimes I will go look up a word that I have been using for a while (perhaps a long time) when it suddenly occurs to me that I may have been using it incorrectly all that time. What’s interesting is that usually my internalized meaning of the word agrees to a great extent with what the dictionary definition says, even though I never looked up the word before or had it explained to me in words. I was able to pick up on its meaning contextually.

Let’s add something else into the mix:

What is the meaning of the word “meaning”?

I don’t expect you to work up that one yourself. That one feels even deeper, and when I went to look up its dictionary definition, I discovered there were aspects to it that hadn’t made it into the sort of implicitly derived meaning I had assigned to it. The first definition I came across was this:

what is meant by a word, text, concept, or action.

Ok, well that’s not very useful. It relies on the word “meant”, which is tied up in “meaning” anyway. It’s sort of self-referencing. (More on that sort of thing later as well.)

So I found another, more interesting definition:

the thing one intends to convey especially by language

There are other variants of that that expand more, noting it might not be language as such. You could be using signs, symbols, sounds, gestures, or anything else that communicates.

What I find interesting about this is the “intends to convey” part – we have this thing inside us that we want to communicate to someone else, and we do that with words, gestures, etc. What that implies is that the words themselves are not the meaning. The words are a mechanism for conveying meaning, but they aren’t the meaning themselves.

Ironically, the answer to our question brings us back to the question: if meaning is this thing inside us that we wish to convey, and the words or whatever are just a means to do that, what the hell is meaning to begin with? It is what we intend to convey, but what does that actually mean? What is it that we translate into words or gestures or inarticulate sounds?

One answer might be that the words themselves are the meaning. There are any number of people out there who think that we think in words. I don’t know about them, but I certainly don’t, at least not in the serial, one-word-after-another fashion that I experience when reading or speaking. My brain makes connections much more quickly than that, wordlessly. And, for example, when I’m having a conversation with someone, as I’m listening to them speak, what I want to say next will come to me suddenly, in an instant, before I ever formulate words either out loud or in my mind. I know what I’m going to say, on some level, before I say it.

If you assume that words themselves are their meaning, then you run into an interesting problem: when you try to get to the heart of the meaning of any particular word (excluding for the moment tangible items, which you can sort of point to and say, “that”), you end up in this sort of circular regress: this word is defined by those words, but then what defines those words, and it’s other words which are then defined in terms of more words, or the same words, and it goes on and on. You never get anywhere. There is no foundation. It never bottoms out. You would need to have foundational or simpler words that the other build on… but then what defines their meaning?

And I think it’s born out in normal life: we don’t have an internal dictionary definition for all the words we use. We assign meaning to words and use those words to convey that meaning, but we don’t necessarily have to have, on hand, a knowledge of other words that we can use to express the same thing.

I wish that I could go back to before I knew any words, and to experience what it’s like to not only learn new words but new meanings… if that’s even the right word for what I mean. I don’t mean simply new arrangements of existing ideas. I mean learning something entirely new.

I recently subscribed to one of those “word a day” websites, because I thought it would be interesting to see what I could learn. Unfortunately, the first week was “portmanteau” week (where a portmanteau is a word blending together parts of other words, like “brunch” or “motel”), so it was just combining existing concepts into a new word. Nothing earth-shattering there. Later one of the words offered was “proparoxytone”. A rather imposing word. But it just means “Having stress on the third-from-the-last syllable.” Ok, so somebody made up a word for that. But that’s not really a new idea; it’s more a combining and refining of an existing idea. Words have syllables, syllables have accents, and we know how to count: combine them a bit. Nothing mind-expanding there.

But there was a time when I hadn’t heard the word “mean” before or even had an idea about what it meant. There was a time when I hadn’t encountered “love” or “justice”. We start off easy with things like “apple” and “block” and “hungry” and “mama, I believe I have soiled myself.” Those are tangible things, where we can know what someone means by the word, because it’s something right there, in the real world. Somehow, though, we pick up on more abstract ideas, and all just through context, by taking in how other people use them.

I wonder if we accumulate actual low-level meanings like that, or whether somehow – like language syntax – we have meanings built into our brains, just waiting for words to come along for us to make the connection and learn how to express. Ah, to go back in time, and undo all I know (except this question, of course)…

So why am I going into this? Meaning is something I have pondered often in my work as a computer programmer.

First, we can leverage a computer for anything that we can express in a way such that the computer can act on it. And I have wanted to create games or simulations with characters that could interact with the player, the virtual world within which they live, and each other. I wanted them to have conversations, to gossip, to pass knowledge around. But how do you represent that? How do you encode “meaning” in a computer? At least, can you do so in a (for lack of a better word) meaningful way?

I could simply dump a dictionary into the computer’s data structures. That would be all the words I know and a lot I don’t. But the words aren’t the meanings… Even if the computer could cross reference words with other words to try to come up with definitions, all the words just point to all the other words.

Meaning lies elsewhere.

Even knowing how to construct sentences… you not only have to know what words mean but also what role they play in sentences. All of this is wildly beyond my ability to comprehend.

(Google’s recent LaMDA AI chatbot raises an interesting issue. By using these incredibly large neural nets that train themselves, we may eventually have created consciousness and intelligence without understanding at all what consciousness and intelligence actually are. Buried in the mass of connections… And how will we know if a bit of software actually truly understands the real meaning of something? The “Chinese Room” thought experiment goes into that in an interesting way.)

The other aspect of meaning for me a computer programmer is a bit more down-to-earth: as someone writing code that others will want and need to understand, how do I express the ideas I have in my head in code in such a way that both the computer does well with them and a human being will be able to understand them? We often get hung up on syntactic or structural aspects of the code. Apart from the difficulty in naming things (and except for those times when someone just comes right out and says “this is confusing” or “I don’t get what’s going on), we don’t really emphasize meaning much, at least not in any sort of strong way. We generally want the code to be understandable, but we have very little that guides us in terms of making the code meaningful (in a comprehension sense, not a “higher purpose” sense), in terms of being able to effectively express what we intend to express.

And that, after all, is what meaning is.

So, I’ll continue to explore the idea of “meaning”. I may never get anywhere. It does have the advantage, though, of being something that’s going on inside me in a personal way, which is always a nice property to have.

(Post thought: I’m really interested in the idea about whether there can be new ideas or concepts to learn, on a fundamental level, for someone who is my age. Not repurposing or restructuring or refinement of existing ideas, but entirely new concepts, as we encountered when we were those “blank slate” babies. I’d be very happy to entertain any ideas people have about this. I suspect if so, it will be realms like mathematics, philosophy or something else that involves things existing in the mindscape.)

Excitement

Some things that I have found that give me that mental buzz:

  1. Making a connection between things that I hadn’t seen as being connected before.
  2. Making a distinction between things that I hadn’t seen as separate before.

Both of these open up new ways of looking at things, and that can be quite exciting!

Everything I Know About Life I Learned from Programming Computers

I have been writing software for a long time. I have learned a lot in that endeavor that I realized applied to life in general. Maybe this will be of interest to someone.

  • Just because something’s logical doesn’t mean it’s right or true. For any given amount of information, there are typically a number of possible explanations that make sense. But only one is actually true.
  • The more information you get, the closer you get to the truth. Diving deeper into something helps you to narrow the number of possibilities, refining your understanding.
  • Don’t trust your first instinct about what something is or means. Sometimes your first thought is right – you get lucky sometimes. But if you assume your first, uninformed opinion is the right one, it can prevent you from seeing what the truth actually is.
  • “Good” and “bad” are always subjective. Even when your metric is objective, the assignment of that metric to “good” or “bad” is subjective. It’s better to talk about the metrics themselves. Or just not get into it to begin with.
  • The larger the system, the more chaos creeps in. Breaking things down into small pieces that work doesn’t mean the larger thing will work. You have layers built on top of layers. Complex things are chaotic by nature. And people are inherently complex.
  • You can spend weeks or months planning only to have to modify or throw away your plans as soon as you make your first connection to something real. What you think is going to work might not be what actually will work. Sometimes it’s better to make some explorations, to confirm or discover what is actually real.
  • Imagination is a poor substitute for reality. I have learned to doubt, on at least some level, my first impression of anything. If you want to know what is really going on, you have to get out of your head.
  • Documentation is a poor substitute for reality. Just because someone wrote something down doesn’t mean it’s true.
  • Things aren’t always going to be fun. Sometimes you have to do things just because you have to do them. That’s just life.
  • Things aren’t always going to be easy. There will be challenges you never could have imagined. It’s in the facing of those challenges that we learn about ourselves and grow.
  • Don’t give up right away. Persistence can pay off. Sometimes the difference between success and failure is the fact that you didn’t stop trying.
  • Sometimes the best approach to a problem is to stop, back up, and look at it from a different point of view. It’s easy to get stuck in what you perceive is “the right approach”. But that could just be you running into the same wall over and over again.
  • Sometimes, the best approach to a problem is to talk to someone else. Talking out a problem can help you gain insight. And sometimes the other person just happens to know the answer – they have gone through what you have gone through.
  • Nobody can do everything. You get really good results from a group of people with different skill sets all working together. Every person can play a part, based on what they bring to the party. The trick to having things go well is to look at what people can do, not what you think they should do.
  • Communication is a dark art. No matter how much you might like to think that you’re being obvious and clear, the proof is in whether someone else actually thinks so as well. And if they don’t understand you, it’s not necessarily their fault… or yours. Communication is an interactive, two-way street. And people can differ even about what individual words actually mean, sometimes on subtle levels. To be effective, you have to listen as much as speak.
  • What matters is what a person does, not what a person is. Titles and status mean nothing, at the end of the day. Anyone can contribute. Anyone can create something amazing and worthwhile. Anyone can change the world.

Wait… What?

Ah yes. Definitions.

Who: “What person or people”

When: “At what time”

Where: “In what place or at what location”

Why: “For what reason or purpose”

How: “In what way or manner”

Hmm… Those all use “what”. Let’s go see what’s “what”.

What: “used as an interrogative expressing inquiry about…”

Thanks. That clarifies things. We don’t really know what “what” is, but we do know how it’s used.

So the next time someone asks you, “Which is the odd one out of ‘who’, ‘what’, ‘when’, ‘why’, etc.”, now you can tell them.

Further Thoughts on The Three Bears as Code

After writing and uploading the previous post about a computer programmer stylized rendition of “The Three Bears” (https://www.aniamosity.net/if-authors-wrote-stories-the-way-programmers-write-code/), I spent a good deal of time reflecting on what I had done. And there ended up being some interesting aspects to the process I went through that might cast some light on what we do as programmers when writing and refactoring code.

So I wanted to dive into that a bit…

The first question might be, “What was the process you used to arrive at that?” And there were different aspects to that.

High-level Structure

The initial step was to look at the overall story and see what the meaningful chunks were. It ended up being roughly along paragraph boundaries, but not exactly. In fact, the initial paragraph made more sense to split into two, semantically, since they’re actually about different aspects of the story. (That could be considered a “bug” in the original story’s use of paragraphs.)

I actually think the high-level steps in Story give a pretty good overall sense of the progress of the story – that is, if you know what they mean. So that can be useful in computer code as well: by pushing lower-level details down into functions, you can allow someone to get a good sense of what a function is doing at a high level.

This raises an interesting point, which I hadn’t thought of before:

It’s easier to understand the lower level details when you know where they fit into the higher level structure.

Someone who has read The Three Bears, for example, can know exactly where this fits in:

define Sitting_In_My_Chair:
    Someone's been sitting in my chair

They can see that small piece and understand its role in the overall story.

There is the counterpart to that as well:

It’s easier to understand the higher level structure when you know what the lower-level details do and where they fit.

Something like the overall structure of Story is only as clear as the step names can offer – and you can only put so much information into a name. That is one of the problems I have with the idea of “self-documenting code” as a sort of excuse for having virtually no comments in code: identifiers are of necessity limited. They can only contain and convey so much information.

However, once you know what they mean, then they can be good shorthand for things. Once I know what happens in Girl_Chairs, for example, I can just look at it as “the part where she interacts with the chairs”, and if I later want to find where the bears discover she has eaten the porridge, I can quickly jump to Bears_Food – once I know that that’s where it is. On the other side, if I know the overall arc of the Three Bears story, I could probably jump right there even if I had never seen this particular “code” before. I can map what’s in my head onto the story’s structure.

You can move your level up and down within the code. I think it could be argued that decomposition works best when the view level of the code goes down as you go down into sub-pieces and vice versa. Beware of decomposition where the result is actually at the same level. That can point to an arbitrary creation of concepts rather than a refinement of concepts.

Extracting Common Constructs

Moving on, another aspect of the “codifying” was to extract some constants from the code. Now, that wasn’t necessary, but it can have advantages later. It might be a bit silly to generalize “porridge” as {Food} or to allow the name of the girl to not be “Goldilocks” – “Ms. Locks”, perhaps? On the other hand, I have seen the bears named “Papa Bear” and “Mama Bear” instead “Daddy Bear” and “Mummy Bear”. By having constants outside of the main body that can be changed, then all of their references will change automatically, if so desired.

The structure of the story is the same, but minor details can be easily changed, on a whim.

This is the first part of what is typically referred to in software development circles as “DRY” or “Don’t Repeat Yourself”. Consolidating repeated values like names into overarching constants or variables (or doing so with bits of code into common functions) offers at least two advantages:
1) You can easily change the value of all instances of one of them at once by changing the higher-level definition.
2) By making them all refer to the same thing (for example, Girl for “Goldilocks”), you are saying, “These things are all the same.” That might seem obvious in this case, but there will be cases where that isn’t true. Having that additional clue when looking at the code makes it easier work with, because you know what is meant to be the same and what isn’t.

When refactoring, we need to differentiate between things that happen to be the same and things that actually are the same, especially when we consider coding them as the same thing.

Consider, for example, my injection of Bear_Scene to replace the three repetitive bear sections. On the surface, it seems reasonable: if you look at those sections, they are basically the same as each other, structurally, with just some minor differences in wording. However, I made a mechanical decision, which is that I would make them all be expressions of the same pattern simply because it worked to do so. I really don’t know if the author deliberately intended that they would be the same or should be the same or if it just worked out that way. In other words, I don’t know if the pattern I ascribed to them is a deliberate pattern or just something accidental.

That might seem like a very nuanced (and maybe pointless) point, as the code works, but when you’re working with software, the distinction in semantics can become important if things need to change later. By forcing the text to fit the pattern (and I sneakily did that by changing Daddy_Bear’s dialogue tag from “growled” to “said” in the chair section to make it fit – does that violate the requirements?), it then becomes much more difficult later to change things if, for example, we need to add an additional line into one case but not the others.

The pattern works while it’s a pattern. But if things need to change in one case, then the question becomes, “Do I need to remove this case from the pattern, or do I need to extend the pattern to cover this varying case?” And you can typically do it either way, though if you do the latter too much, it can lead to horribly complicated code with lots of exceptions and variability, trying to account for variations in a pattern that might not actually be a pattern anymore.

This is where it really helps to understand what the code actually means. But we can’t always have that insight, especially when it’s code written by others.

Objectifying the Bears

After some initial breaking down of what varied in the various scenes, I discovered I had a number of constants like “Daddy_Chair_State”, “Mummy_Chair_State”, “Daddy_Chair_Size”, etc. where all three bears had the same set, and I had unique calling cases for each bear. At that point, I saw I could invert things a bit by dividing and consolidating the constants into structures, one for each bear. Then the other chunks could look at which bear was in play and use its values. I could just pass the bear around instead of the values within, and the underlying chunk could pick out the part it needed.

So “Daddy_Chair_State”, for example, became “bear.chair_state”, where “bear” could be one of the Daddy_Bear, Mummy_Bear or Baby_Bear “things”.

This isn’t really “object oriented”, in that there is neither encapsulation nor even any inheritance. It’s really more “structured data”. In fact, I made a point of using “thing” instead of “object” (which had connotations) or “struct” or “structure” (which sounded techie and even language specific).

There is possibly more that could be done along those lines. But then, there’s a limit to the gains you make, and doing too much can lead to code being harder to understand, even if it “works”.

This leads us to some of the difficulties I noticed during this exercise.

The Difficulties with Compression

As I mentioned before, it’s easier to understand the lower-level pieces when you know where they fit into the higher-level structure. That is one reason why the person writing the code is in a better place to understand the decomposed, semantically compressed code, as they (at least when they wrote it) have the full picture in their mind of what it all means and where it all fits together.

Someone coming onto the code for the first time won’t have that advantage. And that is something I think we need to be aware of as programmers: that someone else won’t have the same mindset that we do, even if “someone else” is us 5 years down the road. (Though, in all fairness, I tend to find it easier to get back into a mindset I once had, even if I’m not in it at first when encountering old code.) It might make sense for us as the all-knowing programmer to keep breaking the code down into smaller and smaller pieces, as we know how they all fit and – more importantly – what they all mean. But someone else won’t, at least not at first. At that makes the code harder to understand, if the pieces become so small that they have little semantic information on their own, or if the divisions are along syntactic lines rather than semantic lines, where it becomes hard to work out what something actually means.

Take, for example, the Said_Food_Is chunk. That is exactly one line, and it’s used in exactly one place. That came into being because I originally replaced a few separate lines with that (doing a sort of textual replacement), and then later when I compressed the resulting structures using those lines into one thing, it became a single instance again.

The question is, “Is this chunk useful or does it make the code harder to understand?” Initially, it had a use, as it replaced several common sections. But I would postulate that, now that it’s back to a single use, not only does it not serve a purpose, but it makes the code harder to understand, as the name for it doesn’t add any useful information and it’s just another level of indirection. It becomes just another concept to have to deal with when understanding what is happening. The decomposition has gone too far.

What’s interesting to consider is how “helpful” decompositions differ from “harmful” decompositions. If you look back at the original Story breakdown, it felt “helpful” because it allowed us to operate at a higher level and gain an understanding of the code at that level, without having to plow through all the low-level details. It actually added information, by providing a structure that we might not have noticed otherwise. However, the Said_Food_Is chunk doesn’t have that benefit – it doesn’t take us up or down levels. It’s just a replacement with no value. It is introducing an extra step to go through, but it doesn’t offer any additional insight, whether it be structural or “these things are all the same”, which is what you get when replacing things used in multiple places. It’s barely a separate thought, and yet it’s trying to be one.

The Difficulties with Abstraction

I wanted to look at one more chunk, which is the Bear_Scene one. This is really a template to be filled in. And it works for what it needs to do. However, if you were to hand that to someone outside of the context of this code, it would be hard to get a good sense of it. I mean, you could see what it does, but you may not know exactly what it means. And this is something I have noticed often in code, which isn’t a 100% generality, but it happens often enough to make it worth watching out for:

While it can feel good to find patterns and generalize the code through common abstractions for those patterns, abstractions tend to be harder to initially grasp than concrete code.

Again, I wouldn’t say it’s generally true. Things like templated or generic containers, for example, have good semantics that make immediate sense. However, other abstractions – especially if they don’t have a unifying concept behind them – can be harder to grasp until they can be placed into context so their usage can be seen. We can extract the pattern out, but not all patterns have good semantics outside of the code that uses them, which would allow them to stand on their own in our minds.

If Authors Wrote Stories the Way Programmers Write Code

There is a saying in coding circles that code should read like well-written prose. While on the surface this sounds like an admirable goal, we’re actually taught to break down our code, which can lead to it being hard to follow and understand if done to too fine a detail. Its interesting to compare that sort of writing to actual prose.

The following is a made up example of the other way around: what prose would look like if written like typical code. The main point of this is that code readability is something worth thinking about – and that maybe the automatic decomposition of code into smaller and smaller units may not always be the best thing to do, especially if we are interested in having the code be able to be easily understood. At some point, we begin to lose a lot of the context and coherence that allows us to maintain it properly in our minds.

I don’t really have hard-and-fast rules for when to break down or not, but it’s something I have been keeping firmly in mind when writing code lately. I think it’s worth thinking about and exploring in different ways to see what actually works best.

The story is “Goldilocks and the Three Bears”, with text taken from this website: https://www.wardleyce.co.uk/serve_file/699125

I fixed one error in the text and normalized some of it to keep the code from getting too special-case. There may actually be bugs in this, as it’s not something that can actually be run.

Enjoy!

=================================================================

{Story}         # Execute the story!

define Story:
    {Intro}
    {Girl_Enters}
    {Girl_Food}
    {Girl_Chairs}
    {Girl_Beds}
    {Bears_Enter}
    {Bears_Food}
    {Bears_Chairs}
    {Bears_Bed}
    {Girl_Exits}

constant Girl: "Goldilocks"
constant Food: "porridge"

constant Just_Right: "just right."

constant Daddy_Size: "big"
constant Daddy_Bowl_Size: "large"  # fix this inconsistency?
constant Mummy_Size: "medium"
constant Baby_Size: "small"

thing Daddy_Bear: [
    name: "Daddy Bear",
    bowl_size: Daddy_Bowl_Size,
    food_state: "too salty!",
    chair_size: Daddy_Size,
    chair_state: "too big!",
    bed_size: Daddy_Size,
    bed_state: "too hard!"
]

thing Mummy_Bear: [
    name: "Mummy Bear",
    bowl_size: Mummy_Size,
    food_state: "too sweet!",
    chair_size: Mummy_Size,
    chair_state: "too big, too!",
    bed_size: Mummy_Size,
    bed_state: "too soft!"
]

thing Baby_Bear: [
    name: "Baby Bear",
    bowl_size: Baby_Size,
    food_state: Just_Right,
    chair_size: Baby_Size,
    chair_state: Just_Right,
    bed_size: Baby_Size,
    bed_state: Just_Right
]

define Eating_My_Food:
    Someone's been eating my {Food}

define Sitting_In_My_Chair:
    Someone's been sitting in my chair

define Sleeping_In_My_Bed:
    Someone's been sleeping in my bed

define Intro:
    Once upon a time there lived three bears and a little girl called {Girl}.

define Girl_Enters:
    One day, she saw a house and went inside.
    {{break}}

define Girl_Porridge: 
    She saw some {Food}.
    {{break}}
    {Tasted_Bowl_And_Commented(Daddy_Bear)}
    {Tasted_Bowl_And_Commented(Mummy_Bear)}
    {Tasted_Bowl_And_Commented(Baby_Bear)} She ate it all up.
    {{break}}

define Girl_Chairs:
    {Girl} saw three chairs.
    {{break}}
    {Sat_In_Chair(Daddy_Bear.chair_size)}. “{Chair_Is(Daddy_Bear.chair_state)}” she said.
    {Sat_In_Chair(Mummy_Bear.chair_size)}. “{Chair_Is(Mummy_Bear.chair_state)}” she said.
    {Sat_In_Chair(Baby_Bear.chair_size)} and said, “{Chair_Is(Baby_Bear.chair_state)}” Then it broke.
    {{break}}

define Girl_Beds:
    {Girl} went upstairs.
    {{break}}
    {Lay_Down_On_Bed(Daddy_Bear)}
    {Lay_Down_On_Bed(Mummy_Bear)}
    {Lay_Down_On_Bed(Baby_Bear)} She fell asleep.
    {{break}}

define Bears_Enter:
    The Three Bears came home.
    {{break}}

define Bears_Porridge:
    {Bear_Scene({Eating_My_Food}, "it's all gone")}

define Bears_Chairs:
    {Bear_Scene({Sitting_In_My_Chair}, "it's broken")}

define Bears_Beds:
    They went upstairs.
    {{break}}
    {Bear_Scene({Sleeping_In_My_Bed}, "she's still there")}

define Girl_Exits:
    {Girl} woke up and screamed. She ran away and never went back into the woods again.

define Tasted_Bowl_And_Commented(bear):
    {Tasted_Bowl(bear.bowl_size)} and {Said_Food_Is(bear.food_state)}

define Tasted_Bowl(size):
    She tasted the {size} bowl

define Said_Food_Is(food_state):
    said, “This {food} is {food_state}”

define Sat_In_Chair(chair_size):
    She sat in the {chair_size} chair

define Chair_Is(chair_state):
    This chair is {chair_state}

define Lay_Down_On_Bed(bear):
    She lay down on the {bear.bed_size} bed and said, “This bed is {bear.bed_state}”

define Bear_Scene(each_said, baby_added):
    “{each_said},” said {Daddy_Bear.name}.
    “{each_said},” said {Mummy_Bear.name}.
    “{each_said}, and {baby_added}!” cried {Baby_Bear.name}.
    {{break}}

Impulsing: #devtober Post Mortem

Here it is, November 1st, and devtober is now no more. It has been a wild month. I have had highs of creativity and several periods where I was so depressed, I felt like I would never be able to progress.

Lots of takeaways, in no particular order:

I enjoyed writing each day. I used to write more, and it felt good to write again.

Being part of devtober forced me to do a little each day, just to have something to write about. It wasn’t much, and sometimes barely anything at all, but there was daily effort and daily progress of some kind.

Writing the daily entry stirred thoughts that didn’t occur otherwise. Perhaps it’s a bit like “talking to the duck”.

The most frustrating parts were struggling with the Godot engine, in terms of learning how particular features worked and then working around idiosyncrasies in the implementation. When you use a game engine, you’re at the mercy of the features as they are implemented.

Some of the most rewarding parts were becoming competent in those same features in the Godot engine. You have to go through the pain, but you come out the other end with something that works better than you would have had if you had done it on your own. You are really standing on the shoulders of everyone who has worked to make the engine what it is. The body of knowledge, experience, and expertise embodied in the engine is tremendous. And there is so much I haven’t explored yet.

Making screen captures is a really good way to see progress. And it’s really nice to see the progress, to look at where you were and where you ended up and know, “I did that.” Without a way to measure, you can have a dim view of what you actually accomplished, which means you’re deprived of that energy that can help keep you going.

Sometimes it’s good to walk away for a while and then come back.

I need to – and want to – get better at art. I’m often pleased with what I can do, frustrated with what I can’t do, and determined to increase how often I’m in the former category.

You will have times when you know exactly what the next step is, and you will have times when you have no idea not only what the next step is but where you’re going at all.

If you want to complete a project like this, you have to be persistent. Never forget what you’re trying to do. Don’t compare yourself to others how have “made it”, thinking you can never do that. You may not do what they did, but you can still do what you can do. And what you can do is something that is yours, your creation, and part of you. If you want to share it with the world, then make it happen.

Game programming is hard. I have been writing software for over 30 years, and I’m continually surprised how working on a game is different from other software in a way I haven’t been able to quantify yet. Part of it, I think, is that you can’t fudge things. You can’t cut corners. Everything is right up front. Everything is part of the player’s experience.

That’s all. Well, there’s probably more, but I’m running dry. In half an hour, I might have ten more thoughts. But I don’t know if anyone is going to read this anyway.

I’m glad I took part in devtober. It has been an eye opener in many ways, and what I started here is something I want to continue.

#devtober, ober and out.

Impulsing: #devtober Day 31

Today ended up being the most productive Saturday I have had in a while.

After my write up last night, my brain was branching off on new ideas and thoughts. I began envisioning the levels being platforms in a broad 3D space, and when you finished one, it would whisk you off to another with slick animation. And you could see in some form the levels around, beside, below, etc.

It was a really cool idea. And it was far too ambitious to try to do right now.

Granted, it would be fun to try, and there’s nothing ruling out doing something like that ultimately. But what stuck in my mind was this image of the puzzle level sitting on this thin sort of platform floating in space or air or whatever you like.

First thing this morning, I swapped out the plane used as a background with a thin, broad cube – the same side, but not with some depth. Given the angle of view, it was hard to see the depth, so I bumped it up a bit.

Then I bumped it up a bit more.

Then for grins, I bumped it up a whole lot more, and suddenly I saw something I really liked. It’s probably not fantastic in the gaming world, and it’s not what I would go with if I had more artistic talent or a better vision. But I like it enough that I’m happy to settle on this for now. I mean, this is just a passion indie game that likely will never go anywhere. I want to get it to the point where people can play it. I just need something to build on.

I sometimes feel like I’m avoiding working on the levels. Perhaps I am. But there is also a rationale for getting some of the more global details settled: it’s easier recreating a few levels than a few hundred. With what I have now, I feel like the idea is solid enough that (hopefully) things won’t change too drastically, at least for this first round.

Here is the first level, reworked:

Initially, it was just a cube (properly sized). That was easy to deal with. The next level has jog in it, and I wanted the background to follow. If nothing else, it helps to see the 3D.

Man, that was a pain.

Sure, you can resize and move blocks fairly easily in Godot, but trying to butt blocks up against each other isn’t easy. And if you want to make a block larger, it resizes from the center, so then you have to guess around how large it will be and then reposition it. Not bad for one or a few, but after completing the even more complex third level (which wasn’t even that complex), I was at the point where I knew that approach wasn’t going to be workable.

Then it occurred to me that perhaps this was a good time to re-evaluate GridMaps, now that I know what will actually be in them. I started out with a simple tall narrow cube, full height but 1×1. Immediately, I hit the problem that the GridMap was centering this tall cube in the Y direction, whereas I wanted it to be top aligned.

I tried offsetting the GridMap to make the top line up, but then the perspective camera made painting the blocks impossible. (You would need to figure out where the bottom way down there would be.) Thinking now, a top view or orthogonal camera would have solved that. What I did instead was to research the problem, and I learned that others had it, and there was no solution in Godot for it besides creating your own mesh in an external tool like Blender.

That’s what I ended up doing. A lot more transpired after that, including some really frustrating things around getting the mesh to show up and the fact that the GridMap plane can be moved up and down, and to pan the view you use the middle mouse button plus shift, and it turns out that if you hold down the shift key and spin the mouse wheel, the plane moves up and down. I noticed the grid had changed colors, and the objects being placed no longer lined up. It took me too long to figure out what the heck was going on. Even now, even being careful, when panning I will occasionally move the plane by accident and have to reposition it.

On the positive side, being able to move the plane up and down opened up some creative possibilities in terms of level design (“artistic” more than functional), so it ended up net positive after quite a while of hair tearing. You can see how the corners in the above picture are a little lower. It’s not worthy of hanging in a museum, but it does break up the monotony a bit.

Some more levels:

I finally feel like I know it string the levels together now.

Time to start building out the game more.

Day 31: A bit scary at times. But also something sweet in the end. (Ok, corny. I know.)

The final day of devtober. The month has flown. Not every day was great advances, but a little each day gets you somewhere.

I’ll write up the post mortem tomorrow.

Impulsing: #devtober Day 30

Another one of those days. Not much done externally, but a lot of time spent thinking and doing some research. I have a set of levels, but I need to work out how to connect them together – the overall strategy to build the game from the levels.

I could just string them all together, but that makes for a linear game. And it creates a situation where if someone can’t solve a puzzle, they’re just stuck and can’t proceed. I’m determined that the player will have more freedom, but that means some sort of navigation of puzzles, as well as being able to exit a level or more to a different puzzle or section of puzzle in the same level. Also, some levels might have different puzzle sections, so it’s important to be able to come back to a level and continue it. (At this point, I plan on every level you visit remembering its state. The entire game is in play at once. That has some interesting ramifications in terms of whether you can do irreversible actions.)

To list that out explicitly:

  1. There are multiple levels that can be navigated among.
  2. You can exit a level and come back to it, and the level will be in the same state.
  3. There may be multiple ways to leave a level (places to go to), with some being easier and some being more advanced.
  4. There is some sort of overworld or other type of hub level that the other levels branch off from.

Of course, that could all change. I had originally envisioned a single level with all parts of the machine on it, which you would massage into operation as a single master goal. My reluctance to do that has two aspects: 1) having smaller “bites” to focus on might be easier for the novice player to deal with in the beginning, and 2) I have concerns about performance for something that large all operating as a single network.

Stating things like this, in and of itself, has stirred some thoughts. Perhaps I should do this more often, even if only to myself.

Penultimate but not. Life will continue beyond devtober.