“I want to build own RTS game but don’t know how or where to get started. I have a (very) rough idea but I don’t know where to start. Can you give me any pointers?”
I’d advocate a 4 step process. 1) Vision. 2) Player journey. 3) Prove your thesis. 4) Build all your features. From here you’d go into playtesting and optimization, but you were interested in how to get started, so I’ll stop at step 4.
Start with a vision that you can articulate and share with your team or players. You don’t actually have to share it, but you need something that could be shared. If the ideas are still sort of fuzzy in your mind, then you haven’t finished this step yet.
Your vision statement can be any length that is useful, though shorter is usually better. If you end up with a longer one, then be prepared to also boil it down to an “elevator statement,” so called because the idea is that you might find yourself on an elevator with some publishing big shot and might have only a minute or two to make your pitch.
Two simple ways to approach this are the “except” and the “cross between.” For example, “Age of Empires is like any RTS except that it has random maps,” or “Age of Empires is a cross between Warcraft and Civilization.”
The vision is important because it helps you identify what is really important in your game for you to nail correctly, but also what isn’t important. Don’t make the noob (and sadly non-noob as well) mistake of saying everything is important. Maybe your world is important, or your combat, or your multiplayer matchmaking, or your interface, or your art style, or your story. But it can’t all be important or you’ll never finish, and probably be unfocused until you realize that you’ll never finish.
I wouldn’t focus on story for a long time, unless you’re really going for a story-driven game. (If what you really want to do is tell a story, maybe you should be writing a story or making a movie, not designing a game.) Getting too excited about any detail too early on (especially story) might lead you down the wrong path away from your vision. Instead think about the player experience. What kind of players will play your game? Why will they play your game? The answer has to be some version of “There isn’t another game that meets their needs.” If your answer is “It’s like this other popular game, but the gameplay is 10% better” that may not be sufficient.
If you’re happy with your vision, then I would start thinking about the features you’d need to deliver on that vision. One framework to do that is to create “a player journey.” Tell a story (which can be through words or pictures or a slide deck) about the experience a player might have playing your game. “She picked it up because some of her friends were talking about it, and it kept showing up on Youtube” all the way to “She lost her first couple of games against the computer opponent, which was frustrating, but also drove her desire to try again an prove that she could do it.”
You don’t have to take your made up player through 50 hours of gameplay. Sometimes just a complete story through a game session is sufficient. This is sometimes called a “vertical slice” because you are thinking about everything from firing up the game to logging out and all of the stuff in between, but you don’t need to think about all of the variation therein. For example, if you’re making an RTS maybe you only think about one of the races / civilizations and only some of the units, but you’re also thinking about the player experience going into a match and what happens after the match.
This journey exercise will help you do a couple of things. It will help you figure out some of your features and how important those are to your experience. Do you need a single player campaign? Maybe not. Do you need a way to download the game? Almost certainly.
It will also help you focus on the player experience. In my example, the player lost a couple of early games. This is a bold move because it’s likely to cause players to quit, especially if they don’t feel like they understand the game well enough to have a chance. If that’s important to your experience, then you need to think deeply about how you solve the second part of that equation: the “but she felt compelled to keep trying.” What is it about your game that drives that?
This is a tricky part, because you want to do just enough work to convince yourself (and maybe your team and your publisher) that your basic idea will work but you don’t want to actually build the entire game. You’re really screwed if you start up a lot of development time only to find that one of your core ideas isn’t super compelling in the long run.
Going back to the Age of Empires example, it would have been very expensive to build a random map generator when the team wasn’t confident that random maps really were as awesome as they had imagined. A cheap way to prove the thesis is to have someone build by hand 3-4 maps and then not tell the team which one they were playing on so that the experience might feel random. You might get feedback like “I couldn’t locate my starting resources” or “I felt I lost because the enemy had a better starting location” and then you’ll know you need to prove that those problems won’t be blockers before you declare victory and move on. This is a time to cut corners. Use stand in art. Prototype in paper if you have to. Do the minimum you need to prove your point.
From here, you basically have done the hard work to design your game and now you need to figure out how to build it. You’ve done the “what” and you can move on to the “how.” This will lead to a lot of thoughts about specifics, about what features you’ll need, about scope, and about what kind of team you’ll need to deliver. From this step on you’re not imagining a game, you’re making one. There is a lot of hard work ahead of course, but a lot of game designs don’t even make it this far.
prguitarman
annaxmalina
germansingergirl
kianamaiart
titsay
baratheonpilled
2087
