Module 2: Programming & Design Basics (Lessons 2)

Lesson 2 Transcript

So what is a game programmer?

Well, they’re the ones who create something out of nothing. Nothing happens in the game without the programmer first being the one to code it in.

This role is all about solving problems through code. They’re going to write the code for the player to jump, move, attack, interact, use the menu and everything else that the game consists of.

Usually what this looks like is the programmer typing out some code, figuring out exactly what they want to happen, trying to run it, have it fail, and then debugging it, which is the process of figuring out why it didn’t work and then getting it to do exactly what you want.

That is a very common loop when it comes to programming and game programming specifically, and that’s because rarely does code work the very first time you type it in. It requires a lot of trial and error, research, experimentation, and just figuring out exactly what you have to do to get it to work the way you want.

(01:08)
It’s kind of like a logic puzzle through code, which is how I look at it. And for me, that’s kind of what makes it fun.

In a small company or by yourself, the programmer might actually be the one to code the entire game. Everything from movement to the physics to the menu and how it works and interacts, and sometimes that’s a really great benefit.

That means when something goes wrong, that person who coded it now knows probably exactly where to go to fix that issue. Fixing it itself is a totally different thing, knowing where something is and how to fix it.

Two separate issues, but the benefit of having just one programmer code the game is really substantial, but it also means that it’s going to take longer and if you want to make any changes that one programmer has to go and make those changes.

(01:59)
Instead of building out more of the game.

In a larger company, the programmer is going to be set upon specific tasks. You’re not going to be able to just code whatever you want. The game is going to be broken up into dozens or hundreds or maybe thousands of different pieces that have to be done by individual programmers.

So that means you may tackle a little bit of the movement, a little bit of physics, maybe how the menu is going to be worked in the background or something like that. You work on it, you get it just right, and then you merge your code into the larger base and make sure that it works there. Do we any debugging?

And if it’s all good, then you go and pick up another piece of the game and you start working on that. This really improves efficiency as it allows many programmers to work on one game so that you can get it done faster.

But it also comes with the risk of having more problems and being able to solve those problems becomes much more difficult because it’s not just one program

(02:58)
Or everything. Now multiple programmers have to come together, talk, figure out what might’ve caused it, and be able to communicate exactly what they were trying to do, what they did and what’s not working now. So there is a possibility of increased efficiency, but there’s also the possibility of increased problems.

But a lot of that is managed through the project manager and making sure that communication is going well and that they have steps in place to figure all of that out, which is a totally different subject.

Just thought it would be worth mentioning, but whether you are a solo game developer or part of a team, your time is going to be spent coding and then probably the most part of your time is going to be spent debugging.

It is finding out what’s going wrong or what’s not working exactly the way you want it to and fixing it.

(03:50)
And really, I have to stress this is it is a lot of it going to be debugging.

Unless you’re doing something you’ve already done and know how to do, you’re going to fail when you first start writing code, and that’s just natural. It’s okay. I fail all the time when I’m writing code, even doing things I’ve done before, which is kind of sad, but just part of the gig.

Programmers have to have a lot of knowledge. But the thing is, we don’t memorize it all. We learn how to look it up, store just little bits that are essential and then figure out where to find it later on.

And so that means when we try and do something, it requires research, trying it out, debugging, and then finally getting it fixed and moving on to the next problem.

Like I said, it’s kind of like a logic problem.

(04:40)
And if you like logic puzzles and you like solving things like that, then coding is probably something that you’re really going to enjoy. And in this course we’re going to solve a lot of those logic puzzles.

The first couple games that we make, I’m going to walk you through exactly what to do and how it works. And then in the last one, I’m going to show you what it’s more like to be a programmer working on your own.

I’m going to make mistakes. We’re going to find bugs that we didn’t know were there and have to fix them on our own. And I hope you’re really excited about it.

If you’re not interested in being a programmer, but you want to be a game designer, this part is still really important because as a game designer, when you assign a task to a programmer, you can’t really know how fast they can get it done.

And that’s because you may ask them to do what you think is something simple, but is actually much more complex and requires a lot more time and leniency from you, the one who’s assigning the task.

So this will not only benefit the programmer who’s taking this course, but also the designer. So with that all being said, let’s go ahead and jump into the software we’re going to be using and get an overview of GameMaker Studio 2.