In this article, I explain the difference between a game designer and a programmer, and why you need need at least one person who specializes in both to help you build your game.
If you’ve been working in game development for a length of time, you’ve probably heard these terms “game designer” or “game programmer”. (Or maybe you’ve come across of the more umbrella term, “game developer”.) But is there an actual difference between a game designer and programmer, and if so, what are those differences?
In very simple terms, game programming makes the game work, while game design makes the game fun.
Now, let’s have a more in-depth look at both professions.
Roles of Game Design
This profession involves the creative process of deciding what the game will be about. The designer is responsible for coming up with the game’s general idea, what type of game it will be, and who the game is for (think target market). The game’s design also includes what each screen will look like, how any levels are built, and the setting/environment/story.
You can think of the game designer as the glue, binding all other technical aspects of the game together to create one gaming experience that player will enjoy playing.
The designer creates the “flow” of the game. The flow of the game could be illustrated using the following chart, and might and look something like:
As you can see, the designer decides what happens during each stage of the game. Of course, you could delve deeper into any of these boxes, especially if your game is large. You might have even heard of a game design document, which goes into heavy detail on how the game will work. Everyone on the team should be aware of this, though the designer, programmer, and likely artist will be using this the most.
In addition to the programmer, the designer works with team member in other professions like the artist, writer (for games with story), audio engineer (music and/or sound effects), and producer (there could be other members as well). Eventually, the design specs will need to be relayed to the programmer so he/she knows what the game should do at every stage.
The designer is responsible for determine how the game will be monetized. They’d be work more on the marketing side, and what strategies will be used (in-app purchases, one-time app purchase, subscriptions, ads, etc.) The decided strategies will be relayed back to the programmer to implement.
Some other tasks of the designer can include:
- Come up with game ideas that are fun and engaging.
- Decide the genre of the game. What kind of game is it? Puzzle, platformer, shooter, RPG, cards? Is it a single-player or multiplayer? Of course, it gets more specific than that, but that’s the general idea.
- Decide what the main objective of the game is. What will the player spend the most time doing, and is this a fun activity? Bonus points if it’s addictive! 👍🏾
- Craft a player experience. What should the player feel or experience while playing the game?
- Understand what the players/market wants.
- Come up with the game’s narrative, plot and characters, for example, if the game is an RPG. The designer can work closely with story writers for this.
- Decides how the game should look (this is NOT the artist’s responsibility, unless the artist is also the designer, but the artists can of course assist).
- Ensure the challenge of the game is balanced (not too easy or hard, doesn’t get too hard too quickly, or stay too easy for too long).
- Decide how many levels the game has, and what each level looks like.
- Maintain open communication with other team members
- Decide how the game “flows”. For example, when this button is pressed, what should it do? (See the flowchart above/) It sounds trivial, but do not leave this up to your programmer. Often, the programmer’s interpretation will not be the same as the designer’s.
- Decide what each screen looks like, for example, menus, intro/outro screens, where the player’s health is located, which fonts to use.
- Decide what the game sounds like. When a button is pressed, does it play a “click” sound? If so, what? Does the game use BGM (background music)? If so, use music appropriate for whatever player experience the game aims to create.
Tips for designers working with programmers
- Simple games can get away with just a designer, and a programmer. Graphics and audio can be purchased or free resources can be found online.
- But do not expect your programmer to build a fun game, or to come up with the immersive elements themselves! In my experience, programmers make lousy designers, as their games are usually not very fun. Sure, they can put together lots of gameplay mechanics, but will the game keep the players’ interests? Probably not. Also, the designer will need to break down steps to the other team members, especially your programmer (and artist, if applicable) as to what each element of the game should do. They’re not mind readers. Sure, you may encounter a programmer who can also design a badass game, but again, that are the exception.
- Likewise, do not expect your programmer to provide art for the game. If your programmer does produce art (link to programmer art) on their own, especially if they are artistically challenged, it should be treated as temporary, until the final elements.
These are some roles and responsibilities of a game designer. These are not written in stone, as a designer may do more or less than these. Very (and I mean very) games may only need a few of these, and depending on the game’s genre, the designer may be involved with more or less tasks as well.
Next, let’s have a quick look at game programming.
Roles of Game Programming
This professions is very heavily vested in the technical side of building the game. The programmer is mostly involved in writing the code that makes the game work.
Of course, programming involves more than just the code. The programmer decides what software, and coding language would best be suited for the game. Once the programmer starts to build the game, he/she needs to determine how the game stores data, as well as which algorithms to write to best create the desired pieces of functionality.
A programmer will often use third-party coding packages (you might’ve heard of SDKs, APIs, libraries, kits, or frameworks). These packages can speed up development by a huge amount, as they prevent the programmer from having to re-invent the wheel by creating all the functionality provided by the package themselves. Phaser, for example, is a framework for developing web browser games in the browser using HTM5.
Building a game will require use of several pieces software, the main one being a coding editor. There a lots of them out there, depending on which coding environment the programmer is using. A popular one is Visual Studio Code. Other tools may require graphics editors, sound editors (NOT for building these assets, but for perhaps making minor adjustments).
As the game is being developed, the programmer will also spend a lot of time fixing bugs. Remember: the programmer’s main responsibility is to make the game work. Correctly.
Squashing bugs is a common task. Fixing them can take time, and the programmer may need to speak further with whomever discovered the bug first, if it wasn’t them. Unless it’s blatantly obvious what the bug is (9 times out of 10, it won’t), the first thing a programmer should do is to try and reproduce the bug. You can’t fix what you can’t see. Just like a referee in the Dubba-dubba-EE, you can’t call what you didn’t see.
Some other tasks for game programming are:
- Writing the code that implements the game’s functionality, such as:
- Loading and displaying graphics
- Loading and playing audio (music & sound effects)
- Moving characters or other game objects around on the screen around
- Collision/hit detections
- Handing user input (WASD movement keys, spacebar to fire, etc)
- Game logic (puzzles, math, physics, etc.)
- Making the UI (user interface) respond to player actions (button clicks, etc)
- AI (artificial intelligence, computer-controlled players, bots)
- Networking (for communication with servers, or if the game is multi-player)
- Using third-party code or libraries (APIs or SDKs) to help speed up the development process and/or make it easier.
- If on a team of other programmers, collaborating with them. Other programmers could specialize in niche areas of game development: gameplay, tools, front-end, back-end, network, etc.
- Have understanding of game engines and frameworks, and which ones work best on certain target platforms.
- Communicate with other members of the game dev team (designers, artists, producers)
- Write algorithms that solve problems.
- Determine the best data structures to use to store certain types of data.
- Fix errors that occur during development and testing, and even after the game has been produced.
- Being familiar with various coding software and/or IDEs (integrated development environments).
Tips for programmers working with designers:
- If you’re working with a designer, don’t expect them to know all the technical jargon like you do! They might know a little about coding or scripting, but don’t expect them to understand low-level concepts. You’ll need to learn how to communicate using layman’s terms. This is not meant to insult game designers, but in my experience, game programming, especially at the low level, is a relatively esoteric profession.
- If you’re unsure of how a specific piece of functionality should work, don’t be afraid to speak up and ask questions. You’ll have your hands full writing code, coming up with algorithms and data structures. You don’t have the time (nor the skill) to make a “fun” game, or to guess what your designer meant.
- If you’re not a designer (or an artist), be sure to speak up and say so. Early. Do not allow your team members to place this expectation on you.
- Programmers are generally socially awkward individuals. Asserting themselves, setting boundaries, saying “No”, and being the “nice guy” are challenges that they often struggle with. If this is you, you’ll need to start with working on yourself, your communication skills, and your own self image. You can check out Bulldog Mindset (started by John Sonmez). Below are a few of his videos for some insight, ESPECIALLY THE FIRST ONE:
In closing, just some things to keep in mind when working with designers and programmers, so you’ll have an idea what is expected (and not expected) from each profession.
Finally, I myself, am a programmer, and if you’re looking for one to help you build your next 2D, single-player, web browser game, then reach out to me! You can use the contact form, leave a comment in this article, or e-mail me directly at cartrell@gameplaycoder.com.
Subscribe to my e-mail list by using the form below. I spend a lot of spare time making games to add to my portfolio, and if you’d like to get behind-the-scenes updates to playable test builds as I make the games from start to finish, you’ll definitely want to sign up.
That’s it for this article! Thanks for reading, and until we meet again! 🙋🏾♂️
– C. out.