Ask HN: Game development for non-game developers

[abanayev]

I started my software career as a kid, building side-scrollers and platformers for desktop and then graduating to iOS. Back then, there was no Unity or Cocos2d and open-source engines were hard to come by.

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.

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

[ChristopherDrum]

Celeste and Slipways both started life as small indie projects in the Pico-8 development environment. Personally, I find it much easier to get my head around gaming ideas in that system because everything is constrained. There aren't a million APIs to learn. The artwork is restricted to 128x128 pixels and 16 colors. Sound is similarly limited in 8-bit-esque ways. There is a kind of freedom in the system's restrictions that is hard to articulate, and its great for doing "sketches" (so to speak). If an idea you tinker with in Pico-8 feels like something you want to expand, then maybe move on to the more "robust" engines. As @zzo38computer said, "it depends on what kind of game you will want to make." If, by any chance, you purchased the Racial Bundle from itch.io last year, then you have a license to Pico-8. It isn't free, but it's super cheap and supports a great indie developer, and comes with a huge amount of community support.

[cableshaft]

Pico-8 is fun to play with, and I do recommend giving it a try, I half-ported one of my games to it (some day I'll get around to finishing and releasing it).

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.

[zzo38computer]

I think that it depend what game you will want to make. Often, the older systems will work just as well (or sometimes maybe even better); sometimes the newer ones do, and not always the same one. Not all games will need camera angles, although if you are doing 3D graphics then camera angles and lighting will probably be important. Not all games use multiplayer either. Although it is true that they are probably more common in game development. Some game engines are specific for some kind of game, and other are more general. Sometimes using a plain programming language is good, and sometimes the use of a VM code is good.

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

[mikro]

I am a non-game developer, and I have been looking into this as well for 3D games.

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!

[ED_Radish]

Game Maker studio (it sounds like a joke I know) is a pretty solid engine if you're working in 2D.

[abanayev]

The original versions of Game Maker were how I got into computer programming, many years ago :) It taught me about these magical things called arguments/parameters, and 'steps' (run loops), and objects. The first game I ever made was a Mario clone but you were an ant who stomped on other bugs in a garden, and I made it with Game Maker.

[Auracle]

Yep, at least depending on the type of game you’d like to make. If it’s something complex it’s probably not the best choice, but that shouldn’t be your first game anyways.

[verdverm]

I'd recommend Unity because it has good support for both 3d and mobile. Many great tutorials are on YouTube

Difficult things are lighting and multiuser networking. Cameras and input are not so hard anymore.

[JoeyBananas]

Godot Engine if you don't want to deal with a foul-smelling EULA

[ChristopherDrum]

I've recently started learning Godot Engine and am having a great time with it. It is so lightweight and simple to jump into. I find its interface very intuitive and as someone just tinkering around for fun, it doesn't demand a huge investment of my free time to learn it. GDScript is more than sufficient for me. As someone who typically does Pico-8 stuff for fun, the Python/Lua-esque syntax of GDScript gets the job done.

[dnh44]

A friend of mine is building a framework for Unity that allows for easy multiplayer. I haven’t tried it because I don’t work on games but it seems like a cool idea.

https://gameplumbers.com/