Little curious how Blogger deals with an entry without a title. Hrm. Anyway felt inspired to try to do more regular updates, maybe it'll make me feel a little more accomplished, we'll see. Will be great if I can do these daily.
Today rolled the actor code into a legacy folder for the engine as work begins on the new ECS solution. Thought I'd had a good design in my mind, but having not written that down anywhere, was somewhat lost, and so a little bit of thinking to do.
Figured switching to ECS makes more sense to me in a
language such as C, as we don't have the luxury of inheritance there as a
language paradigm. Typically though I dislike ECS in an object-oriented environment, as I prefer the simplicity without (totally get the arguable elegance and simplicity of ECS in other aspects however.)
Currently entity holds a descriptor alongside list of components. Collection of callbacks are provided into component that run logic. Not sure how and where to best handle these callbacks right now, and how the communication between them should work.
Outlined a few basic components for starters; transformation, model and brain. In the case of the game, brain needs sensors and thus I currently suspect sensors would be another component. Ideally the brain could have just one or multiple sensors, which could be sensors of different types (sight, sound).
Flopped around considering proper client-side input API. Seems daft engine doesn't have this. Right now input is just piped all over the place, and really not keen on how actors currently check for input as the console and menu can't tell it they're pulling input. Also got me thinking about mouse-look as it's still not something supported, but due to the way camera works right now it's pretty awkward to introduce a generic handler for that.
We dooo have a global camera? Want to avoid toggle states or states in general for camera though if I can help it (was considering, fps state etc.) Right now camera gets attached to an actor and then the actor just deals with that logic for as long as that camera is attached to it. Suspecting though that something like mouse-look will end up perhaps becoming handled by a component. It all seems wrong or gross though.
Was looking to use models from Outcast as a placeholder recently, as the models look really nice. Took a look at the format, reversed it as far as basic geom, thought it was all easy, though it looks like I got the faces wrong... Lost motivation to continue with that - Hei supports Outcast's package format now at least. Have fun? Did also consider how much effort it'd be to create modding tools for Outcast; too much work right now, plus no free or open-source solution for compressing data back into pk format (i.e. implode). Bleh.
Teeny bits of work on assembler for engine scripting language. Plan is assembler first, virtual machine second and then everything else on top. Language doesn't yet have a name (internally called YScript and YinScript, but that sucks), but it currently is inspired by PL/M, PL/I and C (though leaning more towards C as it evolves.)
Oh, prototyped methods for sorting 3D environment for prototype. Yes. Wasn't happy with solutions though; absolutely suck with Blender, and did dabble with the idea of converting Quake maps (something I'd worked on in the past) - geometry isn't optimal from latter solution. Been tempted to fork Quake tools and modify qbsp to generate geometry in the way we need from the map, just until tooling for engine is completed. Not sure on effort involved though, so don't know if I should bother. Not a real problem until ECS is functional.