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.
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.
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 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.
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.
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?
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.
Readit News
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.
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.
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. ;-)
https://luarocks.org/ ?
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.
Deleted Comment