yego.me
💡 Stop wasting time. Read Youtube instead of watch. Download Chrome Extension

Games and modularity | Intro to CS - Python | Khan Academy


3m read
·Nov 10, 2024

So you want to build a game, but how would you even get started? Most games we play have thousands of lines of code; some even have millions. Try and imagine a program with thousands of lines of code all in a single file. Sounds like a nightmare to navigate and nearly impossible to debug.

So how do programmers do it? We use a strategy that in programming we call modularity. Or in simpler terms, we break down the problem. Say I want to build a cozy role-playing game; what might that entail?

Well, I can kind of break that down into different categories of activities. Like there's farming, fishing, mining, crafting, and then within each of those categories, I can break it down further into the different actions players might take. So within farming, you might be able to plant, fertilize, water, harvest, maybe trample.

Once I have that breakdown mapped out, I can focus on solving each individual sub-problem in isolation, one at a time, instead of trying to juggle all the pieces of the game at once. For example, maybe I start off by thinking about what it means to harvest, and then I write the code for that small piece of the game. Like maybe the plant returns a random number of vegetables based on how well the player cared for it over its lifetime.

Notice how that small sub-problem was a lot easier to tackle than the bigger problem of building the farming mechanics, and way easier than the big problem of building a role-playing game. By breaking down the program into modular components like this, programmers get a lot of benefits.

For one, it allows them to easily collaborate with other programmers. One team can own the farming component, and another team can own the fishing component. And within farming, I can work on harvesting, and my teammate can work on planting. We'll have to integrate the different components eventually, but for now, it's easy for me to focus on my task without having to worry about conflicting with my teammate's code.

Two, it makes the code much easier to test and debug. If I gave you the whole program and asked, "Does this game work?" I bet you'd have a real hard time giving me a definitive answer. But if instead I gave you a real small piece of code and asked, "Hey, does this harvesting code work?" you could probably verify that without a horrible amount of effort. If we've tested all the smaller components as we built them, we can have a lot more confidence that the final product works.

It's kind of like a mechanic working on a car. To check if there's any issues, they don't just take the car out and drive around for hours until something breaks down. Instead, it's much easier for them to test the individual components. They can check that the brakes work, the transmission works, the HVAC works, and if all the individual components work, then there's a good chance the whole car works, too.

Three, it makes the code a lot more readable and easy to work with. Instead of one giant mess of code, we've organized it based on task, which makes it easier to find what we're looking for when we need it. Typically, when we modularize a program, we organize it into different modules, where each module or file contains the code for a related set of functionality.

Then, within a module, we break down that functionality into individual functions, where each function contains the instructions for performing a specific task. So in our farming module, we might have a function called Harvest that contains the lines of code needed to perform the Harvest action, and then we might organize the planting-related code into a Plant function.

Now we've probably seen modules and functions before when we've used the ones that other people have written. Like the Random module collects a bunch of functionality related to randomness and organizes that into functions like rand. As we write programs that get bigger and more complex, we need a way to organize our code, too, so we're not left with a single main.py file with a giant mess of code.

That means it's time to learn how to write our own functions in our own modules, so we can make our code more reusable, testable, and maintainable. So let's get organized.

More Articles

View All
Laser Month! Week 2 - Laser vs Balloons - Smarter Every Day 35
Is it hitting the brick wall? (Johan) It’s hitting the brick wall. (Destin) We’re not gonna set your house on fire this time? -no -I’m not gonna get through a brick wall, definitely not. (Destin) Hey, it’s me Destin. We have a class 4 laser. We’re in Hol…
The Secret Life of Plants | Podcast | Overheard at National Geographic
I’m looking at what you might call a classic National Geographic image. It’s a scene of one of the rainiest places on earth in its monsoon season. It’s somewhere deep in a rainforest. There’s a lush tapestry of thin brown tree trunks and rich green leaves…
Using a confidence interval to test slope | More on regression | AP Statistics | Khan Academy
Hashem obtained a random sample of students and noticed a positive linear relationship between their ages and their backpack weights. A 95% confidence interval for the slope of the regression line was 0.39 plus or minus 0.23. Hashim wants to use this inte…
Lecture 3 - Before the Startup (Paul Graham)
That short. Like, long introductions are no good. Sam knows. Alright, ready, everybody? I’m not gonna ask if the mic is working like in every talk so far. I’ll just assume it’s working. No! No, fuck! All right, well make it work somebody. It works, …
Bill Belichick & Ray Dalio on Bill's Most Important Principles: Part 1
Bill, what are your main principles for success? Do your job, work hard, pay attention to details, and put the team first. I think they are the principles for all organizations. I think, ultimately, improvement should be putting the team first, improving…
YC SUS: Kat Mañalac and Eric Migicovsky discuss Week 2 SUS Lectures
Good morning everyone, and good evening. It could be anywhere actually. I’d like to start somewhere. My name is Eric, and I’m the facilitator, of course, facilitator here at Startup School. It’s a pleasure to be joined by Kat. “Hi everyone, I’m Kat, a pa…