I'm doing my best to make my design goals a reality during EngJam 2023, the inaugural jam for game engine development.

I'm participating in the jam, as well as trying to "run the jam". There are only six participants, none of which have made a single community post since the start of the jam. That's OK; I didn't really "market" the jam, so it's somewhat surprising anybody found me at all. Regardless, I reached out to a ton of people for mentorship interviews. There are now 4 posted, and I have 3 more. So it looks like I will have more interviewees than jam participants.

My entry is McRogueFace, the game engine I was already working on, and going to work on with or without EngJam. I spent the first half of the jam working on a user interface element refactor (which went very well) and refactoring the C++ - Python API interface (which went very not well).

Here's what the engine looks like on Wednesday morning of the last week of the jam:

The new UIFrame should be able to handle arbitrarily nested UI elements... IF I can convey that conveniently into Python.

It's looked exactly this way since about last Tuesday; the real changes (and problems) have been under the hood.

I originally wrote a toy example for exposing a simple C++ class (which could just as well be a C-style struct: truly some dead simple data). It didn't work when ported into McRogueFace for a few reasons.

Firstly, I inherited some errors from ChatGPT. In my demo example, I added the PyTypeObject (defined in C++) to the module via PyModule_AddObject. This worked in the tiny example program, but it took me about 2 or 3 precious jam hours to debug that I should really be using PyModule_AddType.

Secondly, plain-old data is not a sufficient example when interacting with SFML data types. sf::RectangleShape employs multiple inheritance, so that it can be implemented as a special case of the more general convex polygon code. I don't need any of that behavior, as I'm sticking strictly to axis-aligned rectangles... But using SFML's classes to store the shapes would make rendering code in McRogueface's UI section very tidy. However, I was not able to get Python to reliably initialize complex C++ objects with tp_alloc. As a workaround, I've decided to store a bunch of floats and sf::Colors on McRogueFace's UI objects, and assemble them into SFML geometry every frame, at render time. I don't love that solution. But I'm going to leave it alone for now, and come back for performance improvements if and only if they're needed later on. I only envision having low-dozens of UI elements to render, and I'm generally tuning the game for just 24/30 FPS anyway.

"Sprint 2" was basically canceled: I missed both weekend streams and my coding time was actually less than my estimated lowest amount.

The Monday stream was also canceled, as I really needed the time to quietly tinker. I ended up streaming 40 minutes of sucking at Undertale, just for fun.

It's time to crank up the energy, though: I am off of work today (Wednesday the 30th) through the end of the jam (Sunday September 3rd). According to my schedule estimate, half to two-thirds of my coding hours are yet to come, so I'm still hopeful to have a decent tech demo at the end.

Complicating factor: hurricane Idalia just made landfall a few hundred miles north by northwest of me. We're well out of the path of the worst of it but loss of power is a possibility even with the wimpy, not-quite-tropical-storm-force rain bands we're going to get here in Brevard county. Hopefully there won't be impacts other than additional coffee for rainy day coziness.

Refactoring my goals for the rest jam here:

• Same bugfixes (didn't resolve a single one during sprint 1/"2".) Some of these bugfixes would be better served by just waiting for refactoring their relevant parts, though.
• Finish up my Python experiments, which will serve as templates for the rest of the API changes.
• Expose the Sprite and Caption classes inside the UI - hooray, we'll be at feature parity with the 7DRL/LGJ2023 demos, without sucky Python code!
• Refactor Entities, with the goals to pass them between grids, follow the player, and demo decisionmaking in Python.
• Upgrade the Python version to 3.11.5; document the procedure so I can hop on the 3.12 train ASAP. (subinterpreters for grids to simulate simultaneously...?!)
• Deployment on Windows and Linux, test the redistributable stuff for EngJam submission.
• Stretch goal: Python components, so I can implement Items, Equipment, Melee Combat and Ranged/Spell Combat without recompiling in C++.

If I make it that far, I'll commit to writing up McRogueFace documentation in advance of "r/RoguelikeDev does the complete Roguelike Tutorial" 2024.

That's it, that's the update. I'd have made this a YT video, but I think this is a ton faster, and I definitely have a lot to do.