Becoming a programmer isn’t just about learning the syntax and the concepts of a programming language: it’s about figuring out how to use that knowledge to make programs. You’ve made a bunch of programs in this course, in the challenges and projects, but now you should come up with ideas for new programs – ideas that you’re personally really excited about – and try to turn those into actual programs.
You probably won’t know everything you need for your program when you start it, and that’s totally okay — you’ll be motivated to learn those new things because of how much you want to make your program real. Programmers are constantly learning new things for new projects, and that’s part of why we love it so much.
Let’s step through the process of planning a programming project:
1. What do you want to make?
When I first started programming, I found myself constantly thinking of new programs to make and writing those down in a list. I was addicted to the power of creation, and there was so much my brain wanted to make. If you’re like that, then you probably already have an idea of what you want to make, and perhaps you have your own list.
If you don’t already have an idea, then here are some questions to help your brainstorming:
- What’s your favorite game – arcade game, board game, sports game? Could you make a simplified, digital version of that? Could you mix it up a bit, like give it a different theme or main characters?
- What are your other favorite academic fields? If you love art, could you make an art-making program? If you love history, how about an interactive timeline? If you love science, how about a scientific simulation?
- What’s your favorite movie or TV show? Could you make a digital version of a scene or character from it? Maybe make a game based on it?
- What’s a real-life gadget that you love? Could you make a simulation of it?
Once you’ve picked an idea, you should write a description of it. For example, if I decided to make a clone of “Breakout”, because that’s my favorite retro arcade game, I might write:
Breakout: a game where you control a paddle at the bottom of the screen, and you use it to hit a ball upwards and at angles to break bricks. The goal is to break all the bricks, and not let the ball through the ground too many times.
You’ll flesh that description out later, but for now, that gives you a good enough idea to keep going in the planning process.
2. What technology will you use?
In this step, you need to consider which technologies (languages/libraries/environments) you’re familiar with or able to learn easily, and which of them are the most well suited for the job. For many of you, that list may be one item long, “1. JS+ProcessingJS”, and that makes your decision easy.
The environment doesn’t work for other things like multi-player games, mobile apps, data-crunching applications. If you know other languages/environments (like JS+HTML, Python, SCRATCH, Swift, etc) and you’re thinking of building something that doesn’t make as much sense with ProcessingJS, then consider which of those technologies would be best suited for your program. If you want to build those things but don’t know other technologies, you might want to come up with a new program idea. You can learn a new technology for a new project, but especially if you’re just getting started in programming, it’s a good idea to get really good at your first language first.
If I decided to make a game like Breakout, I’d pick JS+ProcessingJS, since I already know that technology and it also works great for 2D games like that.
3. What features will it include?
This is where we get into the real planning, and where (I think) it gets fun. Your goal in this step is to figure out what you’re actually making- what will it look like, what features it will include, what features it *won’t* include.
The first thing you can do is make “mock-ups” – sketches that look like the thing you’re making, but without details like coloring or exact sizing. You can make mock-ups on paper, or with online programs:
To give you an idea of what mock-ups look like, I’ve included mock-ups below of my Breakout clone. I sketched each scene separately and drew arrows between them to show how one scene leads to another. Those arrows will help me understand what logic I need in my program to go between program states.
Now you can use those mock-ups to help you make a feature list, where you think of every feature in your program, and make it into a list.
For my Breakout clone, this could be my feature list, broken down by scene:
4. But what features must it include?
If we all had infinite time to make all the programs in our heads, then they’d all include every feature in our list. But we don’t, so in this step, you have to decide which features are the most important, and which features you’ll do only if we have time. This will also help you figure out which order to implement features in, from most to least important.
To help you figure out the importance of each feature, ask yourself these questions:
- If I shared this with a friend, which features would I want to make sure were working?
- Which features am I the most excited about building?
- Which features are the most unique to my program?
- Which features will I learn the most from implementing?
- Are there any features that seem too far beyond my current skill level?
Then, go through your feature list from the last step, and either order the list or add a rank to each feature.
For my Breakout clone feature list, I’ve put “P1”, “P2”, and “P3” next to the features, signifying top priority (P1), middle priority (P2), and lowest priority (P3). I decided to prioritize the unique game mechanics over general game features like scenes, because I find that the most exciting about this project:
As a general tip for those of you making games, here are features that I’d recommend de-prioritizing: menus, multiple levels, 3D graphics. Focus on what’s unique and fun about your game, then add those extras.
You can also turn your prioritized list into project versions, so you can easily see what you need to implement in each versions, and you can always stop after a particular version and be happy with what you’ve made.
Here’s what the versions would look like for my Breakout clone:
5. How will you implement it?
You now have an idea of what features you’ll be building first in your program – but if you start now, you’ll be staring at a completely blank program with no code written, and that can be intimidating. Which variables should you write first? Which functions?
One way you can figure that out is to think about the “high level architecture” of your program – breaking it into categories like “objects”, “logic”, “user interaction”, “user data”, and “scenes” – and then think about how you might implement them, like as object-oriented object types, functions, or variables.
For example, here’s an architecture for my Breakout clone:
Once you’ve thought about the high-level architecture, it should become more clear what you can start coding first.
You might decide to write your whole program in pseudo-code first, which we talk about later in this tutorial. Basically, it’d mean writing the whole program in plain English text inside a comment, and then slowly turning that into actual code.
6. What’s your timeline?
How much time do you have to make this program? How many weeks, and how much time each day? What features will you write each week? Your goal in this step is to figure out a timeline for your project – which is particularly important if you have a deadline, but also useful so you start to understand how much time it takes you to write a program.
Here’s a timeline for my Breakout clone, assuming 2-4 hours of work each week:
- Week 1: Design and pseudo-code
- Week 2: Rough visuals
- Week 3: Ball moving/collision mechanics
- Week 4: Scoring mechanics
- Week 5: Scenes (Start/Win/Lose)
- Week 6: Polish, Manual tests (QA), Prep for demo
Figuring out timelines for programming projects is hard. Some things that seem easy take way longer than you expect (like some weird bug that you spend hours debugging), some things that seem hard take less time than you expect. As a general rule, assume it will take you longer than you think, and adjust as you go along.
Thanks to khanacademy.org