Yikes, it’s been over a year since the last post…
Anywho, for the time being SMAE is canceled, rip. It’s all good because I have a new game engine. The difference now is while I was documenting the progress of making SMAE, it ended up unfinished, and I haven’t really documented any progress of jIN, and it is nearing its “completion”.
jIN stands for (M)jir game enjIN, or enJIN, or JirJin, whatever it is. I’m gonna call it jIN. I’ll probably start writing it as jin so I don’t need to worry about capitalization, but it’s supposed to be called jIN. Some people might say this is framework, and not a game engine like Unity or Unreal, but I don’t really care about what it is really, it can be used to make games so it’s basically a game engine. Throughout my experiences of making a bunch of failed games by hand, I am now making the engine which will facilitate and speed up the process of making games “by hand”. Normally I would use SDL and C++ to get things working, but since I am smarter and better, it’s a bigger flex to not use SDL and code the thing in C. I’m starting to like C a lot and am currently using it as my “daily driver”. At first I was using GLFW as well to create a window, but I took at out too and am using direct platform libraries. Pain = gain. The only external libraries used now are OpenAL Soft for audio, lodepng for loading PNGs, cglm for gl stuff, and GLEW for gl function loading, but I am planning on removing that dependency as well. There’s no real point to writing all of these functionalities myself, but it is a flex, and in the case of GLEW, will actually reduce my compilation time on windows by a few seconds, lol.
On top of jin I also made JEL, an Entity Component System, to also help in making games. Now flecs is a 100% better ecs library, but I was surprised that I was able to make my own, it’s pretty cool. Mine lacks a lot of fancy functionality flecs has, but for my purposes, JEL will be good enough.
One of the big downsides to jin is it does not have its own physics engine. I personally think a game’s physics is dependent on the game itself, so it should be coded per game. I’ll probably eventually write some basic reusable physics modules for jin, but the main point is physics is something you would have to code yourself. I also think it’s one of the fun things to do, so it works out fine for jin. Since a lot of jin is going to be based around code it yourself, I can say now it’s almost finished. The main engine is done, but I am working a bit more on the core module, which handles the platform dependent code. The dialog boxes on X11 were harder to make compared to Windows, but at least it now has text on it.
I forgot to mention, since jin doesn’t have its own physics engine, it is not a 2D engine or a 3D engine ;), but there is a limit to how much math I am going to do myself so I’m only going to make 2D games with this (at least for the forseeable future). The source for jin is here and there is also a jin org here.
This post was pretty sporadic and I doubt it made much sense, I just wanted to get this out there so I just wrote what I was thinking as I wrote it. Hopefully the next one isn’t going to be out so late.
By the way, here is a gif of a demo of the engine (sadly gifs don’t have audio :( )
