I thought it’d be useful to compile a few important advices I read about or learned the hard way. If you’ve been doing your research, you’ll probably know some of these already. But if you’re just starting, this is a nice TLDR that will save you some time. While writing this, I realized it was becoming huge, so I decided to break it up into edible chunks. It’s mainly divided into 4 categories: Design, Art, Organization and Marketing.
So let’s start with some Design advices:
1- Focus on smaller games. Specially if it’s your first game. Concentrate in 1 single idea, and try to develop that idea only. Don’t start branching out and adding ideas upon ideas because it can get out of control really easy. I guess this depends a bit on the designer/s, but this is easier said than done for me. Once I start with an idea, I keep building upon it (even unconsciously) until it becomes this unfathomable mountain of work. The worst part is that there are a lot of really good ideas; I can’t just ignore them as they will improve the overall quality of the game. So I’m stuck between drawing the line and removing a potentially great idea or go for it but add more dev time.
In fact, this problem actually happened with this “Advice” article. It was going to be a small bullet point TLDR. I ended up breaking it apart into several blog entries.
As to how it went for Gravitators, I think it’s worth to write a full entry explaining this. It’s quite a story on its own.
2- Choose your platform well before you start the design. It’s not the same if you’re doing a mobile game, or a PC game or a PS/Xbox or a Switch game. They all have strengths and weaknesses, advantages and disadvantages, players tastes and expectations. If you’re planning to release on several platforms, be aware that each will take you a considerable amount of time, and if you’re solo or with a small team, it might put too much stress.
3- Play absolutely every game you can. From Atari 2600 to PS5, going through mobile, flash games, board games, card games, anything really. You can draw inspiration from everything. It’s very useful to see what works for each type of game, with all its restrictions and advantages.
First, you should of course start playing the games of the same genre as the one you’re planning to do. And not only the good ones. By only playing the best of the best, you will definitely note why they are at the top, but you’d be missing out what doesn’t work, and you might end up making the mistake of going that way.
When you play all the others, you’ll start noticing what things don’t work well within the genre (or at the very least, what you consider not OK for your game).
What I suggest you do is:
. Do your research and make a list of all games that are from the same genre (additionally, you can add games that could share some player base, or with the same art style, or some specific tech or mechanic that you’re interested to check, or cool menus or UI, or even music and sound effects that you feel match your game). Basically anything that picks your interest and you might use for the game.
. If the list is too large, group them by priorities and start with the most important ones. Then, if you have time, continue with the rest.
. If the game is too old, too expensive to buy (and doesn’t have a demo), on a platform you don’t know or you simply don’t have much time, you can always search longplays or no commentary gameplays. I don’t think I ever encountered a game that wasn’t available to watch for a good amount of time. I don’t recommend watching gameplay videos with commentary because I think music and sound effects are almost as important. Exception would be if you’re watching a developer break the game apart or a gamer reviewing it, as both of them can be useful.
Just to give you a quick idea, this is the list of games I prepared before and during Gravitators development:
3D Gravity Rocket
Aces of the Galaxy
Beat Hazard 2
Death Ray Manta SE
Drone Zero Gravity
Enter the Gungeon
Galaxy on Fire 2
Geometry Wars 3
Heroes of Hammerwatch
In Space We Brawl
Land It Rocket
Line Space Wars
Microcosmum: survival of cells
Non Stop Space Defense
Perfect Universe – Play with Gravity
PixelJunk Shooter Ultimate
Power of Ten
r0x (Extended Play)
Really Big Sky
RIVE: Wreck, Hack, Die, Retry!
Sins of a Solar Empire: Rebellion
Sixty Second Shooter Prime
Space Invaders Extreme
Space Run Galaxy
Sparkle 2 Evo
Starr Mazer: DSP
Strike Squadron: Caracará
Strike Suit Zero
Super Laser Raser
Super Rocket Ride
Survive in Space
SYNTHETIK: Legion Rising
The Long Journey Home
The Royal Cosmonautical Society
Warhammer 40,000: Armageddon
Wayward Terran Frontier: Zero Falls
X3: Albion Prelude
Xenoraid: The First Space War
I probably miss some games that I quickly checked and didn’t write down.
I didn’t play all of them, specially if I only wanted to check a quick thing. But I made sure that I fully played very similar games. Seeing what others are doing is probably the best way to measure your work.
When you play, you should split your mind and go through the game with both a player mindset and a designer/developer mindset.
As a player, you should ask yourself this kind of questions:
. Are you having fun? Why / Why not?
. How do the controls feel?
. Did you get confused at any point (with the controls, directions, etc.)? What did you need to prevent that from happening?
. As the game progresses, are you more engaged (can’t stop playing) or you’re just rushing to get it over with? Why?
As a designer/developer, you should break the game apart and see how all the pieces come together. Questions you should ask:
. What can the player can do with the in-game avatar (actions, movement)?
. How do all objects/entities interact with the player avatar or with each other?
. What settings can you modify (in options or the gameplay itself)? Are they easy to find?
. How is the camera work? What effects are used? Do these bother you or improve your experience?
. Is there anything that can be used for your game? Is there anything that you should absolutely avoid?
I went through this a bit more in depth in the “Analyzing Games” article.
While playing all the games (or watching gameplay videos), I had a notebook next to me, and wrote the answers to all those questions and any idea sparked by them. Afterwards, I went through it, and used those notes to add, change or remove design ideas for Gravitators. It’s also important to have a good filter here, so the rest of the team only gets the final, polished proposal. And not all your random thoughts.
4- Playing the “games of interest” isn’t enough though. It’s almost as important to see what other games are doing. I always can take something useful by playing them (either an idea for my game, or (in the case of popular games that I don’t really like) to understand why many players have fun with them.
So I try to go through a variety of games, doing as much rotation as possible (from genre to release date).
This is the list of games I played in 2020:
Dark Quest 2
Day of the Tentacle
FIFA (only when meeting friends)
Mother Russia Bleeds
The Deadly Tower of Monsters
Super Mario Bros Wii U
Besiege (didn’t finish it)
Bullshot (didn’t finish it)
Rocksmith (started playing a bit bass)
Streets of Rage 4
12 is better than 6
Mutant Year Zero
Mario Kart 8 (replay)
Four Ways (didn’t finish it)
The Fall Part 2
Remnant: From the Ashes
Madden NFL 21 (didn’t finish it, free weekend)
Plants vs Zombies (replay)
I’m missing a couple of genres, but I think it’s a pretty good list. I take this time more as R&D than plain entertainment. I try to keep it down to a few hours per week only, although I must admit that when I hit a game I really like I ended up spending more time than I had planned. I also usually try to alternate a bit between long games and short games.
5- Don’t reinvent the wheel. The industry has matured quite a bit since its humble beginnings. There are a gazillion tools (many of them free) to aid you in development. So, while you can design an engine from scratch, code all the shaders, work on the libraries for all platforms, create the 3D models, textures or sprites, and compose the music and the sound effects… do you really need to? If you’d like to test your skills or are eager to learn about a specific topic this is absolutely OK, but every single thing you add to the list means more development time. If your goal is to develop games, then remove all unnecessary tasks by using all available tools at your disposal and focus on the game. Chances are that the tool is more than enough for the job you do, and you minimize the risk of encountering insurmountable difficulties that will damage your schedule.
On the flip side, by using third party tools you’re usually constrained by what the creator has done. So if you’re going to need flexibility or many additions, you should consider finding an open source tool or develop it yourself. Pick your battles wisely.
6- Careful with going against the norm. Certain standards are expected by players today. A few examples:
. Interactive Tutorials. The days of “Tutorial Pages” are over. Players don’t want to read a 10 page manual to learn how to play the game. They’ll forget all about it and will already be bored by the time gameplay begins. Make your tutorials as interactive as possible. Don’t interrupt with pop up texts unless you really cannot find another way. Teach what needs to be taught at each specific time. But don’t overdo it either: players don’t really like feeling you’re holding their hands either. It’s a fine balance to find. And this is why the Tutorials should be implemented once the core mechanics of the game are polished and settled. Otherwise you’ll be spending extra time doing the tutorials over and over again.
This is not a golden rule though. Some games fare better with little to no tutorials, and the player is expected to discover them by trial and error. But it’s definitely a lot more difficult to pull off. When most players need to search for guides or videos online, game design failed. And I don’t mean when players search for best-builds, exploit strategies or any kind of metagaming, I mean when they really have no idea how to properly play the game.
. Frustration. Unless you’re specifically and deliberately developing a frustrating experience (I’m looking at you, Bennett Foddy), from the moment the game is playable until launch, your main job is to remove frustration. And I’m not referring to bugs. I mean stuff like: getting stuck, confused as to what to do or where to go, difficulty spikes, boring segments, grinding, breaking immersion, consistency issues, etc.
Players don’t like feeling frustrated. They are playing your game to have fun, to improve their skills, to compete, to feel accomplished. Each one has different frustration tolerance, but everyone will eventually tire and quit the game if it’s not a positive experience. Most people already have a huge backlog of unplayed games, and games are releasing at a faster rate than ever. In the 80s and 90s most players were stuck with a single game for a foreseeable future, so sometimes there wasn’t any choice. Today, you get a new game with a few clicks.
Now, it’s understandable that some games will release with ups-and-downs. Some grinding is almost impossible to avoid on an MMO. If you don’t slow down player progress, everyone would be at max level very fast and you’ll be out of content (losing players). But removing frustration should always be your goal.
. UI / HUD / Menus. User interface has come a long way. Many games today have a lot of information to portray to the player (due to the increased complexity of modern games), yet it’s all done with such attention to detail that we don’t even realize all the information we’re handling on a constant basis.
If you check some old games, you’ll probably notice the UI is all over the place. Confusing, convoluted, just plain ugly.
The basic rule for HUDs seems to be “show what players need to know while playing”. Health, Stamina, Direction, Weapons, stuff like that. If there’s no need to know, then no need to show. A clear example for this is Mario 64. Very small UI, health bar didn’t show until you got hit or were losing it underwater.
Polishing UI appears simple at first, but it actually takes a long time to get right. Your goal is to maximize player understanding of the situation.
We’ve done many attempts and variations until we settled with one that was clear and tidy. Don’t wait until the end to start with this.
. Autosave. Most games already have some sort of autosave going on. Many also have several autosaves now. Forcing the player to save progress by himself (potentially losing precious time if making a mistake) seems dangerous nowadays.
So while going against the norm is a possibility, you’ll be walking on thin ice. If you’re not careful enough, you’ll be alienating a big part of your potential player base with something it’s very easy to solve.
7- Listen to feedback. While you’re developing the game, some people from outside the team will most likely play the game (family, friends, random strangers from the internet, etc.). If they play games (and even better if they like your game’s genre), their feedback will probably closer to real players that will buy your game.
You don’t need to apply everything everyone says. But if you show the game to 10 people, and 8 of them give you the same feedback, I’d certainly fix that one.
With Gravitators, once it was in its more final form, we had feedback like these:
– Good: Graphics, Ships weapons fun to use, different levels/objectives keeps variety.
– Bad: Different controls for each ship, and not being able to use controller/gamepad.
A significant amount of people complained about the controls, which worried us.
The reasoning behind ship controls implementation was the following:
Retro Gravity games have separate thrust and rotation controls, and thrust always moved the ship forward. As we are heavily inspired by these games, we wanted to keep that. New games, on the other hand, they use WASD to move into all directions and a mouse pointer to aim.
Choosing one type of controls would alienate players that like the other. This would cause those players to dislike the game entirely. I actually experienced this with some of the similar games I played.
Given the numerous types of controls and the dangers of sticking with one, we said “why not do them all?”. So each ship would have different piloting controls. It’d add an extra layer of difficulty if players want to beat the game using all ships, and we’ll ensure that most players will at least find one ship that they liked to pilot.
I personally loved the brain cramps when having to switch ships (and controls), as it caused an initial confusion or delay, similar to switching languages on the go.
This is how we ended up with the following controls:
Fighter: Thrusts with SPACE, rotates by moving the mouse horizontally only.
Sparker: Thrusts with SPACE, rotates by pressing A or D.
Lancer: Thrusts with SPACE, rotates by moving the mouse 360° into the desired direction.
Crusher: Uses WASD to move into any direction, and rotates by moving the mouse 360° into the desired direction (this was closer to what new games normally use nowadays).
We did not have good feedback on this. Most of the comments were like:
“I really like everything about the game but the controls are just too hard.”
“Why can’t I just move with WASD and aim with a mouse pointer? All games are like that now.”
This clashed with one of the first design decisions we had made. But at the same time, too many people did not enjoy the controls. Any big fan of old retro gravity games (like me) was fine. But everyone else was just not having a good experience because of them.
On the other hand, it would have been a pity to lose all the different controls that we spent so much time fine-tuning.
So in the end, we decided to implement everything, and let the player decide. When you launch the game for the first time, it’ll ask you if you’d like to have a MODERN experience (using WASD and mouse pointer) or a CLASSIC experience (ships will use different controls), also suggesting that most players will find MODERN more comfortable and intuitive. And that’s it.
Maybe it’s not ideal, but it was the best compromise we could find. We did another round of playtests with Modern controls, and everyone agreed the game felt much better.
So when listening to feedback, it’s important to remove all preconceptions you had with your game. What you feel it’s right and settled, might change after more and more people get to play what you’ve done. And as a designer, it’s very easy to fall into a “I know more than them, they are all wrong” trap. You must never forget that you’re doing the game for the players, and not for you. Be open minded when receiving feedback, and be ready to change anything.
© 2019 Insular Games. Gravitators, Gravitators Logo and Insular Games logo are trademarks of Insular CV. All rights reserved.