Making games as a single developer (pt. 1)

You can create a whole, entertaining, complete and polised game as a single developer. I mean games that are good enough that people who are not your friends or even know you will play them, and share them with their friends. This is my personal observations and opinions as someone who is not (and has no wish to be) a professional game developer, someone who is not a professional gamer or reviewer, someone who just find playing and creating games entertaining.

First off, what you've been told everywhere else, so I will keep it short; Adjust your expectations. You're not going to create Doom, if you're good, you can create wolfenstein as a single guy, but don't get your hopes up. If you want to create a 3d MMORPG (not a tech-demo, but an actual, finish product that people will like), this article is likely not for you.

Now that your expectations are low enough to be realistic, think about games through time, was space-invaders a complete, polished game ? Yes, it was, and it made someone filthy rich. Space-invaders is a technically, conceptually and graphically simple game, which runs on simple hardware, which creates consistency. Everything presented to the player is consistent with the players expectations, of the game, of the hardware, of the "system". This is important, and I'm not sure if anyone has stressed it before, but I will, because to me, an important parameter in what makes a game "finished" or "good" is a percieved (subjective) consistency between the game implementation and its engine. If you take an engine with UDK5 capabilities, throw in assets of Quake1 resolution/density/quality, and mix it with amazing shading and accurate physics, you get a freak. Maybe the concept in your game IS to be a freak (Voxelstein3D for example), then great, that's not the kind of game I'm talking about here, I think it's really cool, but in my opinion, it stays well within the realm of the tech-demo. Now, let's take the actual Quake1, you can think what you will about the visual graphics, but they are consistent, it feels like "this is what I'm going to get, this is my life now" it helps the player immerse themselves, to believe the environment. My opinion is that it looks "real" in a sense, because the fidelity and content are aligned and consistent with everything else within the game. It avoids such comments as "Oh! I know it's possible for ABC to happen right here! I've just done that before! Someone made the choice to disable that feature here, just so I have to play the game differently!" That's annoying as hell. The build games did not have real destructible environments, but they had movable ceilings and floors, and the level designer could trigger something that looked like environment destruction, it usually worked by inserting a few special sprites to tell the engine "Before activated, these floors should have full height" and then place a sprite looking like a crack in the wall, to hint the player "here's a place where you can destroy the environment". Consistent. Games like Red Faction, which did allow almost fully destructible environments, used different materials to hint to the player where the environment could be destroyed. This should sound a lot like game-design, and less about technical consistency, but they are conneceted, because the more feature-rich an engine you have available for your game, the more features you want to pick from, and, if you chose to use a feature once, you must keep it in mind for every single decision you're making in your entire game, something which even many AAA titles get wrong (and I know they're trying hard), but you're just one developer, you can't make AAA graphics and AAA physics and AAA everything. But the A's go together, if a game has AAA graphics, we, the players, expect AAA everything else too, and you can't deliver! So think hard about your choice of technology.

Depending on the type of developer you are, you may be more interested in graphics, or in level-design or in programming. Pick a genre that presents interesting challenges in the field you enjoy, but is more forgiving in the fields that are not your primary interest. A first person shooter may be one of the worst types of games to implement as a lone developer, so as someone who's only ever thought of making one, I'll give my opinion on where it can go wrong, and what could be done to make it go right. An FPS is heavy in programming, assets and level design. It can be pretty forgiving in story and puzzle (and by that, I mean that making interesting puzzles for an FPS can be pretty easy). If you chose 3D models over sprites, you're doomed, because, try modelling and rigging one 3D character, unless you're a savant, that's already a few days work, just drop it! Afterwards you'll spend half a life on character animation code, and then you'll be dead. I'd go with a low-resolution friendly technology for an fps, either a raycaster or a 3D engine with limitations in place to keep you from making something too technically inconsistent, like smoothed wall textures and sprites. Upon seeing a smoothed wall texture, the player will expect 3D models, and you're doomed. If you want to create and finish a FPS as a single developer, go lowres, no filtering and use sprites. This also helps a lot with the math if you're limited in that aspect (as I am), as 2D math is usually a bit easier to understand and implement (go write a raytracer if you want to practice 3D, but don't call it a game). Player expectations to raycasted games are usually easier to fulfill, because you can concentrate on the things they let you do well, like interesting puzzles, textures (lowres textures can look great, and they are easier to maken repeat in a nice way, and they are better okay!?). A raycasted game frees you from rigging character models, to do interesting and creative stuff with the story, weapons, design and gameplay, so go exploit that. Now you might ask, who's going to play a raycaster in 2016 ? Well, me for once, and while I'm definitely odd, I'm not the only one, and I'd rather play a packed and rich raycaster than a barren and incomplete fully 3D game. As for tools and tech, that's up to you, I think I'd personally (because 2016) implement a raycaster in the GLSL shading language, but other options are to use an existing engine, such as Build (which was opensourced iirc) or use a lot of dicipline with UDK or Unity. I know at least one studio is making a build game in 2016.

Next time (if I continue this), I will write about RTS games from the point of view of someone with a lot of opinions and no real experience to back them up.