Yes, I missed Tuesday again. Oh well!

I've continued working on Yin, though lately more-so on the engine than the editor.

For some reason I'd totally forgotten to mention but a couple of weeks ago I had converted the Peach's Castle from Super Mario 64 to Yin's level format to try and push things a little. Fortunately it had already been converted to Obj by someone else, so credits to them for doing the difficult part.

Because Yin is being designed to handle any arbritary geometry for it's levels, I wrote a plugin for Blender a few months back that I can use to quickly export geometry for use in the engine.

It was generally cool to see in Yin itself, but obviously not something I can package with the engine as a demo level. Regardless I've dropped some screenshots below.

Textures are excluded due to laziness.

The other blue figure you see in the level is another "player" object, though at the moment the first players input is just piped to them - so moving forward moves all other player objects forward as well. That said it's incredibly useful for testing object vs object collisions and object vs world collisions too.

Earlier this week I ended up whipping up the following level instead. Literally just created for testing purposes, but at least something I can ship with the engine. It also demonstrates normal map support, which is relatively new to the engine.

While fixing some issues with the rendering that I discovered today on my laptop, I took the time to also update the GLSL pre-processor I wrote to allow for include directives - this gave me a good opportunity to move duplicate code into shared files which could then just be included into the other shaders.

I'd looked into this a while back for another project but decided to postpone it because I thought I'd have to throw out the existing code for it to be possible. Turned out after looking again today that everything to make it possible was already there - derp.

I'm also aware there's an OpenGL extension that apparently supports this functionality now, but writing my own pre-processor seemed to be the more portable route.

The console has seen a number of improvements as well, including auto-completion (I don't recall if I mentioned it in the last blog post?) Probably more importantly however, it's given me an opportunity to make the general structure of the engine a little more sane as I no longer need to necessarily depend on keyboard shortcuts to trigger debug functionality.

The engine also features a scheduler which I was using to handle animations for the console opening and closing originally, but that's since been dropped - though I still plan on using the scheduler for other things as well.

A question which I'm sure will arrise at some stage is probably, why? Why not just use an existing engine?

I'd probably put down the following as the major ones...

• It's a great learning experience! And everything I do here serves other projects I'm involved in such as OpenHoW and anything I might do in the future
  
• I now have an engine I know inside and out that I can use for game jams etc.
• Most modern engines I've dealt with do too much for what I want, or are fiddly/slow to use

There were originally more points in that list, but eh, I'll save those.

So what's next? 

I still need to make more progress on the editor. There has been progress since last time but far from anything interesting or useful - so this is now a big goal for me. It's one of the biggest roadblocks towards creating more interesting worlds and getting the world format more solidified.

There's been a start on a networking implementation but I need to rethink how actors are currently implemented.

Had some thoughts about the audio system but not too much progress yet. This will probably be split into it's own module.

I'm also still trying to decide what model formats to support. Right now I'm leaning towards IQM but I've heard mixed things about it in the past.

A little longer-term, I'm waiting for a game jam to kind of align with things and my plan is to make some small game that I can use to flesh out more of the engine.

In the very long-term, I've been dabbling with writing out a scripting language and virtual machine - with these I'd love to make the engine lean more into being a platform for creating things or creating your own small games, but that's more of a pipe dream right now.

Not much else to cover really today. For my 2D Warlock game, I've only really done a little bit more sprite-work and general thinking about the design.

I've got a long way to go at improving my sprite work 😓