Since then, I've been doing professional software development (first backend and now full stack) but never revisited game development.
In the time that has passed, games have obviously evolved a LOT, in terms of game engine sophistication and availability, types of games ("game metagame"?), and expectations of games. It seems that more indie game studios have appeared and done well.
My question is two-fold:
1. What is the state of the art for indie game development right now? If I wanted to make a game, what should I do, and what libraries or frameworks are absolutely standard?
2. What are common problems in game development that are not common in other verticals of software development? I'm imagining things like camera angles or multiplayer networking.
Sure making a website or app you have to consider frontend + backend, but with game development there are many parts that you have to spend time on (or at least make thoughtful decisions to de-prioritize). 3D modeling and shaders or 2D graphics and sprites, physics, game logic, sound, networking, serialization / persistence, character animations, story, particles / fx, lighting and post-processing, music...you can find all these different areas you may want or need to spend time with. For a AAA game there are entire teams and functions that spend years on just one chunk of this. Teams and budgets are more like movie budgets than app or website budgets for a reason. Sticking to 2D can help a lot. As can sticking to singleplayer. As can starting with a simple and well-trodden genre. To create Tetris you obviously don't need all of these, but it's easy to come up with an idea that seems achievable at first glance to a novice but quickly realize you underestimated the project even dramatically more than web or mobile app or desktop app developers often do because there are yet more components that take real hours of work with games.
RE: engines and technologies, you have to determine if you want to create a 2D or 3D game, if networking / multiplayer matters, what platform you are targeting, and a few other things before you choose an engine.
There are other considerations too, such as input. Also, not all games need all considerations, and sometimes you can use a library or VM code which does some of these things automatically. For example:
- Many games will not need a story; some games are more story-oriented, but some aren't and will work OK without.
- Fancy graphics are not needed for many games. At least in my opinion, I don't like it to waste the disk space and power of the computer. (I also dislike cutscenes.)
- Many games are a single player and don't need networking.
- If a VM such as Glulx is used, then save games, pagination, cross-platform, etc can be handled for you already.
- If an emulation of an older system such as NES/Famicom is used (such an emuluation is also a VM), then such things as networked multiplayer, save states, user-adjustable input/sound/zoom, cross-platform, etc, is already done for you. (See what I mention in the other comment about colours though)
- Libraries such as SDL can be used in cross-platform computer game development, and will handle input (keyboard, mouse, joystick), timing, sound, and display (including double buffering if enabled).
- Some game engines are designed to make specific kind of games, and have advantages and disadvantages. You do not necessarily need to use any existing game engine, but you can do so if it is applicable to the game that you are designing.
Analogy to movie production is spot on, I think. I suppose game dev is also different from other software/tech products because releasing continuous updates is harder. Also, players expect more from the first published version of a game: it shouldn't merely be playable (compare: early adopters could pay money for a SaaS MVP) but already polished, fun, engaging, well-designed. I've never worked on hardware products or products in heavily regulated areas, like health care, but I suppose the production cycle is just as tough.
So there are games you can make over 3-6 months that will give you a tiny foundation in a bunch of different areas, but it's just way easier to get a little taste of React and taste of working with a database and a taste of a backend framework and a taste of HTML+CSS over a few months than it is to get a taste of all these different parts of game dev. Or at least it felt that way to me. So easy to get sucked into the wormhole learning about just one aspect of game dev for months, or letting scope creep or an over-ambitious design distract you.
So even though everyone says to aim for the world's dumbest, smallest project first, and then everyone immediately ignores that advice, I still have to look at my own experiences and pain from that lesson and recommend doing so for you as well.
There are a lot of courses that take you through creating an entire small game and hold your hand through the process, and I would recommend doing one of those first. Whether its an Unreal or Unity or Godot thing or whatever. Because jumping in head first and learning what you need on the fly from google and youtube can be easier from a motivation POV but putting in the work to follow an entire course that teaches you how to make an entire game will give you a broader view and help you avoid getting bogged down writing shaders for 6 months. Ofc, if you want to just follow passion and get sucked in, then off to those types of rabbitholes you go.
But if you're coming from a web background you might have better luck with something like Phaser 3 and Typescript. You get to keep a lot of the same structure and toolset that you're likely used to in modern web development, while still able to make good looking 2D games (not just be limited to 8-bit looking games) that you can put online and send a link to friends so they can play and enjoy it.
For games I'm not putting on the web, my main framework of choice nowadays is Monogame. It's C#/.net based like Unity, but open source. It doesn't have quite as large of a community as Unity, but it's still in active development and some major indie games have been developed using it. It doesn't have a drag and drop editor like Unity, and I'm running into a few recent issues with 3D in other platforms (that look like they might be addressed in a development build already, I haven't dug too deep into it yet)
But the framework is battle-tested from the Microsoft XNA days and there's no proprietary editors with ugly messy scene code that doesn't merge well (at least from what I remember working in Unity a while back). I can just focus on the code.
But maybe not great starting off point. I still recommend taking a look at Phaser 3.
For example, if you write a game for NES/Famicom, then it is likely to run on many computers with many operating systems, likely supports user-definable key bindings, volume controls, possibly multiplayer by internet, you do not need to implement any of these things by yourself since it is already there. And, it will work on NES/Famicom, too. There is also less likely the user will have to worry about malware. (One problem with this is that the colours might be somewhat different in different emulators. I had once proposed a format to include the file with the RGB colours (which can safely be ignored, but if used might result in better colours) with the game, but doing so doesn't seem to be so common now.)
1. It seems the major game engines are Unreal (C++, many AAA titles) and Unity (C#, widely used). Godot is open source and uses a python-esque GDScript. There is also Roblox Studio (Lua) which is its own walled garden.
For multiplayer, you can use Unity and Unreal’s systems or Steam or you could try to roll your own with something like Agones.
For Assets, major tools are Blender and 3DS Max. You could also use tools like Shapr3D or MagicaVoxel. Or buy on sites like Turbosquid but the meshes/textures may not be organized well.
2. Reasoning about geometric transformations can be challenging. Also animations, character rigging, organizing assets, memory management, framerate performance.
All of this is in addition to game design, which is its own thing. Good luck!
Difficult things are lighting and multiuser networking. Cameras and input are not so hard anymore.
