Seven Types of Game Devs And The Games They Make
The Computer Science Student
The computer science student had to write a game for class in the fourth semester. The game must demonstrate OOP design and programming concepts, and solid grasp of C++.
This game is written not to be fun to play, but to demonstrate your skill to the professors - or to their poor assistants who have to read the code and grade the accompanying term paper. The core loop of the game is usually quite simple, but there are many loosely connected mechanics in there that barely don’t really fit. For example, whatever the core gameplay is, there could be birds in the sky doing some kind of AI swarm behaviour, there could be physics-enabled rocks on the floor, there could be a complicated level and unit editor with a custom XML-based format, and all kinds of weird shaders and particle effects.
And with all this tech infrastructure and OOP, there are just two types of enemies. That’s just barely enough to show you understand how inheritance works in C++.
The core gameplay is usually bad. Un-ergonomic controls, unresponsive game feel, flashy yet impractical 3D GUI widgets make it hard to play - but not actually difficult to beat, just unpleasant. The colours are washed-out, and everything moves a bit too slow. There is no overarching design, the moment-to-moment gameplay is not engaging, and the goal feels like an afterthought.
But that’s ok. It is to be expected. The professors are CS professors. They (or rather their assistants) don’t grade the game based on whether the units are balanced, whether the graphics are legible, or whether the game is any fun at all. They grade on understanding and correctly applying what you learned in class, documentation, integration of third-party libraries or given base code, and correct implementation of an algorithm based on a textbook.
The CS student usually writes a tower defense game, a platformer, or a SHMUP. After writing two or three games like this, he usually graduates without ever having gotten better at game design.
The After-Hours Developer
The after hours programmer has a day job doing backend business logic stuff for a B2B company you never heard of.
This kind of game is a labour of love.Screenshots might not look impressive at first glance. There is a lot going on, and the graphics look a bit wonky. But this game is not written to demonstrate mastery of programming techniques and ability to integrate third-party content, tools and libraries. This game was made, and continues to be developed, because it is fun to program and to design.
There is a clear core loop, and it is fun and engaging. The graphics are simple and functional, but some of them are still placeholder art. This game will never be finished, thus there will always be place-holders as long as the code gets ahead of the art. There is no XML or cloud-based savegame in there just because that is the kind of thing would look impressive in a list of features.
More than features, this games focuses on content and little flourishes. This game has dozens of skills, enemies, weapons, crafting recipes, biomes, and quests. NPCs and enemies interact with each other. There is a day-night cycle and a progression system.
While the CS student game is about showing off as many tech/code features as possible, this kind of programmer game is about showing off content and game design elements and having fun adding all this stuff to the game.
This game will be finished when the dev gets bored with adding new stuff. Only then, he’ll plan to add a beginning and an ending to the game within the next six months, and go over the art to make it look coherent. The six months turn into two years.
The after-hours developer often makes RPGs, metroidvanias, or rogue-like games. These genres have a set of core mechanics (e.g. combat, loot, experience, jumping) and opportunity for a bunch of mechanics built around the core (e.g. pets, crafting, conversation trees, quest-giving NPCs, achievements, shops/trading, inventory management, collecting trinkets, skill trees, or combo attacks).
The First-Time Game Jammer
The first-time game jammer wants to make his first game for an upcoming game jam. He knows many languages, but he does a lot of machine learning with torch7 for his day job, so he has decided to use LÖVE2D or pico-8 to make a simple game.
This guy has no training in digital art, game design, or game feel. But the he has a working knowledge of high-school maths, physics, and logic. So he can write his own physics engine, but doesn’t know about animation or cartoon physics. He doesn’t waste time writing a physics engine though. He just puts graphics on the screen. These graphics are abstract and drawn in mspaint. The numbers behind everything are in plain sight. Actions are either triggered by clicking on extradiegetic buttons or by bumping into things.
The resulting game is often not very kinetic or action-oriented. In this case, it often has a modal/stateful UI, or a turn-based economy. If it is action-oriented, it could be a simple platformer based around one core mechanic and not many variations on it. Maybe it’s a novel twist on Pong or Tetris.
The first-time game jammer successfully finished his first game jam by already knowing how to program in Lua, copying a proven game genre and not bothering to learn any new tools during the limited jamming time. Instead, he wrote the code to create every level by hand, in separate .lua files, using GNU EMACS.
The Solo Graphic Designer
The graphic designer has a skill set and approach opposite to those of the two programmers described above. He is about as good at writing code as the programmer is at drawing images in mspaint. The graphic designer knows all about the principles of animation, but has no idea how to code a simple loop to simulate how a tennis ball falls down and bounces off walls or the ground. He used to work in a team with coders, but this time he wants to make his own game based on his own creative vision.
The graphic designer knows all about animation tools, 3D modelling, composition. He has a graphic tablet and he can draw. He knows all about light and shade and gestalt psychology, but he can’t write a shader to save his life.
Naturally, the graphic designer plays to his strengths and uses a game engine with an IDE and a visual level editor, like Unity3D, Construct, or GameMaker.
The graphic designer makes a successful game by doing the opposite of what the coder does, because he does it well. The screenshots look good, and his game gets shared on Twitter. He struggles writing the code to aim a projectile at the cursor in a twin-stick shooter, but we live in a world of Asset Stores and StackOverflow.
The resulting game is a genre-mixing thingy full of set pieces, cut scenes, and visual-novel-style conversations. The actual gameplay is walking around and finding keys for locks, but it’s cleverly recontextualised with a #deep theme and boy does it look pretty.
The Engine Coder
The engine coder is like the CS student on steroids. He has nothing to prove. He knows his C++. He lives in a shack in Alaska, and pushes code to GitHub over a satellite connection. He also knows his Lua, C#, Python, and Haskell. The engine coder writes a physics engine, particle system, dialogue engine, planning-based mob AI, savegame system, a network layer and GUI widget library.
He has written five simple demos for the engine: A first-person walking simulator, a third-person platformer, a very pretty glowing orb swarm shader thingy, a non-interactive simulation of a flock of sheep grazing and a pack of wolves occasionally coming in to cull the herd with advanced predator AI, and a game where you fly a spaceship through space.
Somebody comments in the forums that it’s hard to even write Pong or Tetris in the engine. The Engine Coder is more concerned with optimising batched rendering and automatically switching LoD in the BSP tree so you can land on planets in space without loading screens.
The Overeager Schoolboy
The schoolboy has an idea for a game. He saves his money to buy Game Maker (or RPG Maker) and tells his all friends about his amazing idea. Then he makes a post about it on tumblr. Then he makes a sideblog about the game and posts there too, tagged #game development.
Unfortunately, the schoolboy is 15, and while he is talented, he doesn’t really know how to program or draw. He’s good at math, and he can draw with a pencil. Unfortunately, he wants to learn digital art, level design, and programming all in one go. He already knows all the characters for his game, and he writes posts about each of them individually, with pencilled concept art and flavourful lore.
Even more unfortunately, our schoolboy is hazy on how big the game is actually going to be, and what core mechanic the game should be based around.
After designing sprite sheets and portraits for ten characters you could add to your party, plus the Big Bad End Boss, he realises that he has no idea how to get there, or how to make the first level. He starts over with another set of tools and engine, but he doesn’t limit his scope.
In an overdramatic post two months later, he apologises to the people who were excited to play the game when it’s done. A week later he deletes the tumblr. He never releases a playable demo. He never gets constructive feedback from game developers.
The Game Designer’s Game Designer
The game designer’s game designer is not exactly a household name, but he has done this for a while. While you have never heard of him, the people who made the games you like have. All your favourite games journalists also have. Through this connection, many concepts have trickled down into the games you play and the way your friends talk to you about games they like.
The game designer’s game designer has been going at this for a while. When he started, there was no way to learn game design, so he probably studied maths, psychology, computer science, industrial design, or music theory.
The games fall outside of genres, and not just in the sense of mixing two genres together. They are sometimes outside of established genres, or they are clearly inside the tradition of RTS, rogue-likes or clicker games, but they feel like something completely new.
The games of the game designer’s game designer are sometimes released for free, out of the blue, and sometimes commissioned for museums and multimedia art festivals. Some of them are about philosophy, but they don’t merely mention philosophical concepts, or use them to prop up a game mechanic (cloning and transporters, anyone?). They explore concepts like “the shortness of life” or “capitalism” or “being one with the world” or “unfriendly AI” through game mechanics.
But they also explore gameplay tropes like “inventory management“ or “unidentified magic items“ or “unit pathfinding“.
Sometimes bursts of multiple games are released within weeks, after years of radio silence. Should you ever meet the game designer’s game designer, you tell him that you got a lot out of the textbook he wrote, but you feel guilty that you never played one of his games. So you lie and tell him you did.
