One of the major hurdles to overcome (for me at least) is implementing a functioning animation system. Initially I used the learn OpenGl example to import DAE animation files. It worked. It worked only for the example. No matter how many export parameter changes nor testing other file formats did I get it to work for my own models. This was so disheartening that have ended up implementing my own 3d object file format that will and will not contain animation data. This way I have full control which is really what I am after anyway. So welcome to the computing world the .erlo file format. I would go into depth of the formatting of the file but I would rather keep it hidden for now. I have a working blender export script and updating the model loading logic to use it. These changes haven't been pushed since the animation data parsing is not complete but it should be done by the end of this week. I also will eventually make this a binary file format to allow for quicker load times and some obfuscation. A little insight on the file format is that the animations right now are an old school mesh per one bone weighting with the transformations being baked. I know this will make the file larger than necessary but it is simpler and makes more sense to me. Anyway, that's where I have been. Till next time.
On this happy Independence day, I want to relay all of the new changes and some of the philosphies that are leading the game. Here are some notes of what I added since the last update. Split screen has recieved some love in that the controllers are now drop-in-drop-out and that it works with the dynamic window updates such as toggling full screen. I have also included some UI updates to display the FPS, Coins (Per Player), Health, and Player Velocities. I almost forgot a big one, AN ENEMY has been added to the game. To throw some water on the fire however, the enemy only follows the player when they get too close and when it get's close enough drops the players health. This is a major jump because soon I should be able to prototype a full level with cooperative player elements and enemy combat. When implementing the enemy it opened up design questions for my entities. I have decided to try a modified ECS using std::function (I know... C++17) componenents where the GameObject class is all that is required and the Player/NPC classes are not needed. The major issue with this that I still need to figure out how to implement entity specify variables that can be modified by these entity components. This would save a lot of logic in ErlPhysics so that all physics operates on the same entity class. Either way that's the goal, I have been using my free time from coding to brainstorm how this would work and have yet to implement it. Now for the philosphies leading the game. I have been in contact for three month but still have yet to explain the reasoning behind the game. There are many games on the market but very few that capitalize on the couch cooperative experience (especially as of late). There are a few notable exception but none hit the sweet spot between pick up and play and replayability that is warrented for my needs. My wife and I are always looking for things to do together and besides watching movies/tv games have been a fun relaxing part of the end of the day. That was until we played all of them that fit our interests. I have set upon creating the perfect couch coop game for us and have been learning so much on the way about graphics programming that this warrented it's own devlog and website. I needed to spill this information out of my cranium and onto some forum. Well here we are. Next you will likely see player movement updates, two player cooperative elements, and updated enemy AI. On the side I have been doing some 3d art for the game so will likely see some improvements there as well.
Much has been added in the last five days. Enough to make me proud of the progress. At the start of the new 2025 repository the lighting has been severely neglected. I decided to remedy that in the last two days. Fixing the logic for reading and using the lights from the ERL map file was rather simple thanks to my early considerations for extensibility for render items. The engine now is primed for moving the direction light in realtime and saving it's location. Side note, for fun I updated the skybox to something that is inline with the game that is currently in progress (I think it looks very nice). On top of the lighting improvements, I have actually implemented a fully functioning material system for the default shader and also fixed some assimp buffoonery with reading textures, specular, diffuse, and shininess values. I now feel very comfortable reading wavefront obj files and their correlating mtl files. Maybe in the future I will implement my own obj parser. For right now though if it is not broke do not waste your valuable time 'Fixing' it. Along with this lighting changes, major improvements were made in the ErlPhysics department. After making some changes for character rotation I noticed some odd what looked like tunneling. Turns out my AABBs were not acting trully as AABB. I updated the code so that the AABB are not affected by rotations fixing the collision issues. However it's not acting like a dynamic AABB where the max and min points are being recalculated which will lead to misleading collision boxes. I plan on implementing a ellipsoid triangle collison algorithm so that there isn't odd collision boxes to contest with in the future. I believe I covered the major changes, so I will leave it there. Oh and since I mentioned lighting I know you're dying to see the changes. You're in luck I have attached a gif with the latest changes running in the engine.
Long time no see. Will keep this short and sweet. This will just be a procurement of progress over the last eight days. Also, SURPRISE!, I kept my promise of showing off with an attached gif. The in-game console and scripting was completed shortly after the last entry. A side-effect of implmenting the console is that I updated all of the key command structure entries to use std::functions so that they can be declared inline. This is a fantastic way to save from 'class-clutter' that is common with the command structure. Secondly I have made some quality of life improvements to the ingame map editor. I now am able to specify player start positions and save them to the map. This also led to a script fix in the map save that now saves the scripts associated to the objects themselves in the esf file rather than the dynamic instance id. There is also now right stick control for camera movements. This was achieved using spherical coordinates which is so much easier to follow than using cartesian. Anyway, enjoy the gif!
Steady progress with the engine has continued from since we've entered through this one-way communication. The goal as of today remains the same as the goal as since we last spoke, 'scripting'. After researching information on scripting and engine design I believe I have been using the term incorrectly. Scripting in my sense of the definition means that I will be able to modify entity behavior at runtime from a preordained list of possible code snippets I had created before hand. Scripting in the traditional was meant for non-technical people to make modifications to the game, usually in the different language, and requires it's compiliation to work. This to me seems wrong and a waste of time for what I want or need. I prefer my interpretation of scripting better. Anyway getting definition confusions out of the way, the progress of the scripting has gone well and currently now I am able to read and write scripts to the map save file on reload. When I envisioned this functionality I wanted to create something like cvars in that I can just specify an object in the map and add a script to it in a 'console'. I am currently in the progress of creating the gui for the console and the input handling for it. Writing a simple gui from scratch is no 'simple' task but will be well worth it in the future. In the past I have been using ImGUI for interacting with the engine at runtime for the simplicity. However, I find it to be tying my hands when it comes to making me ideal solution for a in-game console. Maybe in the future all of the debugging ui will be written by my own hand (what a beautiful thought). By the next entry the console will be done and I may even treat those reading with an gif of the functionality. Much more I would like to say but I fear of becoming too wordy for a single entry so this is where I will bid you adeu.
Today it dawned on me two things that I want in this engine, 'scripting' by using std::functions in a map, and a master texture for each level. I started work on the first part which did not require too much startup code. This is exciting news because this will allow me to enable/disable scripts and see it change before my eyes during runtime! I pushed changes that show the example code working but they will need to be more organized so that all the scripting functions are in a centralized place. In the example, I added to the game object class a map of actions where one of them is rotate and allows all the coins in the map to rotate on the fly. This was also a fun use of lambdas in C++ which is an odd thing to see. Now for the later of the game engine wants. I have seen examples of using a master texture to enable only one load from disk to parse the texture making the load time speed much faster (this will also help with lightmaps in the future). This can be done by manipulating the texture coordinates per object to point to pixels in the master texture's image file. Now, I have not messed with the textures and object loading in general since first implementing it so this will be a fun trip through memory lane. I will get to implementing this when I feel that scripting is in a good working order. Exciting things to come!
Over the last twenty four hours I have been thinking to myself what would I want this page to be. How should I populate this page with topics meaningful to me and also keep it interesting? I believe in the meantime while exploring the future of this page I will continue to fill this page with learned technical programming knowledge. Starting with issues I have been battling today with the small amount of work I have added to the engine. I pushed a commit today that implemented 'fully functional' split screen mechanic that allows two players to move AABBs around the map (In the future I will discuss the nail-biting process of rolling your own a physics system). In creating a split screen using Opengl you are required (at least with my current high level knowledge) to render the sceen twice using two glViewport commands and two different camera 'views' which in ErlEngine's case means between render passes switch the camera's position since the renderer take the view from the camera to do the whole rendering process (as it probably is the case for most engines). Luckily I have a decent laptop and the frame times for two render passes is still above 200 frames. With all this said, it has stil been stitched together and I need to implement a system to enable split-screen on the fly (this will require more research on my part). When I am able to accomplish split screen on the fly it will allow me to create a system that will dynamically check player distances and toggle split-screen when needed. After pushing the changes I started working on fixing the Engines runtime editor. After some previous camera changes the controls for the editor were broken (these growing pains of updating one part and breaking another is like a persistent cold sore). After fixing editor controls (Mouse/Keyboard) I added a long overdue and highly needed quality of life update. I DISPLAY THE OBJECT'S FILE NAME IN THE EDITOR AND NOT JUST THE DIRECTORY. Now, this may seem like a no-duh should have always been the file name but never underestimate the whack-a-mole programming logic of creating your own large repository and still wanting to see continued progress.
After fighting with cloud host I was finally able to get this website set up. I have owned this domain name on and off for about 10 years but I have never truly added a proper webpage to it. The website holds my namesake and will contain musings about my personal interest and current development projects. My Github page contains all of my current projects. The most important of the projects being the Erl Engine. I have been working on creating a game engine for the last 8 months using Opengl and C++. With no prior knowledge of game development, it has been a great source of growth in both my development skills and programming interest in general. Download and run it for yourself, but be warned it is a work in progress and is not by any means a complete project.