Hey there,
I’ve rewritten this prologue of sorts several times now, because I initially wanted to introduce game design as a concept, but then I realized a table of contents would be helpful, and then some kind of brief explanation about the rename and rewrite was going to be needed- so this is hopefully the final version.
Anyways grab a penguin and some popcorn and uh yeah!
Table of Contents
Introduction … page 218
Core Principles … page 2837
Plot and Narrative … page 198
Planning … page 11
Rough Draft … page 32716
Prototyping and Playtesting … page 17
Game Structure … page 42
User Interface … page 99
Consistency … page 1001
Game Mechanics … page 1092
Systems of Design … page 832
Game Design Process … page 1
Conclusion … page 6
Introduction
What is Game Design?
Game design is the process and way of building your game. That includes the pre-production, update schedule, characters, style, rewards, user interface- everything in a game can be filed under this rather general term.
In a real life environment, a game designer would be just one person in a team with an artist, programmer, and so on, but usually you have to be all of those things yourself in Gimkit.
This guide is written to cover all of those aspects, with a focus on specific examples. At the end, we’ll go over the full game creation process.
But to start, going over the general concept of game design is probably a good idea.
Core Principles
These are a few things I’m going to lightly touch on, just to give you an idea of things to keep in mind while making a game, and then we’ll get into the planning stage of game design.
Gameplay Loops
This is by far the most interesting part of games, I think. Loops are these sets of actions a player is going to be doing repeatedly. For example, in a platformer map, the main loop is probably running and jumping. That’s the core loop. The secondary loop might be something a little deeper, like figuring out the lore of the game, or decoding a clue.
If you can actively think about designing rewarding, balanced, and challenging loops then that goes a long way. It’s sort of like, is the action of playing your game actually fun? Otherwise no one will want to play it, regardless of how interesting it is.
Challenge and Reward
In a game, if it isn’t challenging, no one will want to play it either. Players are motivated to complete your game because it’s a challenge and takes effort. So to keep them engaged, challenges should get harder throughout the game, and should also have some kind of reward.
There are actually two different kinds of rewards, intrinsic and extrinsic. An intrinsic reward is just the joy of playing the game itself. An extrinsic reward is some kind of achievement or upgrade. You can depend on the extrinsic ones, because you control that. But also remember that the game itself is supposed to be fun, and completing a difficult level in it of itself is a reward that the player is attached to because they earned it.
Player Choice
No one wants to play a game that feels like they’re being forced along. If players don’t have choice, or at least the illusion of choice, then they’ll be bored. Bottom line is to make sure you include enough options for the player to make a decision that it feels interesting.
Progression
As the player moves through the game, they expect some upgrades, achievements, and a sense of growth and development. So give that to them.
The player’s character can progress, with new abilities and strengths. The story should progress, going from point A to point B. And the world should progress. Change in some way, give the player new options. Don’t just reward players with something monetary in-game. Give them knowledge about their character and the world itself.
Balance
Balance is one of the most important things on this list. The game should obviously get harder in difficulty as time goes on. But it also needs to cater to different skill levels. If you want a lot of people to play your game- and plays is one of the only metrics you can get using the Gimkit Creative platform- then it needs to be accessible. Experienced and new players alike should be able to get something out of it.
Feedback
Feedback is important, and no, I don’t mean having people fill out forms about whether or not they liked your map. This is in-game feedback. When a player performs an action, or does anything really, they want some way of knowing whether it was right or that everything worked. And in a lot of cases, you do want to give some kind of sub-concious confirmation. For example, when a player moves onto the second level of a map, visually they can automatically see that they’re now in the second level because the design is different. But they want a notification or activity feed message saying they progressed, because it indicates that their progression was noticed.Basically, both negative and positive feedback are important, and when used correctly are super helpful ways of guiding the player.
Pacing
Like a book, your game needs a consistent- or at least coherent- pace. Players need to understand the passage of time, for one thing, and they also need the main points of the storyline to be realistically spaced. When making your game, consider how long it will take different players to make it between points and test it to see if it feels alright.
And those are the main aspects of game design. The rest of the guide is talking about specifics and building out your game.
There’s an order…
The next category is about plot, and it’s pretty important to figure that out before working in the editor itself.
Plot and Narrative
This section is about the plot and narrative of a game, which is pretty important.
Plot and narrative refers to how the game tells its story. It’s important to have lore, history, and backstory for a lot of aspects of a game in order to make it feel immersive.
Linear Storytelling
Linear storytelling is when the adventure is monodirectional. A sort of fixed, predetermined narrative where the player is just getting from point A to point B to point C.
Branching Storyline
A branching storyline is when the player has more choice. Instead of just point A to point B, the player can move horizontally along the storyline as well and make different decisions and affect the outcome.
Between these two options, usually it’s better to have something closer to the branching side of the spectrum, but it really depends on the game. This standard comes from the principle that players should have control over the story, so they really feel like they’re in it. Sometimes it isn’t neccessary, though, and some games will benefit from having a simpler plot anyways.
And there’s also a third idea, sort of.
Environmental Storytelling
This is a little more passive, so it doesn’t work for plot-focused games, but environmental storytelling is when the game communicates elements of its story through the world itself instead of direct dialogue and cutscenes. It relies more on visual clues and notes.
This is the style that a lot of open world games use, where you explore in your own and the story is derived from that.
Communicating Plot
-
Show, don’t tell. It’s more valuable for the player to see firsthand what the story is, instead of it being explained directly to them.
-
Games are different then books and movies because players change the story and experience it themselves. Let players shape the plot themselves and don’t hardcode it in.
-
Build tension throughout the story. Instead of merely having event after event, show the effects of those story points in the overall experience.
-
Have moments of reflection, not just action. Let the player have peaceful moments and fast paced action. Variety is important.
-
Character growth should happen, and it should represent the story to some extent. If something traumatic happens, then they should feel it! Maybe it triggers a flashback or something.
-
Let the conclusion of the story be interesting and more dynamic then just the typical happy ever after. Don’t resolve everything and leave room for the future.
Writing Plot
Put some actual effort into writing out the story and don’t let it become an afterthought. Write the story first and then go into the mechanics and code of working it out. Let the plot guide the game, not the other way around.
In fact, it’s worth a shot to try scripting some of it as well. Write out what characters say and how the story unfolds.
Conclusion
Plot and narrative are incredibly important. Don’t forget about them. Write the story and figure it out first. Then start planning.
Planning
You’ve got to start a map somewhere. Whether it’s a post asking for ideas over here on the forum, Wix, and Discord or some seed of inspiration you had in the middle of the night and made sure to write down, all games start out as an idea.
Since we already covered plot, presumably you already have an idea assuming you’re following this in order.
The problem with a lot of maps can end up being that the original idea is modified or changed too much, or that it isn’t consistent across the map. You don’t want to start playing a recreation of Roblox Doors and end up in a Squid Game remake. That would be confusing.
The solution, which most well done maps use, is to plan out your game before jumping into the editor. A plan can look like a lot of things, but I can think of several ways to organize your game in some kind of document that all have various pros and cons.
Flowchart
-
A flowchart is a sort of visual progression of a system or concept. They look like this.
-
Flowcharts are great for visually seeing a game’s plot. You start with the first level, and then players can take different actions that each lead to another plot point, and those branch out and so on. It’s a visual tool to see a system, that’s what a flowchart is.
-
Flowcharts don’t really deal with large quantities or detailed amounts of information per “box”, so you cannot get very descriptive using one. They also don’t have places to put other related details.
List
-
Observe how meta it is that this is a list talking about a list
-
List are helpful for categorizing information into groups and that sort of thing, in order. So it could look something like this:
Example List
- Player clicks on button to move on to level one
- If player moves to the second level too fast, they will be temporarily stopped from participating as an anti-cheat measure
- NPC is available to talk to if player wants
- Title card for second level
- This is nice, but you could totally use a flowchart for it. Instead, use a list to organize information about characters, levels, and other arrays of information in the game.
Bob (Sentry)
- 40 HP
- Level Two
- Lore: Bob is a penguin from Antarctica who is now canon.
- When knocked out, Bob multiplies into Bob One and Bob Two because penguins are exponentially awesome.
- So basically, use lists to categorize information in your game.
Document
So this is the obvious combination of the two organization methods. It’s probably easiest to use both lists and flowcharts when planning out your game. I know this is like a lame way to conclude the section, but the moral of the story (that I attempted to convey here) is that these are two great ways to organize information about your game and plan it out.
In closing, to plan out your game, just orgnanize out what you want to implement. This makes it especially easy to collaborate because you have a document to edit, and you can track what’s been done as well with the next method to use to plan.
Project Management Software
Short footnote, but basically, using something like Asana or Trello, you can create projects where you track the progress and implementation of features of your game. You can usually make at least one project board with a free plan, and it’s just a fun and good way of organizing. I wouldn’t reccomend it unless your game has updates and is really big, because it takes effort to maintain. Usually- basically if you take nothing else away from all this stuff I’ve written- a document is a good enough start.
Rough Draft
Now you’ve got an empty map. Great! What are you going to do with it? No clue.
Exactly like writing out a book, you’re going to want to start with a rough draft. What I think is a common misconception is just starting to make the map from the beginning. You should evenly work on the entire storyline, because otherwise the game will change too much if you just work on it linearly from beginning to end.
To start, like a sketch, it’s easiest to block in each level or area. Make a big barrier or otherwise indicate the position of each level/area and get all of them positioned well. Then you can start working through them, adding terrain, then props, then the mechanics.
Make sure to reference all of the planning you did in the least section and to take a look at the plot. Then it’s important to get into a habit of iterative design.
Prototyping and Playtesting
This is part of building a game, and it means a lot of work over and over again until you find something that works.
What’s Prototyping?
Prototyping is the process of creating a simple and easy version of an idea. It’s like making the proof that it works and can exist, before you commit time and effort to a complete version. For example, any idea of a complicated mechanic you have is a good thing to try prototpying.
Protoyping Best Practices
-
Focus on the core idea or mechanic of whatever you’re testing. Don’t waste time with all of the little details.
-
Prototyping is literally all about speed. Be simple and efficient with your testing.
-
Don’t overcomplicate a protoype. Leave out other related aspects that aren’t needed.
What’s Playtesting?
Playtesting is the process of playing through all or part of your game in order to test it on game design principles and performance. It’s important to playtest frequently, and with other people as well. Playtest with your audience in mind. What kind of people want to play your game and how will they play it?
Playtesting Best Practices
-
Figure out why you’re playtesting and focus on a few things to look out for. Stay focused on those features while you’re playing the game.
-
Record your experience. Don’t trust yourself to remember the important stuff. Take screen recordings of gameplay or notes to look at later when you’re editing that part of the map again.
-
Be open to feedback and don’t overexplain the game to external playtesters, as in your friends who you roped in to help you out. Let them figure the game out themselves without additional information and listen to what they have to say without getting annoyed at their opinions.
Iteration
Iteration refers to editing and refining parts of your game. You’re going to get into a cycle of editing, playtesting, reviewing the playtesting information, and then editing again. This can get repetitive and boring, but the last thing you want is to get burned out. So don’t feel forced to work on one part of your map for a whole day or something. Jump around.
So after you’ve started work in a map, get into the habit of playtesting. It’s really helpful and it’s also fun.
Game Structure
The structure of a game is the plot and the storyline. How does the player get from Point A to Point B? What are the choices they can make to affect the plot? This is the kind of thing helpful to map in a flowchart.
So you want to make sure that you a) have an interesting story and b) the player feels like they’re in control to some extent, which combined make the game feel a lot more immersive.
A couple of things to look out for here.
Soft Locking
Soft locking is when you get stuck at a point in the game (e.g. stuck in a hole in the ground, or respawn mechanism doesn’t work) and cannot get unstuck. The game is running normally, but you can’t progress any more. Soft locking’s frustrating to the player because it means the game creator didn’t test out the game enough and now they have to start over.
So basically, remember to play test thoroughly and ask other people to playtest as well. They’ll spot things you might have missed, just like how peer review is important with writing.
Hard Locking
Hard locking is when the game completely crashes. Like, it glitches and is frozen or the screen goes black or something. This is pretty rare in Gimkit, since it’s just a sandbox editor really, but it happens sometimes with high performance games. If you’re encountering hard locking in your game, try to redistribute some of the more memory intensive mechanics and if neccessary, remove some things.
Hard locking in Gimkit has the same result as soft locking, because either way you have to reload the game and there’s no such thing as saving progress (excluding save codes, that sort of thing) smoothly.
Bottom line here is that playtesting is important.
User Interface
A big aspect of game design is not the game itself, but the framework surrounding it. As in the UI.
Gimkit already has a built-in UI, with the buttons to start and stop the game, view inventory and leaderboard, and view players. In Creative, you can add up to four buttons and overlays, one in each corner of the screen.
So here’s a list of things you can do with Creative in order to make something that would be considered a UI.
-
Buttons
-
Popups
-
Menus
-
The whole-player-moves-to-control-the-menu-that-is-actually-a-bunch-of-props smashed-together situation
-
On-Screen Text
Having a UI is not necessary for everything, but here are some UI elements that are commonly and realistically used in all sorts of games.
-
An energy meter
-
A text display
-
A button
-
Menus
And now there’s actually a whole device for user interfaces, which is rather strangely called the Popup Call to Action device but it basically mimics the selection system used in the official gamemode Apocalypse.
The UI can help communicate a lot of important information in the game, like…
-
Instructions at the beginning of the game
-
A clear objective for the player
-
A clear way to progress
-
“Trail markers”, like checkpoints, signs, text, arrows, waypoints, distinct areas
-
Ways to respawn from or reset the current event
But there’s also another term starting with “u”, and that’s User Experience, or UX. UX refers to how easily the player can experience your game, or play it, and how intuitive and good it feels.
To achieve a good UX, you want a lot of sub-concious indicators of right or wrong, really. Here are some examples.
Quick little interlude. At the end of this guide I’m going to write out a full, step by step tutorial on how to develop a map, but in the meantime, here’s how you should think through the process of making a game.
First, come up with an idea. Then, start thinking about the storyline and plot. Once you’ve got a rough outline, then you can start planning out your game with levels and such. Then, take a look at the playtesting and prototyping section. Start getting ready to implement specific mechanisms. This way, you’ve thought through everything before touching the map editor.
The guide continues in the most recent post for now, sorry about that. It reached the character limit.
I asked Gimkit to extend the character limit but they haven’t gotten back to me about it yet. So for now you’ll have to deal with the interruption.