Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Bitty Engine: An itty bitty game engine (paladin-t.github.io)
204 points by user8501 on Sept 13, 2023 | hide | past | favorite | 49 comments



I love these projects so much. It must be exhilarating to work on them and I'm very tempted to work on one myself as a side project/self learning experience.


There's hundreds or thousands of these indie game engines because, yes!, it is a lot of fun to write them. You'd learn a lot. The #1 tip though is that you're writing a game, or an engine, not both. So commit to doing one of those tasks. Usually you end up with a bunch of toy games and no steam left to want to really polish them into something complete.


> The #1 tip though is that you're writing a game, or an engine, not both.

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.


> The #1 tip though is that you're writing a game, or an engine, not both.

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.


While I agree with your sentiment: most people who DON’T follow the advice will propably not ship anything either as shipping is hard and rare in any case.


Or if you need a special wheel adopted to your needs. Because you were annoyed, that the common generic wheels blasted the way you drove them ... but also could not use a expensive high performance wheel, because they come in different sizes.

(But remember, if you want to ship fast, or at all, usually better stay with the common wheels and sizes)


I wish AAA game developers would listen to this advice. How many times has trying to write a new game engine for one IP ended with the game in development hell?

No, 343 Industries, you don't need your own custom engine. Just use Unreal.


Do you know of any that use JavaScript/typescript?


Here's the more popular dozen or so: https://github.com/collections/javascript-game-engines

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.


Yeah, I was thinking more terms of pico8 where you have the the editor which basically has everything included to make the game.


Phaser, as game engine, Pixi.js as a powerful render library (FRVR.com games were made formerly with Pixi.js). You can use Cocos Creator (not Cocos2D-x)


They’re more like frameworks or libraries. CC isn’t open source and the editor doesn’t work on Linux.



2d phaser (photonstorm) 3d babylonjs (microsoft)



Thanks! Looks promising.


Can confirm; they're real fun. I've got a 7-year side-project I still grind on in the form of a voxel engine. The trick is to start small and have realistic expectations. Your progress will be glacially slow at first, and that's okay. Eventually, if you keep grinding, you'll have something awesome that you love working on.

If you want to check out my project there's a link in my bio.


Can confirm the first two years will suck if you’re starting from scratch. Keep with it. By the 4th year you’ll be able to use all your abstractions to whip up prototypes over the weekend.


that's really cool!

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


I checked out your side-project.

> [ ] Do sound :'D

Why bother with sound? Likely a dev would just pull in SDL_Mixer for game sound. Get on with the transparency. ;-)


Mostly for the learning experience of writing an MP3 decoder and WAV mixer


That Lua debugger/editor with ImGui looks awesome! I’ve been wanting to do a similar project since Lua makes the API for creating breakpoints and stuff pretty easy. Styling ImGui to look like a normal code editor must have been no easy task though.


Wonder if they've got support for Debug Adapter Protocol? https://microsoft.github.io/debug-adapter-protocol/


The world learns lua one game at a time. All it needs is decent standardization comitee and a better packages/module system. Lua rocks



I have been contemplating lately if we need something like either the early days of computer games or the heyday of the Demo Scene, where people make amusements that are meant to run on embedded computers.

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.


> where people make amusements that are meant to run on embedded computers.

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.


When I was a child, there was a hot second where someone implemented PacMan on an LCD screen.

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.


> around 10MB with an empty project

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!


I played around with Construct2 a lot once upon a time, but never followed them to 3 because the product got a bit too expensive for me has a hobbyist.

How does this compare to that, besides the obviously nicer cost?


Why those limits? 256 colors? 1024x1024?

That seems more of an intentionally self-imposed limit that something that happens naturally in any way.


Popular to do stuff like that for "fantasy consoles" inspired by Pico8


Yeah, but it's just weird to me. Old architectures had logical limits. Most were because of things like memory addressing. Some were because you were writing C without any fancy modern helper libraries, and so if you wanted a hashtable you had to roll it yourself. A fixed size array for some things was just pragmatic. Graphics were 256 color because that was what the hardware supported.

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.


I was looking for this to surprise the missus with her own JRPG for her birthday. Thanks!


I'd really like this if it were actually entirely FOSS, and even more so if it didn't support "code and asset obfuscating".


Silly question from a web dev who has never written a line of Lua before (or delved into game development). What is it about the language that make it such a good fit for game development? Seems like every time I come across these engines, or read stuff about game development in general, Lua is always the language of choice. Can anyone explain it in a nutshell for me? Thanks


As others have mentioned, it's got a few things going for it.

    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 fast


One point that wasn't mentioned: It has a performance-oriented alternative implementation, called LuaJIT.

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.


My understanding is that it's simply historically fallen into the niche. Lua early on was relatively easy to embed in C codebases, making it a natural fit for scripting C (or C++) game engines and their editors. So many hugely popular game development tools are scripted with Lua at this point that it's somewhat breaking the mold to use anything that _isn't_ Lua in this domain.


Thanks that makes sense


I think it’s less that it’s particularly good for gamedev and more that it’s particularly easy to embed in an engine, and it’s faster than it has any right to be


> ... and it’s faster than it has any right to be

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.


Appreciate it!


I think it’s because Lua’s C API is very very closely coupled to its native keywords and standard library, so it’s not only built for trivial embedding but also for trivial / mechanical integration. Using the Lua API from within C or C++ is almost like the syntactic language isn’t even there and it’s just a convenient library.

For 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.


Probably since you can embed it in other languages quite trivially. For instance, in C after about a dozen lines of code you can now pass around data into Lua and back to C and thus give you access to a scripting language with little fuss. It’s also a fairly small and simple language, so adding it in won’t add much more to the overall footprint of the project.


Interesting, thanks!


I know I'm going to bring down the mood, but that kind of engine should support android as a priority.

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...


Well, the dev thinks different and this is what matters.

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.


IIRC the thing about supporting Android is that with game engines, that typically means working with the NDK which as far as I can tell is a bit of a bear to deal with relative to desktop platforms.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: