New year, and a new resolve to blog more! So let’s get in to it! Scripting Over the Christmas break I spent a huge chunk of time working on Shibboleth. Majority of that time was spent take a passing interest in a LISP-like programming language called Janet. I integrated it into the engine to the point where it was 99% of the way done, but ended up abandoning it. The main reason being is that the language was clearly not designed to be embedded in an environment that wasn’t purely statically linked.

I don’t post enough about the work I’ve been doing on Shibboleth. I don’t have a lot of visual progress to show, but I am making a lot of very good progress. And I should get into the habit of writing down the work I’m doing. Reflection Unification In the past, enum reflection had it’s own global data structure that was different from everything else. Everything else has a Reflection <T> structure, whereas enums had a EnumReflection<T> structure.

Once again, it has been several months since I’ve posted anything. I’ve decided it would be beneficial to keep a development log of what I’m working on. So, here it goes. The two main things I have been working on are re-writing the reflection system and how I handle engine modules. My goal is that when writing modules to extend the engine, I’d like as little boilerplate code as possible when hooking up the DLLs.

I feel like I haven’t said anything particularly useful in a while, so I’m going to go over the architectural design and flow of my work-in-progress game engine, Shibboleth. Application Layer Our journey begins at what I call the Application Layer, which is nothing more than what the executable the end-user runs actually does, which isn’t much. To start, let me explain the expected folder structure the executable assumes. <root folder> |- App64.

Hello all! Today I’m writing another technical post about how message broadcasting is done in Gaff/Shibboleth. The high level idea isn’t very complicated: Listeners are registered as either functions, member functions, or functors. When a listener registers themselves, they are returned a “receipt”. When this receipt is released, it will automatically unregister the listener. While this adds some extra memory usage from having to store all these receipts, the end user no longer needs to remember to unregister manually!