Once you decide to make games, you're jumping into an ocean of new problems - problems that you didn't even know existed! But you're also jumping into a rewarding and challenging medium, one that allows you to explore your ideas in novel and interesting ways.
What's more, the problems that a new developer encounters are the same ones that everyone else has encountered, so a lot of time and heartache can be saved by taking the advice of others. In this article, I'll talk about how I navigated those problems, starting from my first idea and progressing to my first successful game.
The Idea That Got Me Started
Typically, you start making games because you have a compelling idea for one. My idea was a free-roaming FPS with random world generation, random building generation, dynamic AI, the works. After I finished writing the Game Design Document for my idea (the enthusiasm!) it was obvious that I didn't have the foggiest idea owhat I was doing, so I decided to leave it for a time when I was more experienced (like my tenth game, maybe) and do something much simpler: a clay pigeon shooting game. It was still related to my goal of making an FPS, but not as amazingly complex.
Choosing a Language and Engine
I already knew how to program in high-level scripting languages like PHP and Autohotkey, so I was happy to learn any other high-level gamedev language like Java, Python, Lua, or C#. With this in mind, I began looking at engines and frameworks.
I went to reddit and took stock of the popular 3D engines, then tried a bunch of them out myself to see if they fit my workflow and way of thinking. I tried five 3D engines and frameworks, doing their beginner tutorials and buying books if necessary. Eventually I adopted Unity because it was the only one that really made sense to me personally. Later on I bought the PlayMaker plugin for Unity, intending to use it for things like simple AI. Instead, I found that I really liked having drag-and-drop visual coding in addition to directly programming. This influenced my later decision to use GameMaker Studio for 2D games because it has a very similar workflow.
What I Learned From Making a Bad Game
So my first game was a clay pigeon shooting simulation, chosen because it was simple to achieve but still directly applicable to my big FPS idea. I went through a lot of trouble to look up pigeon sizes and weights, shot shell speed and density, pigeon launching angle and pretty much everything else you could think of, and 60 hours later I was left with a physically accurate simulation of clay pigeon shooting.
But the game was no fun at all. Hitting the pigeons was hard, man. You were never really sure how much to lead the pigeons by because the game was randomising the launching angles. The shotgun threw out hundreds of individual pellets whose direction and speed were randomised to get them to spread into a cloud, and sometimes the pigeons would fly through a hole in the shot cloud and emerge unperturbed. Hitting anything felt like dumb luck.
Complete realism doesn't always make a good game.
So I went back and made the whole thing more "gamey". The biggest change was that instead of 400 tiny pellets per shot, I simplified it to eight huge spheres that represented the shot cloud, producing a solid mass that would destroy any clay pigeon it hit, instead of the pigeon being able to escape through random gaps in the cloud. Once this change was made, the game became predictable and fun — or at least, as fun as a simple clay pigeon shooting game can be. You can check out the final game on my website.
Games are smoke and mirrors. It's perfectly fine to cheat to get the intended result.
My First Successful Game
Shortly after finishing my clay pigeon game I decided to take part in Ludum Dare. I had heard a lot about how educational it was to participate in game jams, and this was an excellent test of my skills and work ethic, and a chance to see whether I actually liked making games.
The day before the event I made a list of what I was good at and what I was bad at:
A short list, to be sure! But writing it let me know what I could reasonably expect from myself:
- That it should be array-based, probably a puzzle game, and
- I should avoid humans and animals because I can't animate them, and
- I should go for an abstract or simplistic look, because that's what I am capable of.
When the theme came around I knew exactly what ideas to discard in the brainstorming stage, and what ideas to pursue. I settled on making a color-based puzzle game, and the realistic goals I set myself allowed me to finish early enough to polish the game thoroughly, and my puzzle game Additive finished in the top 5% of entries.
Lessons From My First Successful Game
Making a complete game in a jam environment was an instructional experience, and although it can be scary I recommend it to all newbies. I learned three key ideas from making Additive:
- You need regular feedback at all stages of production. Write every suggestion down.
- Music and sound are half of your game. Many new developers leave them for last, and their games suffer for it. A game that doesn't react aurally to the player's actions feels dead.
- Simple ideas can be very compelling. Additive has only one kind of actor: the colored block. Super Hexagon has a triangle and those horrible damn walls.
There are some miscellaneous tips that I'd like to share. You should absolutely work with some sort of time management scheme. I like the Pomodoro Technique, and love hearing the ticking of a mechanical timer. You should also carry a little notebook and write down all of your game ideas. Ideas will come more easily to you if you allow yourself to entertain even the bad ones. And don't worry about sticking to one art style, or one genre, or one engine. Experiment, see what works for you, put yourself in new situations and really work your creativity!
Finally, I just want to summarise everything I learned when I first started in four words: It can be done. Besides being software, video games are a fusion of every other form of art. You can't expect to be good at it overnight, but you can refine your approach to accommodate your weaknesses and play to your strengths, and you can use what you know right now to create interesting works of your own.
Envato Tuts+ tutorials are translated into other languages by our community members—you can be involved too!Translate this post