Commit to Starting Your First Project

Jun 29, 2012

What this is really about is the need to just get started on something. I had an entry recently on the importance of finishing something, and it occurred to me: maybe the problem a lot of folks are having isn’t that they won’t wrap up what they’re doing, it’s that they won’t stop prototyping, and exploring, and dabbling, and trying different languages, and reading, to get out of their comfort zone and really commit to starting something with some sort of deadline to finish it.

It doesn’t have to be a hard deadline. The key here is tentative planning. It’s all about having something in mind as a target, and changing that target if you have a good reason to. If you come upon an idea that’s going to take more time mid-development, and you feel like it’s a worthwhile tradeoff, by all means go for it. But you’ve got to start with something.

Now of course the flip side is you may feel worried about having not found the right idea yet. The very first tentative deadline you can set for yourself is when you’re going to commit to an idea. How long are you going to give yourself in that exploratory phase? A week is probably perfectly reasonable. If you’re busy, if you’re holding down a full-time job, if you’re currently taking classes, you know, give yourself maybe a couple of weeks. Obviously there’s no real pressure on this, you don’t have to rush it, or give yourself 24 hours, or think of it right now.

The game doesn’t have to be great. The game doesn’t have to be amazing. The game doesn’t have to change or revolutionize the industry. It is entirely OK to accept that it will not be the last game that you work on, to accept that you are doing it to learn something, and that that’s going to be sort of the point of it.

You should still finish it, because you don’t want to practice not finishing. You will learn a lot more from the final what you might think is 10% of the game but turns out to be 50% of the time, when you’ve got to make hard decisions about what to cut and what to keep. You’ve got to make sure the game is self-explanatory to strangers. All of those little bits and pieces when you have to tie them up you’ll learn a lot more about how to plan and scope your next projects. It’s really critical to get that finishing in, even if it’s a project for learning.

Consider making that first game a clone. I know I make this suggestion often, but it really is a great way to start, to make a 70’s or early 80’s-era clone: Pac-Man, Space Invaders, Breakout, Tetris, or so on, as your first game attempt. It gives you a way to decide whether or not what you’re working on is the way it’s supposed to be, and a way to pay attention to those little details that professionals came up with that in many cases stood the test of time or held up to popular markets. If you’re just working in your own space it’s really hard to get that sort of critical feedback.

Don’t stress yourself over doing something that has never been done before. I hear that sometimes when I suggest cloning to learn. They’ll say, that game exists, the world doesn’t need another Pac-Man, the world doesn’t need yet another Space Invaders game. But every worksheet you ever filled out, the teacher knows the answers. Every book report you’ve ever done, someone else has read that book before. Every problem set you do, every intro assignment you do has been done before. The point isn’t to do it for the outside world, the point is to do it for you. If you personally have not yet had those experiences, there’s value to the learning process of you going through that on your own. That’s what I’m advocating when I’m saying to do these things that aren’t necessarily for the world at large. They’re for you to come away different for having built it, to be better prepared for your next project.

What you do need to do now is give yourself a time frame, for by when you’re going to have that idea that you’re going to work on, then you’ve got to write it down. You’ve got to put it down somehow just so it doesn’t stay all nebulous in your head. You don’t have to put it down in detail–you guys and gals probably know if you keep up with other HobbyGameDev stuff that I’m no fan of big design documents. But we’re talking half a page to a page of what it is you’re trying to do, what’s sort of the central feature that is going on there, what you think is good about it, what platform you’re developing it for, and then just get rolling.

Of course after you start, after you commit to the idea, your next tentative deadline is going to be how long you’re going to give yourself to develop it. It makes sense to figure that out once you kinda know the game right, after you have some idea what you’re doing.

Put those dates down on paper. Don’t trust it to memory, don’t just leave it in your mind, or they will change every day that you think of them. There’s something magic about putting down on paper or if nothing else on a whiteboard, somewhere for you to see it, somewhere that you will have to actively work to change it. You’ll have to make a conscious decision that if you want to change that you’ll have to pick up a pen or a pencil and mark it out. Don’t just hide it in a text file either, don’t just e-mail it yourself. It will get buried amongst other things, it’s too easy to ignore things that are in digital space. Put it down on paper and you’ll be more likely to hold yourself to it.

I will say if it’s one of your early projects, especially if it’s your very first project, I’m going to say that giving yourself more than a few months may be kind of risky. You want something where you can see the light at the end of the tunnel as soon as you’re starting. Two months is probably on the low end, maybe four or five months is on the high end, I wouldn’t say half a year for your first game.

Simply because: you’re going to learn so much so fast just through the process of developing the application, of figuring out the art, of figuring out the audio and the pipeline. Even just figuring out sense of scope, and gaining an appreciation of… you know you can look at a game, even a commercial game, and as a programmer, know how each and every little feature of that works. You can picture kind of how the motion happens, you can picture in the code what’s going on with items and inventory, input and menus, none of it seems that complicated. But when you start really trying to patch it all together and write it all yourself, and structure it and make a thousand little decisions with everything you’re developing, it can quickly add up. You may find out that the idea you thought would only take a couple of months may actually be the one that needs five or six for you to put something out as your first game.

Commit to a deadline for when you’re going to start–when you’re going to lock in on one thing and stop the shallow dance with a bunch of other ideas and concepts and learning for its own sake. All of that’s important, all of that’s good, but let’s say you’ve got that phase either partly behind you, or it’s time to take a break from that to hone in on a game. Get something behind you and really start to think of yourself as a game developer and not just someone who’s trying to get started at game development.

I would strongly discourage trying to make money from your first effort. It would be a lot like, as I’ve said before, trying to make money from your first dance recital, or your first time playing basketball, or your first time playing guitar, first time singing or writing poetry. It’s just madness to think that the first time you’re doing it you should be worried about ads, or pricing schemes, or distribution channels. Don’t worry about any of that.

Make a game. Make sure it’s something that you and your friends can play. Share it with people. Learn something from it, and you’ll be so much better off for coming up with your second game idea and getting a run on that.



Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.




Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!



All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.