{ "version": "https://jsonfeed.org/version/1", "title": "Barely Conscious Games — Devlog", "home_page_url": "https://www.barelyconscious.games/devlog", "feed_url": "https://www.barelyconscious.games/feed.json", "description": "Devlog from Barely Conscious Games, an indie game studio making retro-modern 2D games.", "author": { "name": "Matt Schwartz", "url": "https://www.barelyconscious.games" }, "items": [ { "id": "https://www.barelyconscious.games/devlog/bespoke-engines", "content_html": "

\"\"

\n

Last week I wrote about my new XGUI implementation that I had been working on for the last month. I had put together an Ability Training screen in a couple hours and it was a very smooth process overall and things seemed to be going well. So I took some time off, played some games, and then came back and saw the memory profile had climbed from about 155 MB to over 1 GB even though I was only rendering ~60 static elements on screen. XGUI was allocating about 300 KB of memory per second while doing nothing.

\n

\"bad

\n

I was using smart pointers everywhere in C++, and I was able to correlate every constructor to a destructor call, so I started looking at Lua. Like most modern languages, Lua is garbage-collected, which just means for the most part it manages its own memory. You ask Lua for a new object and Lua takes care of creating and keeping track of it, including knowing when it's no longer needed and can be deleted (garbage collected). Garbage-collected languages make it seem like you never have to care about memory ever again. You can create as many objects as your heart desires and no one will stop you... until the garbage collector pauses your entire program to remove all the junk you made and now your game freezes every 4 seconds.

\n

Having come from a primarily Java background, I wasn't sure where to start so I brought in Claude and asked it to "review these C++, XML, and Lua files and find out why we're seeing 300 KB/sec in Lua allocations". After it "dug into the files instead of guessing" and "had the full picture", it managed to find a couple of optimizations that helped bring the allocations down all the way to 3 KB/sec. Pretty good, I told Claude, but there's still a leak. Claude then assured me that we had made great progress and 3 KB/sec is really not that bad so we can stop now. The hell we can, I said, and decided to press on and ultimately found out the cause of the allocations was a clever little bit of code.

\n

The Clever Little Bit of Code

\n

I'm using sol, which is a C++ library that makes working with Lua simple, and one of the things it does really well is that it seamlessly integrates its type system with C++ types. It basically handles the conversions between an int, a string, and a table with a simple assignment (=) operation. Mainly, this is used for converting a known type from a Lua result into a known C++ type, like extracting the numerical result from a Lua function.

\n
sol::function_result Result = lua.do_file(Filepath);\nint ResultInt = Result; // <-- sol converts `sol::function_result` to `int` seamlessly\n
\n

In Lua, everything is a table, and through sol, you can access keys in a table like a standard map:

\n
sol::table Table = lua.do_file(Filepath);\nint Status = Table["status"]; // <-- retrieve the `status` field from the table\n
\n

And I mean everything in Lua is a table. Dictionaries, of course, and arrays, and objects. And importantly for our story, C++ defined types are tables, too. If you had a Creature class with the Name field, you could access it like this with sol:

\n
lua.new_usertype<Creature>("Creature", "name", &Creature::Name);\nsol::table MyCreature = new Creature(...);\nstd::cout << "Creature's name is " << MyCreature["name"] << std::endl;\n
\n

So putting all this together, you can make pretty simple routing logic that seamlessly crosses between C++ and Lua objects in just a few lines:

\n
// Lookup->Path is a vector of strings\nsol::object Res = RootTable;\nfor (; i < Lookup->Path.size() && Res.is<sol::table>(); ++i)\n{\n    const string& P = Lookup->Path[i];\n    Res = Res.as<sol::table>()[P];\n}\n
\n

This functionality was critical because of runtime bindings in XGUI, a capability which allows you to create, for example, a text element that always displays the health of a creature in a single line of XML:

\n
<Text text="{$.creature.stats.health}" />\n
\n

And those bindings can be attached to Lua or C++ objects or even a mixture of the two. {$.tooltipData.creature.name} renders the name (string) of the creature (C++ pointer) field stored on tooltipData (Lua table). All of these types can be boxed into a sol::object and if it can also be boxed into a sol::table, we can access its fields dynamically at runtime.

\n

Anyway, this clever routing logic is what was causing the persistent 3 KB/sec memory leak. At this point in time, I was looking at a memory leak I didn't fully understand and it was impacting one of the core reasons XGUI even exists. If this feature wasn't there, XGUI really didn't make sense as a 4 week investment.

\n

Making Your Own Game Engine

\n

If you ask anyone in the indie gamedev community which game engine you should use to make a game, you'll get a bunch of different answers. Unity, Godot, Love2D, etc. But there's always one answer you'll get consistently: "don't make your own game engine". It's good advice and when XGUI failed, I started to reconsider my decision to make my own game engine. I was spending all this time working on a framework for the game rather than the game itself. This was day 3 of debugging and it felt like I was genuinely stuck on this memory leak. If I couldn't solve it, I felt like I'd have to abandon the engine.

\n

Then I remembered that I've never not been able to solve a problem so why should this one be any different?

\n

\"better\"

\n

So I just got back to work assuming I would figure it out.

\n

The Answer is Always Caches

\n

I pressed Claude some more to dig into this problem, focusing on that block of code in particular and it started searching the sol include files I had downloaded as well. It pointed out that when it comes to userdata specifically (ie, the C++ objects), sol boxes the C++ data into a freshly-allocated Lua object every time you create a new reference to that object (which in C++ looks like sol::table Table = OtherTable, where the = is invoking the copy constructor on sol::table). And I'm doing that a lot since the runtime bindings are updated every frame. I wasn't completely convinced Claude was correct here; LLMs hallucinate constantly, after all. But, I proved it was right by adding a gate to prevent userdata from being dereferenced through sol and the Lua allocations immediately dropped.

\n

One of the most important skills for a software engineer is the ability to break down problems and abstract them. A lot of problems have already been solved and many unique problems are really just solved problems wearing a different hat. On the surface, my problem was "how do I stop invoking the copy constructor?", but put a different way, the problem was really: "I need a way to access data without repeating unnecessary work". A cache solves that problem by doing the work once and keeping the result for next time. So I implemented a cache.

\n

I would allocate the Lua reference once, store it in the cache, and the next time I need to find that reference I just return it from the cache instead without an additional allocation. For the cache key, I treat the runtime binding (eg, $.tooltipData.creature.name) as a route and each hop in the route is cached: so for our example, there would be an entry for $, $.tooltipData, $.tooltipData.creature, and $.tooltipData.creature.name. As a result, the Lua allocations finally dropped to 0 KB/sec while idling, and incidentally, the frame time was reduced by 50% (4ms -> 2ms for 670 elements on screen).

\n

Conclusion

\n

Even though I managed to solve this particular problem, I know it won't be the last bug. I know that it takes a lot more time to work in a custom game engine because you have to reinvent features that are ready-to-use in commercial game engines. And I know that this is time taken away from making content for the game. So why do I persist? Honestly, because I choose to.

\n

\"persistence\"

\n

One piece of advice that's stuck with me for years is write what you know. Since I know programming a lot more than I know art and music, I'm focusing on that for Script Kitties and a custom game engine is the perfect playground. I don't know how that will translate to success, but at this point the only one who can stop me is me.

\n", "url": "https://www.barelyconscious.games/devlog/bespoke-engines", "title": "Custom Game Engines", "summary": "Why You (Probably) Shouldn't Write Your Own Game Engine", "date_modified": "2026-07-16T15:30:00.000Z", "author": { "name": "Matt Schwartz", "url": "https://www.barelyconscious.games" } }, { "id": "https://www.barelyconscious.games/devlog/xgui-source", "content_html": "

\"\"

\n

Four weeks ago I decided to invest what ended up being way more time than I anticipated in creating a new GUI engine for Script Kitties, XGUI. It was designed to support faster and easier development of all the GUI screens I'm going to need, which is a lot.

\n

I started working on one of the new screens, an ability editor, to test it out. The ability editor will allow players to change which abilities a creature has available to use in combat from a library of unlocked abilities. The player unlocks new abilities by exploring and completing challenges in the game, such as defeating a number of enemies in combat with fire abilities to unlock Firestorm.

\n

I took XGUI out for a spin and I'm thrilled to say the whole process was an absolute delight. Here's a demo of building that screen, with the editor on the right and the game itself running on the left with hot-reloading:

\n

\n

Design-Driven Development

\n

In the software-buildin' business, when you set out to make something that will take many weeks or months to build, that something is a risk because you don't know that it will work. You can manage the risk by clarifying the ambiguity, isolating unknowns, building proofs-of-concept, and, ultimately, trusting your gut a little. It takes time to do all of that, but it's good to know if it'll be worth it before you waste time.

\n

For XGUI, I did just that. I started by writing a design document, which is just a fancy name for a markdown file that describes what I want to build and how I'm going to build it. I spent a couple days working it over, putting down examples of the interface and designing rules around what values are possible for each attribute and what those values would mean for the engine's responsibilities. If you've ever read through the instruction manual for a board game, you've read a form of a design document. Both the manual and design documents introduce new ideas and describe precisely how those ideas are supposed to work in practice.

\n

Now, I felt pretty good on day 3, and having a well-rounded design document helped maintain confidence for the next 20ish days. See, software gets built like a 3D printer, going layer-by-layer, setting up foundations before building on top of them. Sure, you test your code along the way so you know each piece is working as it's supposed to, but until that last piece gets built you still don't know the whole thing will work.

\n

Each piece along the way that worked would simultaneously boost my confidence while increasing my anxiety for the final flip when I would test it out end-to-end. Any small mistake nestled deep in the code early on may not be visible until everything's hooked up. And those small mistakes are the most difficult to find during an end-to-end test.

\n

The Proof that was in the Pudding

\n

With XGUI, since there already existed a functioning GUI engine, the question wasn't just, "would it work?" but "would it work better?" And as soon as I went to add a tooltip to an element, I was convinced the answer was yes, it will work better, because all it took was two little attributes on any element that needed to have a tooltip:

\n
<Panel id="itemSlot" tooltip="gui_item_slot_tooltip.xml" tooltipData="{.}" />\n
\n

\"ability

\n

All the messy bits that come with detecting whether an element that supports a tooltip has a mouse over it or not and displaying another element depending on that all collapsed into these two beautiful attributes: tooltip and tooltipData. The backend logic orchestrating the messy bits migrated to C++:

\n
if (auto& tt = Hit->Tooltip)\n{\n    auto View = Hit->GetView();\n    auto Model = View->FindInModel<sol::table>(tt->ModelIndex);\n    tt->GetView()->SetModel(Model);\n\n    // show only if it has data\n    if (Model.valid()) Tooltip = tt;\n    else Tooltip.reset();\n}\n
\n

Runtime bindings were another material gain which allowed a text element to be set dynamically based on game data instead of static strings.

\n
<Text id="levelText" text="Lv. {$.selectedCreature.level}" />\n
\n

\"bindings\"

\n

Again, C++ handles the finnicky part about all that:

\n
virtual void Apply(const ViewHandle::ScopeContext& Context, FWidget& Widget) const override\n{\n    if constexpr (std::is_same_v<T, std::string>)\n    {\n        if (StringTemplate.empty()) return;\n\n        string res;\n        bool bOpen = false;\n        size_t i = 0;\n        for (auto& c : StringTemplate)\n        {\n            if (c == '{')\n            {\n                bOpen = true;\n            }\n            else if (!bOpen)\n            {\n                res += c;\n            }\n            else if (bOpen && c == '}')\n            {\n                if (i >= BindingResolvers.size())\n                {\n                    return;\n                }\n                res += BindingResolvers[i++]->Resolve(Context);\n                bOpen = false;\n            }\n        }\n        Widget.*Member = res;\n    }\n    else\n    {\n        Widget.*Member = BindingResolvers[0]->Resolve(Context);\n    }\n}\n
\n

In the early days of my career, I worked with a few different web frameworks like Angular, jQuery, Razor, and React. There were things along the way that I liked and didn't like about each, and so I tried to carry forward just the elements I found enjoyable to work with.

\n

\"high

\n

It's definitely a far cry from being a proper web framework but it does what I need for Script Kitties. I've got the XGUI code hosted in GitHub along with some example XML and Lua code. It's not currently runnable (it expects a simple renderer) but if there's any interest I can get a working demo going.

\n", "url": "https://www.barelyconscious.games/devlog/xgui-source", "title": "XGUI Source Code", "summary": "Hopefully they don't pay me per line of code", "date_modified": "2026-07-09T15:30:00.000Z", "author": { "name": "Matt Schwartz", "url": "https://www.barelyconscious.games" } }, { "id": "https://www.barelyconscious.games/devlog/spotlight-battle", "content_html": "

\"\"

\n

In the beginning, before I had any real plans for Script Kitties, the battle mode was a simple 1v1 arena with some basic actions: fight, run, use item, and switch out cats. Since the game was called Script Kitties, I wanted there to be some kind of "scripting" with the abilities. The idea was there were these items called Biograms that you could find in the world which changed how an ability worked. For example, the Claw ability augmented with a Sweeping Biogram would turn into the Swipe ability that hit multiple targets simultaneously. If you've ever played Path of Exile, Biograms are functionally Support Gems:

\n

\"poe\"

\n

As I was coming up with different kinds of Biograms, I realized that a 1v1 arena could not support my ideas. After all, what's the point of an ability that hits multiple targets when there is only ever 1 target to hit? So in order for Biograms to make any kind of sense, I had to have party-based combat:

\n

\"Party-time\"

\n

I spent too much time working on the new interface and was getting ready to start polishing it up when my nephew asked to play it. So he did a few rounds of combat and then said to me, "All I'm doing is pressing enter". He had meant that all he had to do was hit Fight (enter), select an ability (enter), select a target (enter), and then do it all over again the next turn. Without exaggeration, this was the most important bit of feedback I ever got.

\n

Now, I'm in a lot of game dev spaces online (obviously), and I see this come up quite a bit where a developer gets feedback and their first reaction is defensive: "Well the player just didn't get it". It's understandable, but ultimately it's detrimental. One person in particular stood out to me because when he received the feedback that his tutorial was difficult to understand, he made an entire video blasting the reviewer. I saw the tutorial; the reviewer was right and there were probably many more players who felt the same way.

\n

\"Am

\n

My nephew was right of course, which meant the combat system needed a rework. I knew it would be a huge investment and I wanted to see how it would look before committing too much time, so I put together a quick animation demonstrating the combat in full 2D as a proof-of-concept:

\n

\"Combat

\n

The prototype ended up introducing a lot of concepts that I didn't have in the game yet like action points, visibility, and the terrain itself. I was inspired by games like Divinity: Original Sin 2 which has terrain mechanics that let you light up the ground with electricity and create explosions by mixing fire and poisonous gas. All of a sudden the combat was no longer about just hitting enter.

\n

\n

Abilities and Biograms gained a great deal of depth as a result because of how many different ways the player could interact with the combat system. Some mechanics that emerged:

\n
    \n
  1. Positioning: line-of-sight, range, stealth, cover
    2. \n
  2. Terrain: movement, area of effects, overlapping terrain effects
    3. \n
  3. Action points: resource management, drains and gains
    4. \n
\n

Scripting

\n

With the increased complexity and unbounded ideas, I needed a way to express the logic more easily. I knew early on I wanted to integrate Lua with the game so I could support mods, and so I started by exposing the combat interface. I used the raw Lua headers to start with because I didn't realize there was a better way until I came across sol2. If you're ever looking to integrate Lua with C++, do yourself a favor and use sol2 unless you're a fan of managing the Lua stack by hand. Which I was not.

\n

Anyway, exposing Lua bindings in C++ is dummy easy in sol2. Here I'm defining the Ability type:

\n
lua.new_usertype<Ability>("Ability",\n\t"id", sol::readonly_property(&Ability::Id),\n\t"name", &Ability::Name,\n\t"sprite", &Ability::Sprite,\n\t"description", &Ability::Description,\n\t"shape", &Ability::Shape,\n\t"tags", &Ability::Tags,\n\t"maxTargets", &Ability::MaxNumTargets,\n\t"range", &Ability::Range,\n\t"radius", &Ability::Radius,\n\t"cost", &Ability::Cost,\n\t"hasTag", &Ability::HasTag);\n
\n

which lets you operate on an ability natively in Lua:

\n
local isHarmful = false\nfor _, tag in ipairs(ability.tags) do\n    if tag == AbilityTag.HARMFUL then\n        isHarmful = true\n        break\n    end\nend\n\nif isHarmful then\n    local canAfford = creature.actionPoints >= ability.cost\n    local inRange = closestDistance <= ability.range\n\n    if canAfford and inRange then\n        battle:resolveCombat(creature, creature.position, {closestTarget}, attack)\n        creature.actionPoints = creature.actionPoints - ability.cost\n        return attack()\n    end\nend\n
\n

My mental model for these bindings is: I don't care how the C++ needs to work as long as the Lua is easy and intuitive. I start backwards with Lua by writing how I would want it to work and then retrofit the C++ code to make it work. I call it customer-driven development: you start by writing code like the customer of your API and then figure out how to make it true.

\n

\"my

\n

Now, Biograms were especially tricky because of how I wanted them to work specifically. I wanted an interface that could be used intuitively for any possible combination of actions. I came up with a solution using native Lua tables.

\n

By the way, in case you didn't know, EVERYTHING in Lua is tables.

\n

\"tables\"

\n

In Lua, you might have: action.actionType = "DAMAGE" and using sol2, in C++ you can easily read it like a map: action["actionType"] -> "DAMAGE". Because of this fact, creating arbitrarily-shaped object-looking text becomes trivial:

\n
local damageAction = {\n    target = v,\n    action = CombatAction.DAMAGE,\n    amount = 14,\n    damageType = DamageType.FIRE\n}\nlocal arenaEffectAction = {\n    action = "SET_ARENA_EFFECT",\n    position = center,\n    shape = self.shape,\n    radius = self.radius,\n    effect = "BURNING"\n}\nreturn { damageAction, arenaEffectAction }\n
\n

And if the ability has a Biogram, the different actions created by an ability's script are modifiable. Biograms act on top of abilities, allowing them to change, remove, and create new actions to be processed. The Splitting Biogram, which replicates an ability's damage across multiple targets can be expressed like so:

\n
return function(self, combat)\n    -- figure out how much damage we already did\n    local damageActions = combat:getActions(CombatAction.DAMAGE)\n    local amount = 0\n    for _, v in ipairs(damageActions) do\n        amount = amount + v.amount\n    end\n\n    -- replicate 66% of that damage to all extra targets\n    for _, target in ipairs(findExtraTargets(combat)) do\n        target:takeDamage(amount * 0.66, DamageType.TECHNICAL)\n    end\nend\n
\n

Ultimately, the idea is: abilities describe how they function in terms of actions and Biograms have free rein to change those actions before the ability is resolved to create that feeling of scripting abilities in Script Kitties.

\n

The Player is Always Mostly Right

\n

So, in the end the takeaway is pretty simple: listen to your players. They may not always know how to fix problems but they're usually pretty good at spotting them. In my case, "the game is boring" was enough to send me on a journey to find the fun.

\n", "url": "https://www.barelyconscious.games/devlog/spotlight-battle", "title": "System Spotlight: Battle Mode", "summary": "A journey in constructive criticism", "date_modified": "2026-07-02T15:30:00.000Z", "author": { "name": "Matt Schwartz", "url": "https://www.barelyconscious.games" } }, { "id": "https://www.barelyconscious.games/devlog/xgui", "content_html": "

\"\"

\n

About two weeks ago, I began writing version 3 of my GUI engine, XGUI (as in XML), because I hate GUI programming. XGUI holds a lot of promise for me because of the visual editing capabilities that fall out organically from the use of XML:

\n

\"Editor\"

\n

LGUI (as in Lua), the previous version, had its entire presentation and controller logic defined in Lua code:

\n
local GUI = CreateGUI()\nlocal window = GUI:createPanel({ ... })\n\nwindow.okButton = GUI:createPanel({ ... })\nwindow.okButton.text = GUI:createText({\n    text = "Ok"\n})\n\n-- Register events\nwindow.okButton:registerEvent("OnMouseClicked", function(mouse) \n    -- handler\nend)\n
\n

whereas XGUI, of course, is XML with Lua controllers:

\n
<View controller="myController.lua">\n    <Panel id="window">\n        <Panel id="okButton">\n            <Text text="Ok" />\n        </Panel>\n    </Panel>\n\n    <!-- Register events -->\n    <Event name="OnMouseClicked" handler="handleOnMouseClicked" />\n</View>\n
\n

Why is this better?

\n

For two reasons: visual editing and strict separation of concerns. Obviously visual editing is going to be a smoother process than editing by hand, but how does having strict separation of concerns help? Two words, four syllables: spaghetti code.

\n

\"Spaghetti\"

\n

Setting clear boundaries between what this code does and what that code does is essential to maintaining a large codebase (and your sanity). Without it, you'll inevitably find yourself fork-deep in a mound of spaghetti code. XGUI follows a simple MVC (Model, View, Controller) pattern. XML defines the View (how the GUI should be displayed) and Lua defines the Controller (how the GUI should behave). The Model is the bridge that the Controller mutates and the View renders.

\n

GUIs are highly interactive, especially in video games. There are mouse events, key events, tooltips, sprites, drag-and-drop, visibility, modals... the list goes on. All the while, there's constant communication between the player and the game engine itself, and everything has to remain in sync. And it takes a lot of code to manage all that. At first, it's easy and convenient to do it all in one place but very quickly you'll find yourself in the middle of a 1,500 line Lua file trying to figure out how to render and control the GUI at the same time you're processing input from the player and handling events from the engine. XGUI - through the MVC pattern - helps organize all of that by forcing the pattern in practice. You simply can't implement View declarations and Controller business logic in the same place.

\n

Runtime Bindings

\n

The most common code I wrote in LGUI was updating widgets with data from the game, like a creature's name or sprite for the user to see.

\n

\"profile\"

\n
-- declare the visual layout\nlocal window = GUI:createPanel({ ... })\nwindow.creaturePanel = GUI:createPanel({ ... })\nwindow.creaturePanel.name = GUI:createText({ ... })\nwindow.creaturePanel.sprite = GUI:createPanel({ ... })\nwindow.creaturePanel.level = GUI:createText({ ... })\n\n-- bind data to those visual elements\nfunction refreshCreatureGUI(creature)\n    window.creaturePanel.name:setText(creature.name)\n    window.creaturePanel.sprite:setTexture(creature.sprite)\n    window.creaturePanel.level:setText("Lv. " .. creature.level)\nend\n\n-- later, when the user selects a different creature:\nfunction onCreatureSelected(newCreature)\n    refreshCreatureGUI(newCreature)\nend\n
\n

Just look at how much code that requires and this is for every dynamic element across every screen. And not only do you need logic to set the values, you also need logic to know when to update those values. This is everywhere. It's far more likely that an element needs runtime evaluation rather than a simple static string or sprite.

\n

It's repetitive, tedious, and as it turns out, completely unnecessary. XGUI's other superpower: runtime bindings.

\n

Instead of implementing custom runtime evaluations and update logic, XGUI lets you bind properties (like text) to a runtime value (like name). No Lua code required.

\n
<Panel id="creaturePanel">\n    <Text id="name" text="{$.name}" />\n    <Panel id="sprite" texture="{$.sprite}" />\n    <Text id="level" text="{$.level}" />\n</Panel>\n
\n

Show me the C++

\n

So everything we've talked about so far is great in theory, but how does it actually work? Let's get more technical here.

\n

The XML parsing itself is simple enough. I'm using pugixml, which seems to be the de facto C++ XML library, to do the actual parsing and I created simple facade objects for a more readable interface.

\n

Widgets are the visual building blocks of XGUI:

\n
struct Widget \n{\n    string Texture;\n    string Text;\n    SDL_Color BackgroundColor;\n    // other properties...\n};\n
\n

The GUILoader is a helper class to do the heavy XML parsing into a C++ handle ("GUI") that the engine knows how to update and render.

\n
class GUILoader\n{\npublic:\n    GUILoader(const string& Filepath);\n    unique_ptr<GUI> Load() const;\n};\n
\n

The Widget facade (XWidget) exposes a simple converter to make cosntruction easier. Note the Bindable template type.

\n
class XWidget\n{\npublic:\n    XWidget(pugi::xml_node Node) : Node(Node) {}\n\n    // Handles XML -> Widget conversion\n    unique_ptr<Widget> GetWidget() const;\n\nprivate:\n    pugi::xml_node Node;\n\n    // These are all the properties that can appear on an\n    // element in the XML doc.\n    Bindable<string> Texture() const;\n    Bindable<string> Text() const;\n    Bindable<SDL_Color> BackgroundColor() const;\n    // others...\n};\n
\n

A Bindable is how we express the nuance between static and runtime values:

\n
template <typename T>\nclass Bindable\n{\npublic:\n    string Expression;\n    T Value;\n};\n
\n

During the update call, XGUI evaluates runtime-bound values and updates Widget values so that during the render call, the computed values are drawn to the screen.

\n
void GUI::RenderNode(const Renderer& Renderer, const Widget& Node) const\n{\n\tif (!Child.Texture.Value.empty())\n\t{\n\t\tRenderer.DrawTexture(\n\t\t\tChild.Texture.Value,\n\t\t\tBounds.x, Bounds.y, Bounds.w, Bounds.h);\n\t}\n    // other render calls...\n\n\tfor (auto& ChildNode : Node.GetChildren())\n\t{\n\t\tRenderNode(Renderer, *ChildNode);\n\t}\n}\n
\n

The runtime bindings have proven to be the most fun challenge I've worked on in quite some time. I love implementing ergonomic APIs and interfaces and in general just making code easy to use. This especially is one of those areas where AI just falls flat on its face, but I'll save that rant for another week.

\n

So was it worth it?

\n

XGUI came with tradeoffs. It took 2 weeks to make and during that time I wasn't able to work on any of the game's content or core mechanics. XGUI will make it faster and easier to implement GUI screens, but how much time it will save is still theoretical. If the only benefit was faster development, it would be a risky bet.

\n

Something that often gets discounted is the developer experience or DX. When something is easier to use, I've noticed that I'm able to do more with it. When I evolved to LGUI, my screens were able to become much more complex and polished because it was easier to write and reason about. This is the real payoff I'm looking for. With MVC, I get clear separation and organization. With the visual editor, I get a simplified interface for designing screens. And with runtime bindings, I avoid 90% of the boilerplate I'm overburdened with. All of that reduces the mental load required to implement GUI screens and allows me to focus better on improving the player experience.

\n

So was it worth it? I think so.

\n", "url": "https://www.barelyconscious.games/devlog/xgui", "title": "XGUI", "summary": "And how I girl-mathed the cost of writing it", "date_modified": "2026-06-25T15:30:00.000Z", "author": { "name": "Matt Schwartz", "url": "https://www.barelyconscious.games" } }, { "id": "https://www.barelyconscious.games/devlog/gui-hell", "content_html": "

\"\"

\n

I really hate GUI programming. In Script Kitties, I've rewritten the GUI engine twice. The first time was when I went from text and boxes to sprites:

\n

\"Rewrite

\n

And the second was when I realized you shouldn't design GUIs in pure C++.

\n
// This was a simple example\nWindow->AddWidget(RootGUI->NewPanel()\n    .Layout(WindowContents)\n    .Trim(WidgetTrim::None)\n    .AddWidget(RootGUI->NewPanel()\n        .Position({ 1, 0, 4, 0 })\n        .Size({ 0, 0, 275, 48 })\n        .BorderSize(1)\n        .BorderColor(FocusedFrameColor)\n        .Background({ 0, 0, 0, 255 })\n        .AddWidget(RootGUI->NewImage("gui_kittycoin.png")\n            .Size({ 0, 0, 48, 48 })\n            .AddWidget(RootGUI->NewText()\n                .Position({ 1, 0, 5, 18 })\n                .Size({ 1, 1, 0, 0 })\n                .Update([](WText<ShopState>& Widget, const ShopState& State) {\n                    Widget.Text = GameManager::Only().Bag->Money;\n                    })\n                .Build())\n            .Build())\n        .Build())\n    .Build());\n
\n

The above code rendered the following, by the way:

\n

\"For

\n

It was a tedious process of writing code, compiling, validating the GUI, writing some more code, and compiling again. It took 40 hours to write the battle GUI and the main thing I learned was I did not want to do this again.

\n

\"40

\n

LGUI

\n

I didn't want to write GUIs in C++ anymore, so I created bindings in C++ to write GUIs in Lua instead (hence, LGUI). It was significantly faster, not just because the language itself was smoother to program in but also because with Lua I could finally do hot reloading. I'd make a change and see it reflected in-game within 50ms, no need to recompile.

\n

\n
-- Same as the C++ code above\nlocal window = GUI:createPanel({\n    parent = root,\n    position = {1, 0, 4, 0},\n    size = {0, 0, 275, 48},\n    borderSize = 1,\n    borderColor = Theme.FocusedFrameColor,\n    backgroundColor = {0, 0, 0, 255}\n})\nwindow.sprite = GUI:createPanel({\n    parent = window,\n    size = {0, 0, 48, 48},\n    texture = "gui_kittycoin.png"\n})\nwindow.sprite.text = GUI:createText({\n    parent = window.sprite,\n    position = {1, 0, 5, 18},\n    size = {1, 1, 0, 0},\n    text = GetBag().money\n})\n
\n

XGUI

\n

LGUI was a major step forward and made GUI programming a lot more tolerable but there were two main pain points that made me stop. The first was that it was still tedious: every element - even a text label - required ~6 lines of code. Less code than C++, but still code. And the second was the separation between the rendering logic (what elements to show, where) and the control logic (the player moved the mouse, now what?) was easy to blur, which resulted in unmaintainable spaghetti code.

\n

So this time I set out to build a full drag-and-drop WYSIWYG visual editor. I settled on XML for representing the view logic and Lua still for the control logic. The pattern I am following is MVC - Model-View-Controller, which is a pretty popular framework for managing complex GUIs. The XML defines a template, populated from a data model, with user-interactivity powered by a Lua controller.

\n

This was the result after vibe coding for a couple days:

\n

\n

There's still a bit to do, namely the C++ XML parser, but I'm very excited to try this out in Script Kitties.

\n", "url": "https://www.barelyconscious.games/devlog/gui-hell", "title": "I Hate GUI Programming", "summary": "Tolerable is about as good as it gets", "date_modified": "2026-06-18T15:30:00.000Z", "author": { "name": "Matt Schwartz", "url": "https://www.barelyconscious.games" } }, { "id": "https://www.barelyconscious.games/devlog/next-steps", "content_html": "

\"\"

\n

In 2012 (when the Mayans ended the world), I was in my dorm room thinking of a name for the hypothetical studio where I would publish all of my games. I had come to like "Barely Conscious Games" because it sort of had a double meaning to me. See, a couple years into college I really started paying attention to this foggy feeling in my mind that made it difficult to concentrate; it felt like I was barely conscious all the time. Turns out it was ADHD, but it took another decade for me to piece that mystery together.

\n

So anyway, the next 14 years were spent making games (mostly Stonequest) off and on in my spare time, between college, then internships, then a career. At some point, the career took over everything and I stopped considering myself someone who makes games.

\n

And then one day in spring 2024, everything changed.

\n

That one day in spring 2024 when everything changed

\n

It was the week after spring break, my niece and nephew went back to school, and I had taken an extra week off work to do whatever I wanted. So I decided to do a two-day game jam. The theme was "technology & cats", and by the end of those two days, I actually had a playable game in the style of a very simple creature collector.

\n

\"Script\n\"Script\n\"Script

\n

(And it's still going! You can see the latest updates on Script Kitties here!)

\n

I learned a lot from this experience, technically speaking, but the main thing I learned was that I could do it. It had been years since I made anything meaningful and I thought I had lost the ability along the way - that corporate SWE had drained me of any passion. This bit of inspiration was the spark that ultimately led to me quitting my job after 8 years.

\n
\n

What's Next?

\n

At my last job, there was this thing called a DFAD, or a date-for-a-date. If someone asked when you were going to be done with something, you could instead say "I don't know, ask me again next week" and that was a perfectly valid thing to say.

\n

\"Not

\n

Sometimes a DFAD would turn into a DFADFAD (date-for-a-date-for-a-date). Hypothetically, this can be repeated forever, or until they finally stop asking. In practice, you really only get max 2 or 3 before your manager asks you why they're being asked why you're not giving a date. So now you have two different people bugging you about this thing. The way I solved this was with a roadmap: a glorious spreadsheet filled with dates and action items.

\n

Now, the punchline - I'm giving you a DFAD for making the roadmap: June 18. Give me a week and I'll have a roadmap for you.

\n

In the meantime, here's basically where we're headed:

\n

The Road to Next Fest

\n

4 days from now, Steam Next Fest is starting, which is a great and terrifying opportunity for an indie developer to showcase their game, get some visibility, and gather feedback from players. A successful Next Fest can really put you on the map, but a bad demo - or worse, one that doesn't work - would be a significant setback. There's a whole lot left to do in Script Kitties and 4 days isn't a lot of time.

\n

I'm gonna be honest buds, it ain't lookin good. It's not gonna happen in 4 days.

\n

Alright, so 2026 is out of the question, what about 2027? Theoretically, Steam will still exist and if they continue hosting Next Fest, then that means I have about 369 days to write the story, hire an artist, build out a steam page, and test the heck out of it to make sure it doesn't crash.

\n

That's doable, right?

\n", "url": "https://www.barelyconscious.games/devlog/next-steps", "title": "new BarelyConsciousGames()", "summary": "14 years later", "date_modified": "2026-06-11T15:30:00.000Z", "author": { "name": "Matt Schwartz", "url": "https://www.barelyconscious.games" } }, { "id": "https://www.barelyconscious.games/devlog/script-kitties-retrospective", "content_html": "

\"\"

\n

What do people who have nothing to say write about? Lorem ipsum springs to mind, but\nthat's hardly worth your time to read let alone my time to copy-paste. Let's start with\nintroductions and see where that gets us.

\n

Among other things, I'm the sole developer of Script Kitties, the action strategy\ncreature collector with deep turn-based combat. Script Kitties started in March 2024, when\nI decided to kick off a 2-day game jam with everyone I knew. Only one person showed up, but\nother people might have if I'd told them about it.

\n

This is how it turned out:

\n

\"The

\n

Completing what I set out to do initially, I decided to turn it into something actually worth playing. Mostly, I was just enjoying programming again but after a few months, I started seeing a real game. I expanded existing systems, like rendering sprites flush with color, and added party-based combat to make things a bit more interesting.

\n

\"Party-based

\n

The world was originally randomly generated across seven biomes.

\n

\"Randomly

\n

It turned out okay, and it was a lot of fun to implement, but I knew it would be difficult to\nget right and chose to pivot to a hand-crafted world that felt more connected.

\n

\"Dialog

\n

More to come.

\n", "url": "https://www.barelyconscious.games/devlog/script-kitties-retrospective", "title": "Script Kitties: A Brief Retrospective", "summary": "How it started and how it's goin", "date_modified": "2025-07-19T15:30:00.000Z", "author": { "name": "Matt Schwartz", "url": "https://www.barelyconscious.games" } } ] }