This is a beginning.

I'm in the middle of a project, a solo-developed video game. Nothing flashy, bare-bones and back to the basics of play; amusement without much risk of addiction. A game meant to be walked away from, and worth returning to. A fusion of thoughtful strategy and playful tactics, with story run through its core. At least that's the plan.

In case the title needs deciphering, "RL" is an acronym for "Rogue-like", a wide genre of video games that began in 1980 with the release of a video game called Rogue (https://en.wikipedia.org/wiki/Rogue_%28video_game%29). In recent years the genre has grown amidst a movement of "old-school" revival in video games, part of which means they are made with pixel art, or even text-only visuals. GoblinRL falls into the latter; it consists of text or textual characters on the screen and nothing else. This includes all the symbols you can see on your keyboard, and many more. This is a limitation taken on intentionally and lovingly.

At this point you may be thinking, Okay, but... why? Well, I want to focus on software architecture and game design over graphics and animation, but more importantly: limitations are structure, and structure is good for art. Consider a dreary, rainy day; bitter cold and smothered below steel-colored clouds. You glance out a rain-speckled window at a vast plain of dead grass, maybe a boulder or two drowning in the rain, but otherwise nothing to catch your gaze - nothing specific to look at. Then, the clouds break and a ray of golden light casts down from a tiny patch of blue sky right onto one of those boulders. Something emerges from the shadow beneath. Light glimmers off of its fur as it hops atop the boulder to see if the rain has passed for good. It's a squirrel. It looks up into the beam of light, it sniffs the cold air and exhales a tiny puff of mist. It shakes the wetness off its fur and sits motionless, eyes closed, enjoying the warmth of the sun. A moment ago your view was dull, and now - courtesy of light cast specifically on that boulder and nowhere else - that scene is beautiful; greater than the sum of its parts: dead grass, grey stone, and a wet rodent. This is the power of structure. It is the reason a poet may choose to write a haiku, a sonnet, or a ghazal instead of free-form prose. Its the reason why a painting is enhanced by a complimentary frame, proper lighting and a good location. It's the reason why plays are performed on a stage, and why that stage tends to change from scene to scene.

...limitations are structure, and structure is good...

Let me switch gears and get into the grit. GoblinRL is a long-term project, this blog is a public record of its progress. It's amusement for people other than me who may be interested in this sort of thing. I'm hoping to keep it simple, a way for me to communicate with you, and a core for a community to form around. That being said, I do enjoy discussing the technical aspects, so I'll be sprinkling that in whenever it feels right.

It Feels Right, Right Now

Let's talk ECS and OOP.

If you're not a programmer, OOP stands for Object-Oriented Programming, a paradigm or "style" of structuring sections of code such that each is isolated and interacts with other sections in well-defined, provable, understandable ways. The point is to make sure the program is readable to the next programmer who looks at it (which may be your future self), and to ensure that when something breaks - not if, when - you can fix it by changing code only in the one isolated section that broke, rather than having to understand the entire program in order to begin to search for the problem.

ECS stands for Entity-Component-System Architecture. The "A" is left off and people tend to just say ECS, but that can cause some confusion when trying to understand what ECS means. It is not a "system of entities and components", it is a programming paradigm where all in-game things are entities, each of which has some unknown conglomeration of attached components. In addition, there are systems that read/write to subsets of components. e.g. In the GoblinRL screenshot at the beginning of this article, the player is represented by the "@" symbol. In the code, the player entity has a component called Renderable which contains data representing "@". During each iteration of the game loop (Not to be confused with the "core gameplay loop" from the world of game design. [1]), every object with a Renderable component (everything you can see in the screenshot) is drawn to the screen based on the data in that component.

The downside of ECS architecture is that it does not fit neatly into the OOP paradigm, and so requires some sort of barrier between itself and the OOP parts of the software/program/game.

OOP is roughly and loosely defined like this: Code is separated into self-contained "objects" that contain both data and the logic (or systems in ECS lingo) which operate on that data.

Entities in ECS are very similar to objects, but they don't contain any data or logic.
Stand-alone snippets of data (i.e. components) may or may not be attached to each entity, and may be removed or reattached on the fly as the software runs. Systems, during each iteration of the game loop, grab all entities with some predefined set of components and use or mutate the data within them somehow.

For example, an Cat programmed in OOP would have fields like num_legs, hunger_level, mood, etc, that are always there and always have some value assigned to them. Whenever another object looks at Cat, it should always be able to get some answer to the question "How hungry are you right now?". In ECS, a Cat would be some entity with at least one component maybe called Name or Animal with data containing the word "Cat". If it is hungry, some Hunger component is attached to it to signify this, which would contain some data to represent the degree of this Cat's hunger. Now, under the ECS paradigm, the game never asks, "Hey, all cats, how hungry are you right now?" Instead, it grabs all entities with Hunger components and stuffs them into a machine that we're calling a system, in this case the Hunger system specifically. It doesn't matter if the entity is a cat, and ant, or a whale, or if any entities have a Hunger component or not. All that matters to the ECS machine that Hunger components might exist, and if they do they must be run through the Hunger system.

The difference between OOP and ECS is subtle from this perspective, but it makes a world of difference in the performance of the code and the style in which the game is programmed, designed, and expanded upon. Basically: OOP software is challenging to scale/expand, but relatively easy to begin working with. ECS scales extremely efficiently, but there is a lot of overhead work required before any one part of the architecture begins to function at all.

So which is better?

Neither. That's like asking if you prefer wrenches or screwdrivers. They're both necessary tools for different jobs. GoblinRL uses both. I'm currently working on an upgrade to the UI/menus of the game, written under the OOP paradigm, and once that section gets integrated into the ECS architecture that controls the game-world, I'll be able to show some more screenshots to help the more visually-oriented among you get as hyped for this project as I am.

Thanks for reading - see you next time.

Footnotes

[1] "core gameplay loop" from game design theory:
This concept is what the user of a game experiences while playing. For example, the core gameplay loop of Tetris is: get a new piece, look to see where it can go, get it to the best location that time allows and/or rotate the piece to fit that location, place the piece, and repeat. The central idea is that whether or not the player gets to reach the next iteration of the loop is the game, and it must always be in question. Will they make it? What will happen next? The questions that keep us entranced by a well-written story are the same questions that keep us invested in a well-designed video game.