Bitty Engine: An itty bitty game engine
paladin-t.github.io
paladin-t.github.io
If you want to know about the really small indie ones that are less for actual use and more for just "I want to make a game engine" I would check out the various gamedev Discord and Reddit channels. There's always people showing off their work.
Most of the people who follow this advice will never ship anything. Stop worrying and do what you want. It's okay to reinvent the wheel if you want to learn how to make a wheel, or if you just find it fun.
(But remember, if you want to ship fast, or at all, usually better stay with the common wheels and sizes)
Not sure I agree. I have always done both.
Ostensibly I am writing a game but not using someone's engine. And then my own "engine" comes out of the effort.
Then I write a second game and pull over the rendering-sound-etc-code from the first game. This "engine" gets further refined as a result of being pressed into service for the new game.
Often it improves with each iteration and I move the newer version back to older games and refactor them as required.
No, 343 Industries, you don't need your own custom engine. Just use Unreal.
If you want to check out my project there's a link in my bio.
I'm doing an engine as side project too that I've just accepted will never be finished and it's only for fun :)
/r/TranceEngine
> [ ] Do sound :'D
Why bother with sound? Likely a dev would just pull in SDL_Mixer for game sound. Get on with the transparency. ;-)
I'm not quite sure what that should look like, but in particular making physical puzzles driven by say an STM32 chip could be cool. Especially if you can have it change the rules of the game once you've solved one puzzle.
Anyway, teeny tiny game engines brings that whole line of thinking back up for me.
I'm glad that PICO-8 exists, which is kinda exactly that. Except that it's not targeting any actual hardware (it's an imaginary retro-system), but it ticks all the other boxes.
Would be interesting to see what you can do in a physical space - your STM32 example still needs some kind of output attached to it, but with a 3D Printer and some other cheap components, you can add whatever I/O you want.
And I really do mean a hot second, because one boy showed up with one, another couple had one within days, and by the end of the week the school had banned them. As, I'm sure, did most every other school in the country. Now I can play audiobooks on my watch, but no games to speak of.
I wonder if one could fit the active parts of a entire game inside an X3D CPU's 96MB of L3.
Think of the performance!
How does this compare to that, besides the obviously nicer cost?
That seems more of an intentionally self-imposed limit that something that happens naturally in any way.
This thing though is in C++ which does all the dynamic allocation you want. Nobody uses 256 color video modes anymore. The limits are all completely artificial.
They're not even particularly good limits because there was console hardware that had say, 4096 colors, or per-sprite palettes which doesn't quite match PC hardware in capabilities.
The main Lua interpreter by PUC-Rio is among the fastest bytecode interpreters for a popular scripting language. Very efficient C code.
Wizard programmer Mike Pall then came along and wrote an even faster Lua bytecode interpreter in assembly language. And added JIT for even faster performance of hot functions.
1. It's super easy to embed in an existing code base
2. The language itself is simple and easy to learn
3. It has native coroutines, which allows game devs to write code without a spider web of callbacks
4. For what it does, it is fastFor example:
https://www.lua.org/manual/5.4/manual.html#lua_pushfstring
and:
https://www.lua.org/manual/5.4/manual.html#lua_next
It’s also amazingly semantically simple and dynamic, almost like a Lisp; even though it doesn’t have classes, typelevel programming is pretty straightforward.
It also allows you to easily write and distribute native modules (as shared objects) without needing integration code.
It is also insanely portable.
With this, you can run JIT-compiled Lua code at speeds comparable to V8 (the NodeJS runtime), and almost as good as the Java VM (depending on the workload, YMMV). LuaJIT also includes a foreign function interface (FFI) for even closer integration with native code, which makes it almost trivial to use native libraries from Lua.
Essentially, this makes it easy to move logic to lower/higher levels of the stack when/if you need it: There's the three layers that are increasingly more difficult to use but faster (Lua -> FFI -> C/C++), and you can directly use gamedev-oriented C++ or even graphics APIs like WebGPU from Lua, without crippling performance or writing tons of glue code.
Note that I've worked with Lua for many years and I'm definitely biased. I've also worked with JavaScript/TypeScript-based engines, where my favorite is BabylonJS (it's great, but JS/browsers really aren't...). So if you don't want to learn Lua/C++ I can recommend looking into BabylonJS as a starting point - it will probably be easier to get something going thanks to the browser APIs.
Godot does it, and it's an awesome alternative to Android Studio.
EDIT: although it supports WASM, and I'm curious how well does WASM works on mobile...
And WASM by itself works quite well by now, even on older devices, but not really on stock browsers. The question is more, how will be the whole experience of an autocompiled wasm project with UI? This is hard to get right and debug, if not right.