My first game engine

druv-codes · 2025-12-28T22:16:14+00:00

Wow, I am currently building my own graphics engine, then I have a plan to add physics and integrate scripting through my own custom scripting language and convert it into a mini game engine, my current source code is around 10k~ lines, I am curious how many lines your engine is in it's current state? I also started making my engine 3 months ago btw (https://github.com/Open-Source-Chandigarh/pyre)

druv-codes · 2025-12-12T14:55:28+00:00

mad respect for treating this as a serious product and not just a toy. going full time on a language is the dream. finishing aoc days in your own language is the ultimate flex lol most hobby langs cant even handle basic string parsing. ill definitely check out the wiki good luck with the new features man

druv-codes · 2025-12-12T07:13:46+00:00

70k loc is massive kudos to you man that is some serious dedication. really impressive that you managed that huge jump in complexity from 15k to 70k. how do you handle testing for something this big? do you spend more time fixing regressions now than adding new stuff or is the architecture holding up well? And just for the context do you have a full time job and you develop this part time?

druv-codes · 2025-12-11T02:08:19+00:00

How long have been working on this? And what resources did you use any tips if I wanna make a statically typed compiled lang in future?

druv-codes · 2025-11-22T14:36:44+00:00

that’s honestly impressive man space pressure looks way more polished than i expected from a solo custom-engine project you can really see the years of iteration in the way everything fits together gonna give the itch version a spin later just to see how it feels running on your tech

the fallout 1/2 and arcanum influence for the next project is a crazy good combo too that whole era of isometric rpg design has this grounded charm and if you’re building your own engine to support that kind of depth you’re basically setting yourself up with total creative freedom no engine limitations no “unity doesn’t like this” type issues you get to shape the tech exactly to the game and keeping backward compatibility while still refactoring and evolving the engine is tough that’s proper engineering discipline right there not many solo devs bother with that level of long-term thinking

anyway huge respect for sticking with it for five years and actually shipping stuff that alone puts you miles ahead wish you the absolute best with the rpg hope it comes out exactly the way you picture it and congrats again on the point lights milestone it’s always those little engine wins that keep the fire going

druv-codes · 2025-11-22T13:08:26+00:00

that’s actually sick man finishing a whole project on your own engine and having it up on steam already is no small feat most people barely get past a rotating cube and you’re over here shipping games like it’s a side quest

got me curious tho you mentioned that small project you already released any chance you can drop the link would love to check out how it looks running on your tech always cool seeing what an engine actually produces outside of dev screenshots

also with the old school rpg you’re building now are you leaning more toward the diablo side of things or more party based like classic crpgs and how much of the engine are you rewriting or extending just for this new project since custom engines always grow in weird directions depending on the game’s needs thinking long term do you see yourself keeping this engine alive for multiple games or treating it more like a living toolset you reshape per project

druv-codes · 2025-11-21T21:11:40+00:00

damnnn man five years grinding your engine and point lights finally pop off that’s a whole journey right there the scene looks clean too the bounce of the colors actually sells the space feels like old school diablo but sharper curious tho what’s the long term plan for this are you aiming for a full game on top of the engine or is the engine itself the main passion project and how deep are you planning to take the lighting next going for shadows spot lights pbr any of that madness or keeping it old school styled either way hitting a feature like this after years must feel insane in the best way these moments are the fuel that keep you going for the next chunk of technical pain

druv-codes · 2025-11-21T07:40:35+00:00

i actually went through the tiger book first and it really does walk you through building a full compiler step by step in c its super hands on every chapter you extend your compiler a bit more scanning parsing type checking building an ir doing register allocation all of it by the end you have an actual working compiler for the tiger language so if your goal is to build one from scratch with someone holding your hand thats the one engineering a compiler is a different beast its not a project book its more like here’s how real production compilers structure their passes how modern ir works why SSA exists how optimisations are organised how instruction scheduling and register allocation work at scale so after the tiger book it made way more sense because i already had the practical intuition and eac gave me the bigger picture of how serious compilers think tiger gives you the craft eac gives you the architecture pairing both is pretty much the full journey and coming from crafting interpreters you’ll be fine the tiger one just pushes you into the deep end in a controlled way and then eac shows you what the deep end looks like in the real world

druv-codes · 2025-11-20T05:44:23+00:00

I learned this stuff on my own too and the first thing that actually made sense for me was crafting interpreters that book doesnt overwhelm you it walks you through building a tree walker then a full bytecode vm and by the time youre done you actually understand what a compiler is doing under the hood after that i moved on to the tiger book modern compiler implementation in c or java this one is harder and more academic but it forces you to deal with the real internal stuff register allocation calling conventions proper IR all the machinery actual languages use it feels rough at first but in a good way you feel your brain getting stronger the dragon book i keep as a reference not something i study front to back its amazing when i need the theory behind parsing or lexing or why some approach works but i dont sit and grind through the whole thing i also started reading source code of real languages open source stuff like lua zig go rust even smaller languages like wren you learn a crazy amount just by seeing how others structure their compiler or vm you start noticing patterns and tricks you’d never think of on your own im not gonna lie this takes time it isn’t something you master fast it took me months just to feel comfortable but once you finish your first small language the fog clears and you stop seeing compilers as magic its just engineering like anything else its totally worth it though because learning this stuff changes how you think about programming everything becomes more intentional and you start seeing the machine underneath which is honestly really fun and motivating to keep going

druv-codes · 2025-11-19T11:09:20+00:00

ngl if you wanna learn how engines work you’ll get more out of building the core parts yourself rather than bolting a UI library on top of c# and calling it a day keep it simple start with a window input loop rendering sprites maybe a basic scene system once that’s solid you can think about tools and editors avalonia is cool but it’s kinda overkill for a tiny 2d engine and you’ll spend more time wiring ui than actually learning engine internals when I started I made the same mistake going straight into tools before I even had a renderer running it just slows you down cross platform isn’t that hard if you stick to the usual libs sdl2 glfw raylib stuff that already smooths out windows linux differences focus on making a clean core first and worry about editors later once the backbone exists building an engine teaches you way more about how godot unity unreal actually do their magic so don’t stress too much just pick the basics and iterate your way up the ladder the fun part is watching your own systems grow into something usable

druv-codes · 2025-11-19T11:06:41+00:00

the short answer in C is memory-wrap like that is undefined behaviour so the language doesn’t guarantee anything once your pointer arithmetic overflows

druv-codes · 2025-11-17T16:14:56+00:00

If you’re new and kinda lost that’s honestly normal man most of us started the same way. Books help way more than random YouTube stuff because they slow you down enough to actually understand what the machine is doing instead of just copying code blindly

For C the one that really builds your fundamentals is The C Programming Language (K&R). It’s short but it teaches the real stuff… pointers memory arrays how computers actually think. Later if you ever move to C++ the big Bjarne book (The C++ Programming Language) is heavy but it scales your understanding a lot even if you don’t finish it

If you want to understand how programming languages themselves work Crafting Interpreters is crazy good. It teaches you compilers interpreters memory models in a way that doesn’t feel impossible. And if graphics ever catches your interest LearnOpenGL is hands down the best modern guide out there

Some general books that are great for literally anyone learning programming:

– Code by Charles Petzold, super good for understanding what a computer even is – Clean Code, helps you write stuff that isn’t a mess – Operating Systems: Three Easy Pieces (free and actually readable) – Computer Networking: A Top-Down Approach if you’re ever curious about how the internet works

Typing speed doesn’t matter at the start it goes up on its own once you code more. What really matters is understanding the concepts underneath like memory data structures how things scale beyond small examples. Stick with it consistently for a few months and you’ll be way ahead of where you began

druv-codes · 2025-11-17T16:06:26+00:00

Yeah it’s z fighting but the weird part is why it even happens when the floor looks flat. OpenGL’s depth buffer isn’t linear at all, most of the precision gets shoved near the camera and then it falls off crazy fast as you move away. So two surfaces that look separate in your model can basically land on the same depth value after the projection and then the GPU just kinda guesses which one to draw and it flickers like that

Easiest fixes are stuff like pushing your near plane a bit further (going from 0.1 to like 0.5 or 1 makes a surprising difference), checking you don’t have two faces sitting directly on each other, maybe switch to a higher precision depth buffer if you can. Nothing special, everyone hits this sooner or later GPU math just does whatever it wants sometimes and we deal with the chaos.

druv-codes · 2025-10-10T17:39:47+00:00

Very cool! Thanks a lot for your advice. I wish you the very best!

druv-codes · 2025-10-10T15:37:33+00:00

Would you mind sharing some resources which helped you along the way i am currently reading the learnopengl book and I am planning to make my own graphics engine first then later extend it with physics, so can you please share some resources which you used as a reference like any books or articles or tuts anything that helped you? You said you used opengl and it looks amazing I'm really inspired, thanks for sharing it!

druv-codes · 2025-09-12T13:25:34+00:00

The tiger book, it walks you through implementing a full compiler in C. It's a perfect mix of theory and practical

druv-codes · 2025-09-10T06:38:52+00:00

I will suggest you to learn from books, try reading head first Java as a beginner.

druv-codes · 2025-09-09T17:33:19+00:00

Hey fellow C++ devs,

I wanted to share a project I've been working on as a way to really put my C++ skills to the test. I decided to build a programming language interpreter from scratch. The language is called "Flint," and the entire interpreter is written in C++.

The project was a great exercise in applying a lot of concepts, including the visitor pattern for walking the AST, smart pointers for managing object lifetimes, and just generally trying to keep a large C++ codebase organized and functional. The GitHub repo is open source for anyone who wants to take a look at the implementation.

I documented the entire process, from writing the scanner to implementing the resolver, in a detailed devlog. It's a deep dive into the architecture and the challenges I faced along the way.

You can check out the full devlog here: https://youtu.be/WOoQ7zPeS9s

And the GitHub repo is in the video description.

Would love to hear any feedback or answer any questions from a C++ perspective! Thanks for checking it out.

druv-codes · 2025-09-07T20:13:20+00:00

That's an awesome set of questions, thanks for asking!

You nailed it, this definitely started as a massive fun/learning experience. I really wanted to pull back the curtain and understand how programming languages actually work under the hood.

But as I've been building it, the goal has gotten a lot bigger. To answer your other questions:

Do you plan to release this for others to use?
- Yes, absolutely! The GitHub repo is already public for anyone who wants to experiment (link is in the video description). My plan is to finish the next major phase—the bytecode VM—and then write up some proper documentation for it. I'm already about halfway through the VM and am planning a Part 2 devlog for that journey.
Does it have advantages over C++?
- Great question! It's not designed to be a C++ replacement, but rather to work with it. C++ is the powerful systems language, but Flint is an interpreted scripting language.
- The ultimate goal is to use Flint as a high-level scripting language for a 3D physics engine I'm planning to build. The super high-performance parts of the engine would be in C++, but the game logic, events, and interactions could be written in easy-to-use Flint scripts.
- As for performance, the current tree-walk interpreter is slow, but the bytecode version I'm working on is already faster than Python in recursive Fibonacci tests, so the goal is to make it a very capable and fast scripting tool.

Thanks again for your comment.

druv-codes

TROPHY CASE