214: How To Start Building a Video Game. Part 4.

Take Up Code - Un pódcast de Take Up Code: build your own computer games, apps, and robotics with podcasts and live classes

Categorías:

You can take advantage of libraries and frameworks. Listen to the full episode to learn how libraries are different from frameworks and where game engines fit into all this. You can also read the full transcript below. Transcript Don’t try to do everything yourself. There’s some really good libraries and frameworks that you can use for free or pay only when your game is successful. Again, this applies to any software project. If there’s code that you need to write to get your project to do something interesting, then there’s a good chance that somebody else has already written the code that you can use. Need to play some sound effects during your game? There’s code available to do that already. Need to connect your game to other computers or to server computers to coordinate multiple players? There’s code for that already. Need to load image files and draw the images to the screen. Yep, there’s definitely code for that already. This is the type of code that you don’t want to be writing anyway. It has nothing to do with the specific story in your game. It has nothing to do with how your game is played. Or what rules you decide are important. You need to be focused on the things that make your game unique and fun to play. There’s enough work for that already. Avoid writing code that not only has somebody else already written but has probably done a better job. Now, that’s not to say you couldn’t do just as good of a job. but there’s usually a lot of little details involved that we don’t normally think about until that becomes our focus. None of us has the time or energy to become expert in everything. I might have told this story before but it fits well here. I used to have a book about electrical engineering. It was an old book from the early 1900’s. I forget now if it was 1913 or maybe 1906. Somewhere around that time. The interesting thing is that this book contained all the world’s knowledge about electrical engineering at that time. There was even a chapter about how to pour concrete! I studied electrical engineering in college and I can saw that there were no classes about concrete or general construction. But back in the early 1900’s, knowing how to pour concrete was needed for electrical engineers when placing utility poles in the ground. Or maybe when anchoring transformers to the ground. Today, there’s no way a single book can cover a broad subject such as electrical engineering. There’s too much for a single person to learn at all no matter how many books are involved and no matter what topic. We have to specialize. We have to pick a narrow niche and become really good at that one thing. When it comes to programming, niches such as sound processing, video processing, and networking all have experts who’ve studied the problems and have written libraries that hide all the details so it looks easy from the outside. That’s perfect. If you try to do all this yourself, you may not finish at all. And if you do, your code probably won’t be able to accomplish nearly as much. And it’ll probably have bugs caused by not spending enough time to learn all the details. When you have code that you include in your project to help you with a focused need such as playing audio in your game, this is called a library. We normally think of libraries as a place containing lots of books. A software library will contain classes and methods you can use in your code just as if you had written the classes and methods yourself. You might need to adapt a little to the author’s way of thinking. Maybe the library names the methods with different uppercase letters than what you use in the rest of your code. Maybe the author has an interesting way of passing method arguments that’s different than your own style. And things get more involved when you start using multiple libraries and each library has its own

Visit the podcast's native language site