The Big Idea: Guidelines on How to Complete an Ambitious Project
by Michael Klaus Schmidt
The Big Idea
A few years ago, I had a game idea that seemed too big and too ambitious for a single developer to actually complete. However, I was so passionate about the project, that I shrugged off my concerns and dove in to start development. I knew it would take long, but I had worked on other projects, whether game related or not, for long periods, and I believed I could handle it if I paced myself. Was I a heroic game designer? Or a fool who took on too much?
The Risks of a Big Project
The risk with a big project, especially for a single person without a team, is that the project may soon overwhelm you if you have no other people to fall back on. With a solo developer handling design, programming, art, sounds and even play-testing, debugging and marketing of a game, it can easily take up too much time and energy, causing you to fall into inaction. Inaction, obviously will stop the project from moving forward, and then despair can set in. This can kill the project and cause all sorts of self-discussions about whether trying to design games is even worth the effort.
Outer space is an interesting place. On of my goals was to have my game generate unique nebulas. The script I made to do this actually led me to create a whole different game.
Having done this, and having completed two games – well nearly completed in the case of one of them – I feel like I have gained some insights into this issue. Reflecting on my experiences: things that worked, things that didn't, I felt like I had a set of guidelines by which anyone might complete a project that might seem too large for an individual to handle alone.
Start Small
I know, we're talking about doing a big project, right? So why would I want to start small? Well, that's my first piece of advice. Start your big project by making a small one. Even if you've already started the big one, step back, and make a small game from start to finish. Get it play tested, fix all the bugs, and publish it on Steam, or the Play Store, or wherever you feel comfortable publishing your game. Give it an appropriate price, free if necessary, but make sure you go through the whole process. Create artwork for marketing the game, a trailer, maybe a short tutorial if the gameplay is at all complex. These are all things you will be doing on your big game, so it is really a good idea to know what to expect.
UPDATE: I learned recently about a thing called the inverse pyramid approach. This idea visualizes your game as a large pyramid, with the pointy part on the bottom. Imagine taking slices of this pyramid. The bottom would simply be a smaller pyramid. In this way, you would develop a complete version of the game, that is limited in scope. For instance, if you are developing an adventure game with exploration, combat, trading etc... you could start by making just the combat portion. It would be a complete game in that you would create it, and release it to players as a simple combat game. Later, you can use this smaller game in the creation of your big game. If you program it carefully, it can simply plug into your game, yet be fully playable as a stand alone mini-game. If you approach all the various parts of your game like this, even if you run out of time or budget, you will still have a complete game at the end of it, even if it is not the full game you imagined.
If you've already done a small game, and gone through all these steps, then great, you should be ready for your big idea. But you will still have to keep a number of things in mind before you dive in.
Check out "Anomalies," which was originally based on my nebula creation script. I followed this idea of random shape generation, and later included movement and sounds as well. Read more about it here Indiedb.com
Make a Design Document
Design Documents are for big AAA game companies right? Wrong. You will want to make one, and you will want to put down all your ideas, in writing, before you start designing spaceships, and bosses and whatever it is you have in mind for your game.
Template documents can be downloaded if you want to see what other people have in mind when they make their games, it might be a good idea to check some of those out. However, the main idea is to document everything you want in your game, and to approximate how you are going to make it.
Most people would use a word processing program to create their design document. I like to sketch out ideas, and tend to prefer a looser structure, so I use graph paper. To each their own.
This is not about writing code on paper before committing it to your script editor. This is much more high level. Write the game's primary story-line. Write about who the main character is, what he can do, what he can't do. What are the challenges? Who are the enemies? What do the levels look like? Whatever it is that your game is about, write it down and think about what it will take to make that part of the game work. Some things at this stage may seem too hard … well break it up into smaller tasks.
A large part of game design is simply figuring out how something is going to work. Do that in your design document, because you don't want to be making those decisions while you’re coding.
Once you have a clear idea on what you want the game to be like, and details of the individual pieces that will be used to build your game, you will be ready to start making it.
Part of your design document may include images like this. If you are an artist, you will want to have a sketchbook or some way to capture your ideas quickly. For 3D modeling, it's always helpful to have 2D references. Even a quick sketch like this can help tremendously when you are making a 3D model.
Marketing
Don't make my mistake. Don't think about marketing your game after you've got it up and running. Think about marketing before you start coding. If you have any hopes of eventually selling your game, or getting people to actually play it, then the sooner you think about marketing, the better.
In my experience, if you think your game is so unique that no one else will ever come up with it … you're wrong. People come up with similar game ideas all the time. It's part of the creative process. You see what is out there, you imagine some new combination of those things, and you get an idea. Everyone has access to what is already out there, it makes sense that other people will come up with the same, or similar combinations.
Make a web page. Make a blog. Post about it on Social Media. Get people excited about your idea, and get their feedback too. The earlier you include other people into your design process, the more people you will be able to reach once the game is ready to be played. Also, you will be linking the game idea to you, even if it's not finished. That way, even if another developer comes along with a similar idea, you will have a public record of your game before they come along.
I would not recommend taking out ads for your game before it's released. Advertising is only a small portion of what constitutes marketing. If you do a good job getting your game out there, you may not need to advertise it at all.
Also, remember, there is no better marketing than having the game show up in the place people buy games. My experience is with Steam. Once you release a game on Steam, those first few days are critical. People will be seeing the game show up on their screens. Make sure the images you make are eye-catching, and more important, make sure the game is well tested, stable and really polished. Nothing will sell your game better than players who love playing it!
My big game is currently in Early Access on Steam. If I could do it over, I would have made sure it was more streamlined before I ever released it. However Steam does not give you your full visibility until you do a full release, so there is still hope.
Modeling is just one small aspect of game design. Here you can see how a quick sketch was used in creating a more detailed model. Similarly, your design document keeps track of basic ideas, that you will eventually convert into the game itself.
Scaling Back while Keeping Essentials
We all have great ideas. Every game developer has buckets full of ideas. Ideas are the meat and potatoes of game design, but you also need to be able to implement them in order for them to work. Scaling back is to know when to drop an idea that does not serve the game's main purpose. I had lots of ideas that sounded great, but they did not further my game's purpose of space exploration and discovery.
An example is the mothership. In the game, the player can visit a mothership, where goods can be traded and quests can be assigned. My idea was to create a huge mothership interior that the player could walk through, visiting shops and other characters. I still love this idea, and eventually I would really like to add it to my game, but it would have taken a lot of time. That time might be better spent finishing off the main game mechanics, and developing the exploration aspect further.
Instead, I allowed all the player's interactions with the mothership to happen through a menu whenever the mothership was near. This allowed all the required things to happen, i.e. quests, trading, etc... without any of the extra time modeling and designing this massive ship interior. Doing that well may have taken months. Making the simple menu took only a couple days.
Yes, I still think about the mothership interior, but the game is not quite finished, and I have to focus on those essentials that make the game playable and fun. For now the mothership will have to wait, and the menu will have to do it's job.
These are the kinds of sacrifices that may have to be made for a lone developer to complete a project.
Be sure that you are not cutting down on the essentials. Essentials are those things that you wanted your game to do in the first place. Exploration was an essential for me. So, while I could have decided to cut out landing on planets in order to save time – and it would have, believe me – it would have taken away the main point of the game, which was to be able to land on and explore planets.
Landing on planets like this super-heated desert world is essential to my game. Ask yourself what you can't do without. It may help you to determine what can be left out of the game, saving you precious time and energy better spent on those main features.
What is essential, and what is superfluous? These are questions only you, the game developer, can answer about your own game. But be prepared to cut some ideas in order to make sure the important ones get the attention they deserve. You can always go back and add a new feature once the game is finished. Then you have the option to provide that new feature in an update or DLC package.
Slow and Steady
A major part of finishing a big project is to work slowly and steadily. One habit that I fell into in the beginning was that, when I wanted to, I would spend hours and hours working, but when that feeling went away, I would revert to doing nothing. I knew early on that this had to stop.
Instead, I set up a system by which I would work a moderate amount, an amount I knew I could handle on a daily basis. On occasion, I would still find those moments of high energy, and be able to make great progress in a short period of time. However, at the low points, I knew if I just finished one little task a day, I would be able to keep the ball rolling, preventing inaction, and cutting despair off at its root.
Also, connected with this concept is the fact that a big game will take a long time. Be ready for this. If you’ve never worked on a big project before, be prepared to get bored of it. Be prepared to have other great ideas, and be prepared to say no to those ideas, if, that is, you ever want to finish your big one.
Slow, steady determination can help you build the project you have in mind. Be prepared to take your time. Don't skimp on essentials, and don't invest in things that are superfluous.
Conclusion
These guidelines can be used by anyone, for any project, at any time. However, I learned them by working on games. Games tend to involve so many different disciplines, that I think they may have more tendency to wear people out, but it really depends on the person and how they work.
I said the guidelines were for big project ideas, but these ideas can be scaled to pretty much any game, platform or project of any size. My games are Windows based, but these ideas could apply to any platform. If you have an idea for a small game, you can still benefit from deciding what is essential to the game, and cutting out things that are not. This could be especially helpful if you have a time limit for your project.
If you, like many solo game developers, are struggling to finish projects, or keep them alive, consider these guidelines and see if they might help you get back on the right path.
Check out my current, ambitious galaxy simulation/game Star Explorers here: Indiedb.com
This is a good write up. I planned to do the same thing with a project much too big for me alone, but decided to scrap it until I can manage a team. The part about a GDD and accepting the slow pace is wise. More power to you!
Thanks! You know, managing a team is a tough thing for introverted types like me. I do envy what teams can get done though, so if you can do it you should!
Thanks for posting this. I started the 3571 project alone 5 years ago with no coding skills and now I have a comic album and and a 3D survival procedural RPG! I believe in artisanal big videogames.
Hey, that looks great, I just followed your game. I like the combination of cartoon and realism. Looks fun!