Basic Principles
Before we string writing the program, you’ll need to know some basic principles. Make sure you understand these before continuing, since the rest of the guide will build on this foundation.
What is a program?
At some point in your life, you’ve probably told someone how to do something. Maybe you gave them directions to your house, told them how to play a game, or shown them how to cook your favorite food.
A program is a lot like a recipe. It’s a set of instructions on how to follow a process, using some objects, to get a result.
For a recipe, the objects could be eggs, sugar, flour, and butter. The process is mixing and baking. The result is a cake.
For a program, the “objects” could be a customer account, an address, and a list of things the customer wants to buy. The process is checking to see if the products are in the inventory and charging the customer’s credit card. The result is a report in the shipping department that says to send out the items to the address.
The instructions you write for the computer is the “source code” of the program. Source code can be written in several different languages, PHP, Perl, Visual BASIC, and hundreds of other ones. We’re using C# to write this program.
The best way to write a program
There are many ways to write a program. Just as there are many ways to make a chocolate cake.
Some may be better, and some may be worse. But many of them will produce a result that is completely acceptable – even though they use different ingredients (objects) and processes. Personally, I’ve been happy with more than 95% of the chocolate cakes I’ve eaten. And I’m sure that they weren’t all made the exact same way.
So, don’t worry about finding “the one true way” to write a program. Concentrate on finding a way that gets you the results you want. As you gain more experience, you’ll learn more techniques, and be able to improve your programs.
We’re going to start with the basics in this guide. It’s not going to be the prettiest, most interesting game ever written. But it will cover the most common things you’ll need to know as you continue programming.
What are objects and classes?
You’ve probably heard the term Object Oriented Programming (OOP). That means your program tries to imitate the real world, by using what it calls “objects”. (There’s more to object oriented programming than that, but this is good enough for us to start with).
When you think about our game, the objects will be things such as the player, swords, potions, giant spiders, etc.
So, what’s a class?
If you’ve ever played a game like Dungeons & Dragons, you may have started out with a character sheet. It’s a blank form that has spaces for you to write your character’s name, their strength, the amount of gold they have, and so on.
But that empty form isn’t a character until you’ve filled in the information.
A class is kind of like that empty form. It’s something that says, “Here is the information that you can have about a character.” It defines the object, but it is not the object.
So, a blueprint of a house would be like a class, and an actual house that you can live in would be an object. A recipe is a class; a chocolate cake that you can eat is an object. The application form you use to open a bank account is the class; your bank account is the object.
In programming, creating an object is called “instantiation”. So, you’d create an “instance” of the character class, and then you’d have a character object.
What can you do with these objects? We’ll get to that next.
What is procedural code?
Procedural code is the part of the program that does things with the objects – in some sort of procedure/process.
In the game, when the player moves to a new location, you’ll have procedural code check if they are allowed to enter the location (maybe they aren’t high enough level, or don’t have a required key to open a door). The code will also check if there are any monsters there, and, if there are, start the procedure to let the player fight the monster or flee.
Going back to the “program is a recipe” metaphor, most programs actually end up being a cookbook full of recipes. You have one recipe (procedure) for what the program should do when the player drinks a potion, another for when they buy items at the store, another for fighting a monster, and so on.
An important thing to remember, when you write procedural code, is to keep things as simple as possible. There are a couple of reasons for that.
First, the more code you write, the more likely you are to have a piece of code with a problem in it.
The simpler something is, the less likely it is to have problems. If you’re like me, you may remember when cars didn’t have computers. Back then, if you had a problem with your car, it was much simpler to track down and fix. Nowadays, you need an expensive specialist, with special equipment, in order to diagnose the problem. Don’t write programs that can only be fixed by expensive specialists.
Side note: Almost every time I see a long, complex procedure, it’s because the programmer didn’t understand what they wanted to do (logic-wise), or they didn’t understand the language the program was written in.
If you ever see yourself writing a long piece of procedural code (let’s say anything more than 40 or 50 lines), stop writing. Take a minute to think if there is something you don’t understand. Figure out what you need to understand, and then go back to writing the (simpler) procedure.
Second, a program is more than a bunch of instructions you want a computer to perform. It’s also something that another programmer may need to read, and understand, in the future.
I’ve worked on programs that were written many years before I even started working at the company. Dozens of programmers modified the program over several years. They’ve added new reports, new information that needs to be recorded, and changed the business rules. Then, I need to add a new feature to the program. If the program is a huge, complex, and difficult to understand, it’s more likely that I’ll break something when I make my change. But simple code is easy to change.
So, for the sake of future programmers who may need to change your program (and that includes you too, when you look at your program for the first time in six months), do the simplest thing that works.