In essence mega-lights is ray tracing one shadow ray per pixel, then using some temporal de-noising to try and smooth away the noise. This is in contrast to how games traditionally calculate shadows, which is by rendering a shadow map from the point of view of each shadow casting light in the scene. For a small number of lights, the shadow map approach will be considerably faster. What mega-lights enables is effectively an unlimited number of shadow casting lights for a fixed cost (because it only ever traces a fixed number of rays per pixel), but at a much higher base performance cost, and with the potential for noisy artefacts caused by the denoising.
Yup, raylib is great. Sokol is another solid choice for the low level bits - that's what my engine is built with and it's excellent (at least for indie level games).
Absolutely agree! It's totally doable, but it does require some desire/ability to dig under the hood little.
I think a lot of people conflate the game engine with a game editor, and don't realise how simple an engine can be if it only contains the features needed for one game.
I've shipped several games with my home made engine, and it was the best technical decision I ever made! No more relying on someone else to fix bugs!
The editor is part of it but I think the complete lack of where to even begin structuring one's game code in absence of some kind of formalized scene graph is a huge part of it as well. Scene graph editors make seeing “what exists in the game world right now” very visually apparent and easy to understand: “well, there's this root Node, and within that there's these different Nodes, and some of them have child Nodes which represent…” and so on and so forth. I recently replied to someone on X [0] who was starting from the Raylib 2D platformer example and asked, earnestly, “so I have this constant array of five rectangles representing platforms… how do I go from this to ‘defining my game's world’”?
It's just data. In its most basic form, a game world can be represented as just arrays of instances of structs, and then you loop over those arrays and call a function on each element to simulate the “entity” that struct instance represents, and then again to render it onto the screen. Sure, you eventually might want to do something more complex than that if the need arises, but most people would be surprised at just how far you can go doing only the simplest possible thing.
It's definitely possible to do it - for me the key is to write the game and the engine together, and only implement the bare features you need. For the first game at least, the engine and the game are essentially the same thing. Also, forget about wiring an editor, just add debug functionality to the game.
Very cool - nice tutorial!
I've released a few games with my home made engine (most recently https://poki.com/en/g/blaze-drifter)
My best advice is only write enough engine to support the game you want to make. Also don't try and write an editor, but add debug/editor tools directly in the game. With each game you make, you can add one or two new features to the engine, and slowly build up the feature set to be able to make larger games.
I started with a simple on screen 'watch variable', so I can visually inspect values over time. I added simple click drag edit support so I can then edit a value too. Over time I've added a (very simple) console, a simple immediate mode debug UI, graphing for the watch variables, and a little track editor (with the debug UI). Again the key is to build only what you need and only when you need it. It sounds quite a lot when I write it down, but it's all super simple and only supports the barest features that I actually need.
Yeah, a depth prepass won't help you if you're vertex bound. It's most useful when you have high depth complexity and expensive fragment shaders (which to be fair is most games). It's also not usually required for a deferred renderer, but for forward+ it's normally a decent win.
Not the parent, but I also use sokol as the base for my engine. I've shipped 3 3d web games with it, and honestly it was the best technical decision I ever made! There's just so much to be said for owning all your dependencies (as far as possible, sokol is still a dependency but it's way more manageable than a 3rd party game engine)
Do you mind to share your games details? No judging, I promise :)
I just need examples from people like me and not AAA studios for motivation sake. I literally was called an idiot for not choosing Unity or Unreal, and was turned down for collaboration with non-tech people just for that. Game dev landscape is crazy these days.
It totally depends on the type of game you want to make, whether using an existing engine or rolling your own is the best option. This is one of the games I've made with my engine: https://poki.com/en/g/super-tunnel-rush
My one tip is only make enough of the engine to support the game you're writing, and write the game at the same time as the engine (don't think you need to finish the engine before you can start writing the game, that route doesn't work out well :)
