Timely. I am kind of old-school when it comes to game development and recently got into teaching my daughter maths and programming and art through it. It's been a lot of fun.
Buuuuuut.... the early stages of starting game development these days are, "What engine do you use?"
And honestly it can be a daunting choice. They're all quite large and have their own jargon and way of doing things. I can get through a "Hello, world!" tutorial in an afternoon but it'll take months before I get something useful to work and load my brain with all of the jargon to navigate the documentation and forums...
versus writing everything from scratch. It's a slower start but I have already learned a good programming language and can go from there. I don't end up with a black box of performance problems. Nor do I end up trying to shoe-horn my round game into a square peg. It's quite common going down this route to write your own data formats and tools as well: level editors, compilers, debuggers. And the productivity starts going up fast as you build momentum.
So I typically go a "libraries not frameworks" kind of approach.
Which seems to be entirely alien in the enterprise world. The common wisdom here is to never write your own tools. Always use what's on the shelf and get going as fast as possible. Yet I often end up in those tar pits where cloud costs overrun operating budgets and failures happen constantly without any built-in observability... I wonder why more teams don't build tools for themselves?
> Which seems to be entirely alien in the enterprise world.
There are a few reasons for this.
1) Enterprise is mostly staffed with mediocre programmers. That's not meant to disparage anyone. Even great engineers will produce mediocre work if the incentives are aligned that way.
2) Enterprise problems have more to do with people management than writing the fastest and most cutting edge software. Frameworks can get hundreds or thousands of engineers speaking the same language for writing the boring code (which is the majority of code).
3) Enterprise companies often already have an established business model that works. They often have market dominance in some area and it's okay if their software is a little slower/buggier/etc. Game industry is no different.
4) Enterprise companies often have enormous scope that smaller handmade tools can't always cover. For example your average homegrown UI framework probably won't have accessibility in mind from day one.
5) There is no way to judge the quality of homegrown tools until it's too late. Our industry (like any other) has very loud yet very dumb people who convince others that their way is best. They build up layers of awful tooling/architecture that needs to be rewritten down the road. Frameworks have at least some form of validation.
I used to believe the above was fixable. Now I know better and just stay away from big companies. Work is more fun and fulfilling that way :)
>"Our industry (like any other) has very loud yet very dumb people who convince others that their way is best."
This is so f..g true. Also clearly seen here as well - preaching that this way is bad and that way is the true one.
>"I used to believe the above was fixable. Now I know better and just stay away from big companies. Work is more fun and fulfilling that way"
Exactly what I did. After reaching top still somewhat technical position at the company I got so fed up and burned out that I quit. Went on my own and been this way ever since for some 20+ years.
> Exactly what I did. After reaching top still somewhat technical position at the company I got so fed up and burned out that I quit. Went on my own and been this way ever since for some 20+ years.
I'd love to hear more about your journey. What did going out on your own look like? What type of work do you do? How long did it find you to figure out the kind of work that satisfied you and paid the bills?
Well, by the time I quit I already had my own product in progress. Since I was paid quite well when I was employed I've saved enough to just finish the product very fast and little by little it had started bringing licensing fee. After 10 years the money coming in from that product mostly dried up but I've started another one by then. This one is doing ok even now. Also while I was employed (we were consulting shop) I've acquired a reputation as the guy who can deliver best solutions for a given constraints. So all along the way many companies who knew me because of my previous work kept offering me contracts to design and build products for them. I am very versatile guy who can do firmware for microcontrollers, enterprise grade backends, desktop multimedia / hw accelerated graphics, middleware etc. etc. Also proficient in electronics and mechanical design. This all helps me to be afloat. In my other life I was a scientist back in the former USSR.
So to summarize: I am a product guy. I design and create various products either for my own company or for clients. I did it all my life and I love it and the only thing that had changed over the time is that at some point I've become ISV and am my own boss. I am 60 now but (keeping my fingers crossed) my brain still feels and performs like I am 30 and also in great physical shape as I do not forget physical activities. There must be something in our family as my wife is also work from home / consultant for the last 15 years and so is my daughter for even longer.
As someone who started out in the game industry in 1990, I can say that being able to choose between competently-built game engines is a HUGE bonus.
At last count I'd written six (!!) game engines. Nothing huge; mostly "casual" games as the target. One of those engines ended up having over a hundred published games written for it, though, so at least in that case I got some decent traction.
And honestly? If at any of the times I was starting a game engine, I could have just sat down and focused on _writing the game_? I would have taken that option and not looked back.
You have to make a decision, when it comes down to it: Do you want to write a game? Or do you want to build a game engine?
Because writing a complete game engine can take 2-3 years all on its own. And yes, that's counting gluing together existing libraries. I never wrote, e.g., a PNG or JPG loader from scratch. The engine with 100+ games? I started work at PlayFirst and immediately started working on the game engine. Nearly six years later when I quit to work on my own games, I was _still_ adding features to the engine.
Games were certainly released before that; the first game I released was probably only six months in. But the game engine (Playground) wasn't very mature yet, and it wasn't until at least 2-3 years in that using the engine really had a robust set of features (including cross-platform support).
And if you're looking at creating a 3d game, and don't want to start with an engine? Well, it can be done, but again, if your time budget is three years, at least half that time will be working on parts and fixing bugs that a solid engine would have handled for you. If your time horizon is shorter, then expect even more of your time to be spent reinventing the wheel.
I believe, if you really want to understand how a game engine works, you need to try to build a game from scratch in your favorite programming language. It's a fun exercise and you really grow as a programmer. If you use an existing engine, you will never really need to know how to initialize a window for rendering, you never need to touch opengl/directx/vulkan/etc, you never create a rendering loop, a scene tree, implement a matrix library, create a basic physic engine or integrate a scripting language.
All those things are fun! I know it, because I spent about 8 years on and off tinkering on my own engine in my spare time when I was younger. And what can I show you after all those years? A fun tech demo maybe, but other than that, not a single finished game.
Game development is different nowadays. To stand out, you need to know about game design, concept art, color theory, texturing, tile-mapping, lighting, shaders, interface design, sound design, sprite animations or skeletal animations, networking... The list goes on and on. And then your game also needs to be fun!
If you go the route of implementing or integrating everything yourself, you will never reach the level of someone who knows an existing engine in-and-out. Today, if you want to create games, it's far more important to create as many games in a short time as possible. Just look at competitions like Ludum Dare to realize and appreciate how far even small game engines can help you to create a fully fledged game within 48 or 72 hours. It's crazy. This will improve your skills as a game designer far more than building your own engine.
> Buuuuuut.... the early stages of starting game development these days are, "What engine do you use?"
As someone who started from raw OpenGL and cobbling together various libraries (OpenAL, OpenIL, etc.), I think it's bad for pedagogy, but I love it for productivity. Just like React.js.
I think there's a huge advantage to not having to spend time writing code to glue together asset management to physics to animation to graphics to audio to AI and UI, etc., and also because scene graphs and entity/component systems are like game programming's equivalent to REST and MVC.
So once you know how to work with that stuff, jumping into an engine is a great way to get right to prototyping and skip all of the setup. But for building up the conceptual understanding... it's rough. It's just a totally alien way to think about programming if your background is classic frontend/backend.
> And honestly it can be a daunting choice. They're all quite large and have their own jargon and way of doing things. I can get through a "Hello, world!" tutorial in an afternoon but it'll take months before I get something useful to work and load my brain with all of the jargon to navigate the documentation and forums...
That's absolutely a problem, and I totally agree that it's exacerbated by starting from Unity as opposed to learning the component concepts individually. But that said, Unity genuinely saves me a ton of time, even if the result isn't as optimized. That goes double for VR, where the sheer conceptual load of designing/coding the interaction models makes doing it without an engine not really worth it.
> versus writing everything from scratch. It's a slower start but I have already learned a good programming language and can go from there. I don't end up with a black box of performance problems. Nor do I end up trying to shoe-horn my round game into a square peg. It's quite common going down this route to write your own data formats and tools as well: level editors, compilers, debuggers. And the productivity starts going up fast as you build momentum.
I think this is a difference of what you're trying to accomplish. An engine gets you off the ground much faster if you have trained on it because enough of the abstractions are common to most games that, for example, reusing a not 100% ideal graphics/physics/skeletal animation rigging/key framing/audio/collision detection system still saves you a lot of programming.
I'm intellectually interested in writing my own simplest-possible versions of game engines, but I have no idea where to get started. Do you have any tips or a book recommendation? How did you learn?
It's hard for me to recall how I learned because my first "game" I wrote was in '89 and I wasn't very old at the time.
Maybe check out https://www.youtube.com/watch?v=Ee3EtYb8d1o -- I've watched a fair bit of it and many folks agree it's thorough and interesting. If you don't know C already he has a decent introduction as well.
Maybe not the best place to learn C but it suits well enough for game development projects.
The nice thing I find with C is that bringing life back to older machines is definitely possible -- the homebrew scene for various old consoles is very much alive and well and there's probably a C compiler that targets it.
Buuuuuut.... the early stages of starting game development these days are, "What engine do you use?"
And honestly it can be a daunting choice. They're all quite large and have their own jargon and way of doing things. I can get through a "Hello, world!" tutorial in an afternoon but it'll take months before I get something useful to work and load my brain with all of the jargon to navigate the documentation and forums...
versus writing everything from scratch. It's a slower start but I have already learned a good programming language and can go from there. I don't end up with a black box of performance problems. Nor do I end up trying to shoe-horn my round game into a square peg. It's quite common going down this route to write your own data formats and tools as well: level editors, compilers, debuggers. And the productivity starts going up fast as you build momentum.
So I typically go a "libraries not frameworks" kind of approach.
Which seems to be entirely alien in the enterprise world. The common wisdom here is to never write your own tools. Always use what's on the shelf and get going as fast as possible. Yet I often end up in those tar pits where cloud costs overrun operating budgets and failures happen constantly without any built-in observability... I wonder why more teams don't build tools for themselves?
Is it not as uncommon as I think?