Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitty Engine: An itty bitty game engine

paladin-t.github.io

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Bitty Engine: An itty bitty game engine

#41

Post by ClassyJacket »

Waterluvian wrote: post #4
otachack wrote: post #3

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.

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.

Re: Bitty Engine: An itty bitty game engine

#43

Post by [deleted] »

40four wrote: post #19

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

[deleted]

Re: Bitty Engine: An itty bitty game engine

#44

Post by jwells89 »

jokoon wrote: post #27

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

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.

Re: Bitty Engine: An itty bitty game engine

#46

Post by muchwhales »

40four wrote: post #19

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

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.

Re: Bitty Engine: An itty bitty game engine

#47

Post by jerrre »

Buttons840 wrote: post #16
Waterluvian wrote: post #4

Earlier quoted context omitted.

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

Re: Bitty Engine: An itty bitty game engine

#50

Post by dale_glass »

pringk02 wrote: post #49
dale_glass wrote: post #48

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.

Post reply on HN