[istorical]

The first thing to wrap your head around is that game development is really a collection of multiple disciplines / subsystems / processes / arts that all come together for a single product.

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.

[zzo38computer]

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

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.

[abanayev]

Thanks for these insights!

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.

[istorical]

My biggest advice is to recognize that while one can learn a substantial amount of the basics of web development in 3-6 months, the same is less true for games. Because you could spend 3-6 months learning basic 3D modeling, or 3-6 months on the game programming part, or 3-6 months on game networking.

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.