Enjon: 2D Isometric Roguelike Game Engine, C++ / OpenGL DevLog

Dev-logging my process of building an engine in C++ and OpenGL for the purposes of eventually making a hand-drawn 2D Isometric Rogulike game.
If you have any comments or questions, drop 'em below. Like and subscribe!

[@andrej8875]

I have a feeling this is going to be recommended to everyone soon

[@thestickerqc]

It just did for me

[@Doomsdayparade]

Maybe

[@sdfsdfs13]

I felt like I wanted to play it just by looking at the thumbnail, that is a good sign.

[@NeilRoy]

For the path finding. When you're checking your path using A* on diagonals, I would check for blocked corners. For example, if you're checking the X+1, Y+1 diagonal, I would first check to see if either X+1,Y or X,Y+1 are blocked first. if so, that do not consider the diagonal move at all. Later on it will instead automatically check the horizontal path or vertical path instead to properly go around that corner. The problem right now is you're A* is finding a diagonal path THROUGH a corner that your enemies will then get stuck because the path is saying they can move in that direction, but there is a corner blocking their movement. Checking for those horizontal and vertical blocks before you consider a diagonal will fix that so the path properly goes around the corner instead of through it. There's also another faster path finding I was reading about called "Jump Point Search" which is like A* only optimized to be much faster, it ignores many points that A* checks that are simply not necessary. I quite like it and will probably give it a shot implementing it myself. Your work looks good anyhow. I love your idea of using normal maps, this could give a stronger illusion of 3D as well as adding an appearance of more detail. Especially if you plan to have more dynamic lighting.

[@johnjackson9767]

Thanks for the kind words and suggestions, N. Roy. It's been a while since this implementation was up and I've done quite a few revisions to most of the engine that I plan on sharing soon. Jump Point Search is certainly one of the revisions I hope to be making to the pathfinding so that the path scheduler can make quicker decisions and return them to the AI more efficiently. I've completely reworked the rendering system so now everything runs through a deferred renderer, with a forward pass for transparency eventually planned. So that means that all of my quads for sprites accept normals maps, emissive, roughness and metallic maps for PBR as well as diffuse. They are also all set up for shadow mapping as well, so they can cast and receive dynamic shadows. :)

[@NeilRoy]

Wow, sounds really nice! I look forward to seeing it.

[@johnjackson9767]

N. Roy I posted a small update today covering some of the new rendering tech, actually.

[@joshgordon7299]

Hopefully soon I can program this good too

[@IshakHeor]

I am starting studying engine programmig too, and I am loving it, so hyped to be an engine dev one day tho

[@hiderr6805]

I would really like to ask some questions about lighting.. Is it organized as another frame buffer that is being multiied with world afterwords? Also... What about the shadow? Is it a texture or is it calculated based on some factors real time? Thank u for that great dev log!

[@johnjackson9767]

The lighting is a very simple - just a screen space brightness ring around certain elements of interesting. So in this case, the player. The shadow was just a dummy texture placed.

[@hiderr6805]

@@johnjackson9767 thank you for the reply!

[@shwappler]

Just stumbled upon your channel and i have to say i'm impressed with the work. I have a lot of questions but i'm just going to narrow it down. 1) Where did you learn all of this stuff from? 2)How do you write and manage all of your classes inside the game? Did you only apply basic programming principles like SOLID? Or just wrote whatever you thought and saw worked best? Trial and error for me is painfully slow as i have to redesign classes. Do i need to build like a blueprint or something good enough so my game won't break when making a minor change? And how can i tell it's gonna work for most of the part? 3)How are the collisions handled? What do you compute and how do you stop those characters from moving in that particular direction? I'm having trouble with this as my character manages to get through walls. I'm building a 2d tiled game on android and i'm trying to collide a circle and a square. Having an input thread conflicting with a collision thread on the vector that moves my char (which gets me back to question 2). Do i stop the x or y coordinates from increasing or decreasing or do i keep trying to mess with the movement vector or something completely different?

[@johnjackson9767]

Thanks for watching. I'll try to address them as best I can in a YT comment. 1). KZbin/LearnOpengl.com when starting out. After I got a job as an engine dev, I got more exposed to "standard" engine/game development practices and techniques. I still work as an engine dev (not in game development), so most of my game engine dev work is solo stuff that I figure out as I go. 2). It's been a while since I've worked on this (all of my attention has moved to my c99 game framework that I've been making videos about recently). But the code base used a form of ECS to manage all of its data. The only programming "principles" I believe in these days are "get it working, clean up if necessary, optimize it later if you need to". Everything else tends to muddy the waters and gets you bogged down in conforming to "standards" that only confuse junior devs. 3). Collisions for this are done a uniform, 2D spatial grid. The rendering is isometric, but all coordinates were transformed into cartesian space to make the collisions easier to calculate. Nothing is threaded in this implementation, so there wasn't a need to arrange the data in a "thread-safe" manner. I recommend keeping everything single threaded for as long as you can (or if you're going to thread, then go "wide" rather than "long", so you can still code in a linear fashion). 4). Hopefully that answers some of your questions. If you want a more in depth convo, join the discord channel linked in the video. I'm on there everyday answering questions like this.

[@OptimusVlad]

How much experience creating a game engines, or working in the games industry, did you have when you embarked on creating this engine?

[@johnjackson9767]

This engine originally started as a way to familiarize myself with OpenGL and games development, so I had no experience in industry. About a year after I started it, I was able to get hired as an engine generalist for an indie studio, and this engine was a large reason why ( in spite of the poor condition it was in at the time ).

[@rearden3820]

looks awesome

[@DavidDolynny]

very good

[@banama1758]

its hard to find good devblogs on youtube so really excited about this one ! but i was wondering who is doing the art for this game ?

[@johnjackson9767]

Thanks! I'm doing all the art, programming, and music (when I finally get to that point).

[@nazymko]

You rock! Go on!

[@johnjackson9767]

Thanks!

[@Kombi-1]

Great!

[@oreonengine9444]

great work

[@johnjackson9767]

Thanks!

[@repogamesstudio2366]

that shadow

[@johnjackson9767]

Best thing about the video, obviously.

[@wesofx8148]

Very nice!

[@Kanerade]

Can i just ask, how long did this take to make? I'd like to make a game engine similar to this in c++ and opengl, but i don't have any experience in opengl.

[@johnjackson9767]

This was about a year into learning OpenGL and other various topics (like simple pathfinding, spatial partitioning, etc.). If you're just starting out, which is sounds like you are, I'd suggest going to LearnOpengl.com for some good, simple to follow examples on a lot of topics. You could also jump into my discord channel and ask me or anyone else questions there as well.

[@Kanerade]

@@johnjackson9767ok, thanks. yeah, I joined the discord channel yesterday.

[@purpasmart_4831]

I'm creating a game that is a tile based 2d top down Roguelike game, I have been slowly working it since late 2015, however I'm stuck on creating the opengl renderer, Im using C and opengl, using glfw and glew,. Since im using C i made my own gl math library which does the same thing as the glm library. i just need something that puts a bunch of quads on the screen for each sprite in which i can assign a texture to it, currently stuck on the boilerplate code, so im currently just got a triangle and a quad displayed with some colors using opengl 3.3

[@johnjackson9767]

Purpasmart _ Jump in the discord channel and I or someone else can help.

[@purpasmart_4831]

@@johnjackson9767 Ok, Thanks! Will go check it out!

[@HalfLife2Beta]

hey can u share the source? is there free movement or is it only tile based?

[@johnjackson9767]

The source is drastically different from what it was, but it was all a very naive tile-based approach that used A*.

[@JamesStaud]

It's great what you can build when you have nothing useful to do at work. lol

[@johnjackson9767]

Ha, what're you talking about? Setting up countless amounts of Linux builds was super useful... :D

[@JamesStaud]

Don't forget those Windows instances too! haha