"Your Treasure House is for yourself, it contains all you need."
When I go to any game related event, I see a lot of people asking about "how to make" games. There are groups and groups searching for some magical solution for taking the first steps on "the path of game design" and game development. If you'd like to know more about it, take a look at Danish Sinha's article, which already gives some pretty good insights to beginners.
But even so, I still see a blockage, or rather it seems that many beginners create limitations in their own initiatives/projects. Many people get stuck in the "eternal cycle" of tutorials and online courses. They study, study, study, and do nothing other than that. NOTHING! It curious thing seeing so many good people caught u p in a "wheel of knowledge", and they never get any progress. It's very sad, but these people have a great problem IMHO: in their minds, they are never good enough for starting up a meaningful project.
I consider this one of the WORST MISTAKES made by the very newbies. They never start anything because they do not think they have the competence for doing so. I've learned valuable lessons and developed many ideas and resources for my own game projects that went wrong, or that were simply abandoned. These projects served as the basis for my current games and which allowed me to engage in a series of other projects. Those mistakes, the "bad" games, the stumbling blocks, only turned out to show me different ways of doing things.
The "Perfect Game" Dilemma
Starting a game project (an Indie game for example) is in the most cases an exercise of patience and determination. How many people procrastinate before starting something, by putting several obstacles ahead of themselves (of which there are none) in search of the "perfect game". It seems to be a very difficult thing to start a new game project, even a simple and small one. Some newbie game developers have unrealizable ideas for your first project. These ideas end up frustrating the newbie developer, leaving him lost and without a clear way for moving forward. When that happens, it is time to take a deep breath and rethink some points of the project.
But if you don't know how to go about doing that, I'll show you how I start my game projects and keep it going, without dangerous shortcuts. It is a personal philosophy, it comes from a lot of successful game projects and also from failed ones. This article is not meant to be a "philosopher's stone" for how tuning your mind to success, but it is the fruit of my own experiences while working in a lot of game projects (educational, indies, serious etc).
So let's explore such ideas a little bit further...
When I want to make a game I immerse myself in several things around me. I play old games, I watch movies and TV shows, I read comics, books etc.
I got a lot of ideas from my immersion period, and I start writing a lot. I design the basic gameplay on a paper and I try some game mechanics for an alpha prototype (I'm not coding this time, it's just thinking...) After one or two days working on it, I start a first GDD (Game Design Documenbt) draft.
An important question: how long is your immersion time? Days? Weeks? Months? In most of my projects, one week.
2) I write a GDD, not a bible
In many of my games, I am the game designer/programmer. I set up a GDD to keep my work going.
I don't waste my time in details about the trousers color of my main character or their taste for wheat beer (although I love wheat beer!). This is something I will focus on later or I will only end up making it simple. In many games, it isn't even necessary (sad but true). The player wants to kill mobs, make the best score and unlock a lot of achievements.
In my GDD I basically have descriptions of:
- The game flow;
- The basic math and balancing;
- The levels;
- The gameplay and mechanics;
- The basic art and interface.
When I got an acceptable GDD, the work begins.
3) Working with SCRUM
SCRUM is really an essential software project methodology for me. With SCRUM, I set my goals in a realistic and workable way. If I do something else in a sprint period, it is a super welcome bonus. If you don't know anything about SCRUM, take a look at this link: https://en.wikipedia.org/wiki/Scrum_(software_development)
4) Start with simplicity or the KISS Rule
The KISS RULE (Keep It Simple Stupid) sounds silly, but starting with the "easy one" in a project gives you the necessary strength to keep going. Seeing the first results on your computer screen is a way to keep your workflow in a constant pace of production.
When the difficult part comes, you are ready to continue and not give up. It's very important to keep that in your mind. And an important and final tip: don't try reinventing the wheel.
5) Tutorials are made to solve specific problems
When I'm going to make a particular style of gameplay, I will only refer to the really useful tutorials. I search the most important ones with "killing solutions". I don't waste my time watching a lot of videos, with a lot of solutions. I tend to stick to those tutorials addressing solutions to "real problems" I can easily relate to my project.
By doing so, you gain time and the ability for solving the most common problems.
Don't be afraid to ask Google things like "how do I do an inventory system?". You're not cheating if you look for solutions and implementations ready-to-go. Making things from scratch will only work (in most cases) if you have a lot of money and the help of a big development team.
The "digital oracle" will answer most of all your questions.
7) Use the "best" development tool
What is the best development tool?
I always got asked that same question and my answer is: the one you know is the best for you. Be careful with one thing: sometimes having to use a sledgehammer to crack a nut isn´t the best way to go.
If you don't know which tool to choose, you should choose the one for which there's a lot tutorials, dev groups, and study materials available.
...look for the tool that will really help you and make you "comfortable" with the development flow. When I say "comfortable", keep one thing in your mind: the tool will give you resources for solving your problems in an easy way, in a low learning curve and by a good price.
8) Learn when and how to stop
Sometimes, it's necessary to know when to finish a project. Fantastic ideas may arise in the development cycle, which could turn the game into something beyond the exceptional.
Watch out! Danger ahead! IT'S A TRAP!
We can fall into a famous trap: I can make my game better with more development time. It's important to know one thing: time to stop and how to use such ideas in a new project or a "2.0" version. I know a real story about a game developer who has been making a clone of a classic game for 8 years, and for him, it is never good enough.
Note: In the next June, this guy will be celebrating his 9-year anniversary on the development of his game.
All of my games have deadlines.
My usual game development cycle will take 3 to 4 months for completion (I'm using the "dev cycle time" adopted by ATARI's games and some old Nintendo's cartridge games). I don't try to "stretch" these deadlines. For me, this is a rule set on the stone. In the future, maybe, I'll have more time for making a game.
One last note: DISCIPLINE, above all, is fundamental.
When I finish a project, I stop doing all the things related to game developmenbt and I have one or more weeks of vacation (in most cases, two weeks). I will not start new projects during this time. This will be my free time for playing games (digital and board games), "raiding" with my wife in World of Warcraft, watching movies, fencing, etc.
A fresh head will produce fantastic things and ideas. Take a time for you...
I've developed my games with this rules and they've worked for me. It's my own path, my philosophy, the way I do my work ... However, it's very important for you (as a developer) to really make games. It's the only way for you to find your way in the game industry. Make a simple game, but MAKE IT! Wait no more!
If you'd like to talk more about that, drop me a message or leave a comment on the comment section.