That's incredible game engine architecture!
HTML-код
- Опубликовано: 5 фев 2025
- Ali Motisi from Out of the Bit Studio, discusses their latest game Full Void, written from scratch using their own custom game engine in C programming language!
Check out Full Void on Steam!
store.steampow...
Out Of The Bit Studio Website:
www.outofthebi...
Twitter: / outofthebit
Instagram: / outofthebit
Game Engineering Podcast
Show links: podcasters.spo...
Spotify: open.spotify.c...
Apple Podcasts: podcasts.apple...
RUclips: / @gameengineeringpodcast
RSS: anchor.fm/s/dd...
Ali’s passion and knowledge was a pleasure to listen to. Great interview!
Sounds like they made a lot of great choices for a small studio. I wish them well with Full Void!
They’re developing their next game now: Nanuka: Secret of the Shattering Moon
Nice to see others doing the crazy thing of developing their own game engine.
When the world crumbles, this is the man you want to stay on your team.
This game looks beautiful.
This game is beautiful! You should give it a try, it’s a one long evening experience! :)
Sounds like they should release their games for the Amiga as well.
I have noticed two things that I don't like with todays typical way to make games are, #1 using game engine which make it easy to make games but with the hidden technological debt (including fully knowing everything in and out), and #2 is for instance with C++ is growing and changing, again just like with game engines it also hides the technological debt due to increasing complexity. So with C you are mostly free of technological debt and so you are have more freedom to how things should evolve both in terms of game and game engine. There is one thing I would like C to have and it is having a namespace capability so that you could compartmentalize code into modules, the only why I know how to handle this is to add module name into the function name and variable names, it gets messy quickly (very long names). If anyone have an advice for me how to deal with this please comment here.
You can introduce C++ fairly incrementally, and write it mostly like C. For each standard library or just basic C++ thing that you add, you can then look up each thing and what it does and what it's hidden costs are. Take Vector for example, if you have an array of unknown size, that only allocates whenever your window resizes or you change levels or something, then vector makes your life just a bit easier, but you don't want to use it everywhere. Virtual functions are another example. There are points where you might actually want to use one and be okay with the vtable lookup. But you can introduce these things slowly and over time.
If you decide to use every feature all at once, then yeah, it's too big and too much. I'm pretty sure this is basically Casey Muratori's approach. C but with a couple of the most useful and least costly C++ things.
The main problem with the way games are made today is a profound lack of risk-tolerance. You can't let programmers build their own engine because if it doesn't work, it'll cost too much and delay the game. Nobody ever got fired for picking Unreal. You can't let artists create something unique and interesting or designers create a new game mechanic (or heaven forbid let a PROGRAMMER come up with one). You gotta pick something that's proven in the market. Nobody ever got fired for a shooter with micro-transactions. "Nobody ever got fired for x" is the default way of making decisions when you're an employee with a mortgage risking someone elses money. But an awful lotta junior and mid-level people might have got laid off because of exactly those "safe" decisions.
I can relate with not wanting to fight the engine. I know that fighting the engine is actually a super rare thing to happen, and that even when I do there will always be a way around it to do what I want, but it's like I have OCD for this one small thing. I can't stand it at all.
Also, I hate OOP as well. Not because I have any real criticism of it, the `class` keyword just confuses me because I am very dumb.
It sounds like you've just recently started your programming journey. Don't "hate" anything you don't know. Start by learning it, and with some experience you will be able to assess the positive and negative aspects of a given programming concept. `class`es are ubiquitous and in order to advance (either in OOP, FP, procedural or w/e) you'll need to learn them and the 'abstraction' concept, which they are used for
In all things, do it out of love. For example: Going to church because you love God and other fellow human beings (and not because you hate atheists).
OOP et al are tools. You will have to try and decide for yourselves whether such and such works well with a problem domain. Making an application is one thing. Collaboration on the code base is yet another level.
Cheers,