# Learning C With Game Concepts/Printable version

The current, editable version of this book is available in Wikibooks, the open-content textbooks collection, at
https://en.wikibooks.org/wiki/Learning_C_With_Game_Concepts

# Introduction

    This book attempts to introduce the C Language to new users while making the learning process interesting and giving them code to play with and modify as they continue educating themselves. The author of this book is a novice C programmer, writing for beginners, so I may not always use the best practice. Users who are interested in a more indepth understanding of the C language are recommended to check out the excellent C_Programming Wikibook.

## Code Disclaimer

    I'm new to sharing code with others, so I feel I should state that the code included in this Wikibook is generated by the author and any resemblance to code out in the wild is not intentional unless it is something basic like the implementation of a data structure (linked list, heap, etc).

## Work Environment

This book recommends beginners use a Linux distribution, such as Linux Mint or Ubuntu. Although I'm unfamiliar with C programming on Windows, Microsoft's Visual C++ compiler should be able to compile C code, if it is available to you. The C language is easy to start learning in the Unix/Linux environment because the Gnu C Compiler (GCC) is included by default on most distributions. GCC is a command line utility that transforms C source code into machine instructions (binary). For writing your code, you'll need a Text Editor or Integrated Development Environment (IDE). An easy to use IDE is Geany, which you can find using your package manager on Linux.
Text Editors can be as basic as notepad or as complex as Vim and Emacs.

## A Basic Program

Let's cover variables and standard IO in one fell swoop.
intro.c
Before we compile this, let's review what our code does.

### Header Files

The #include statement at the start of the program lets the compiler know that we want to use a library. Libraries in C are called Header files and end in the ".h" file extension. The C language contains standard libraries to perform all sorts of common tasks. STDIO, as the name implies, contains various functions for printing and reading.

### Main Function / Statements

At the heart of every C program is the Main function. It contains the body of the program and is the first function called when the program is started. All functions follow this syntax:
A statement can be a variable declaration ( x = 100; ) or a function call ( CallingFunction; ). All statements end with a semicolon and it is good practice to give every statement its own line. It's also important to check your code carefully to make sure you aren't missing any semicolons.

### Data Types

There are 3 basic data types in C that we must use to declare our variables. We declare them using data types so the compiler knows exactly what each variable contains. They include:
* char (example 'a' | a single character)
* int (example 123 | a whole number)
* float (example 12.345 | a fractional number)
In our example we use char, but add brackets and a number after it. The syntax Variable[#] lets the compiler know that instead of a single character, we want an Array (string of characters).

### Input/Output

We are using 3 functions from STDIO: printf, fgets, and sscanf. Our stdin and stdout comes from the command line where we will run the code.
Printf prints a string (as denoted by quotation marks) to standard output. If placeholders are present in the string (%letter) it will also print variables. Fgets reads in a line from standard input and puts it in our variable called Input. Sscanf looks at our variable called input and transfers it over to the variable called name. We'll want to use Input again when we get user input, so we can't leave our information in there or we'll overwrite it!

### Returns

Return statements can return 1 datatype or variable from a function. The simplest example of why we use returns is to see if something is true or false. If you have a function called isCapital and call it on a letter, for example, isCapital('a') we would return(False). If we called isCapital('B'), we'd have our function return(True). The function that called the isCapital function would be designed to make a decision based on the value we returned.
Functions don't need to return a value though. Sometimes you may see 'void' used before a function. This means that the function doesn't return a datatype at all.

### Compilation

Now that we've covered what our code does, let's compile and run it. Navigate to the folder that your C program is contained in. If you are unfamiliar with BASH, you'll need to learn about the cd and ls commands. From the command terminal type:
This command calls the compiler (GCC) to compile Intro.c and output an executable called Intro. If for some reason your file is not set as an executable after compilation, you can type:
To run your executable, type:
That wasn't as simple as printing "Hello World" but hopefully it wasn't too difficult to follow. As you continue reading, things should start to make more sense as you begin recognizing common patterns in programming.

### Experiment #1

Before we move on, take a moment to tweak our Intro program. Declare an int variable called age. Change the first print statement to ask your age and use the integer placeholder %d to print your age in the second print statement.

## A Modular Lifestyle

It would be very difficult to read large programs if we kept all of our functions and variables in one file. Suppose also, that we create a great function and want to use it in all of our programs, how would we do that?
If we want our reusable function to do what our last program did, we just take all the statements from before, put them in a function with a unique name, and place them in a header file.
greet.h
Greet.h can now be included in our program like STDIO, and we don't even need to compile it before using it. The only difference is that instead of sharp brackets <> we use quotes "". If your main program and your header file are in the same folder, #include "Greet.h" is all you need to specify. If they are in different folders, you'll need to provide the fullpath for the compiler #include "fullpath/Greet.h"
main_prog.c
When main_prog.c is compiled, the compiler looks for the header files and includes them in the compilation.
main_prog, the executable, will contain the machine instructions for the main program and the Greet file.

# Designing A Roleplaying Game

Now that we've covered the basics of compilation and modularity (we'll refine that section later) lets move on to game design. Our game will be implemented using the terminal and will not rely on any third party libraries, save for the ones that come with C by default. We'll take a Bottom-Up approach to creating our Role-playing Game (hereafter referred to as an RPG).

## Specifications

When undergoing a new project of some complexity, it is important to do some brainstorming about what your program will do and how you'll implement it. While that may sound painfully obvious, it is often tempting to jump right into coding and implement ideas as they pop into your head. It isn't until the code becomes hundreds of lines long does it become clear that organizing your thoughts is necessary. The initial brainstorming phase takes the main idea, an RPG in this case, and breaks it down into more elementary pieces. For each element, we either break it down into still smaller elements, or give a short summary of how we might implement it. In a commercial environment, this brainstorming session produces a Specification Document.
At the heart of every RPG, we have players.
Players shouldː
* Have stats that tell us about their abilities.
* Be able to interact with each other (i.e. Talking, Fighting)
* Be able to move from one location to another.
* Be able to carry items.
Statsː Easy. Just a variable telling us what the stat is for (like, health) and containing an integer value.
Talkingː To facilitate conversation, players need scripted dialog. This dialog could be stored with the main character, or the person with whom the main character will interact, and in the case of the latter, must be accessible by the main character.
Fightingː A function, that when given a player (to attack) initiates a battle sequence, that persists until someone retreats or a player's health is reduced to 0.
Mapping: A vast and epic journey involves many locations. Each location node tells us what the player sees once he reaches that location, and where he can go from there. Each location node has the same structure. This new node will be structured the same as the first, but contain different information. Each location node is assigned a unique location ID that tells the computer where another location node can be found. "Where he can go" is traditionally an array of up to 10 location IDs, to allow the player to go up to 10 directions -- up, down, north, south, east, northeast, etc.
Movingː A player should contain a node for a linked list or binary tree. The first location ID tells us where the player is currently. The second location ID tells us where the player came from (so players can say "go back"). Moving will involve changing the player's location (Swamp, let's say), to the location ID of another node (Forest). If that sounds confusing, don't worry, I'll make pictures to illustrate the concept. ː)
Inventoryː Inventory will start out as a doubly linked list. An item node contains an item (Health Potion), the number of that item, a description of the item, and two links. One link to the previous item in the list, and a second link to the next item in the list.
This preliminary specification acts as a blueprint for the next phase, the actual coding portion. Now that we've broken the main idea into smaller elements, we can focus on creating separate modules that enable these things. As an example, we will implement the player and player functions in the Main file for testing. Once we're positive that our code is working properly, we can migrate our datatypes and functions into a Header file, which we'll call whenever we want to create and manipulate players. Doing this will significantly reduce the amount of code to look at in the main file, and keeping player functions in the player header file will give us a logical place to look for, add, remove, and improve player functions. As we progress, we may think of new things to add to our specification.

## Player Implementation

Because a player is too complex to represent with a single variable, we must create a Structure. Structures are complex datatypes that can hold several datatypes at once. Below, is a rudimentary example of a player structure.
Using the keyword struct, we declare a complex datatype called playerStructure. Within the curly braces, we define it with all the datatypes needs to hold for us. This structure can be used to create new structures just like it. Let's use it to make a Hero and display his stats.
player.c
Let's review what our code does. We've included a new standard library called <string.h> which contains functions that are helpful in working with strings. Next, we define the complex datatype playerStructure and immediately declare a playerStructure called Hero right after it. Be aware, the semicolon is always necessary after defining the struct. Unlike higher level languages, strings cannot be assigned in C using the assignment operator =, only the individual characters that make up the string can be assigned. Since name is 50 characters long, imagine that we have 50 blank spaces. To assign "Sir Leeroy" to our array, we must assign each character to a blank space, in order, like so:
name[0] = 'S'
name[1] = 'i'
name[2] = 'r'
name[3] = ' '
name[4] = 'L'
name[5] = 'e'
name[6] = 'e'
name[7] = 'r'
name[8] = 'o'
name[9] = 'y'
name[10] = '\0' // End of string marker
The function Strcpy essentially loops through the array until it reaches the end of string marker for either arguments and assigns characters one at a time, filling the rest with blanks if the string is smaller than the size of the array we're storing it in.
The variables in our structure, Player, are called members, and they are accessed via the syntax struct.member.
Now our game would be boring, and tranquil, if it just had a Hero and no enemies. In order to do add more players, we would need to type "struct playerStructure variableName" to declare new players. That's tedious and prone to mistakes. Instead, it would be much better if we had a special name for our player datatype that we could call as wisfully as char or int or float. That's easily done using the keyword typedefǃ Like before, we define the complex datatype playerstructure, but instead of declaring a playerStructure afterward, we create a keyword that can declare them whenever we want.
player2.c
There is still the problem of creating players. We could define every single player who will make an appearance in our game at the start of our program. As long as the list of players is short, that might be bearable, but each of those players occupies memory whether they are used or unused. Historically, this would be problematic due to the scarcity of memory on old computers. Nowadays, memory is relatively abundant, but for the sake of scalability, and because users will have other applications running in the background, we'll want to be efficient with our memory usage and use it dynamically.
Dynamically allocating memory is accomplished through the use of the malloc, a function included in <stdlib.h>. Given a number of bytes to return, malloc finds unused memory and hands us the address to it. To work with this memory address, we use a special datatype called a pointer, that is designed to hold memory addresses. Pointers are declared like any other datatype, except we put an asterisk (*) in front of the variable name. Consider this line of codeː
This is the standard way of declaring a pointer and assigning it a memory address. The asterisk tells us that instead of declaring a player, with a fixed, unchangeable address in memory, we want a variable that can point to any player's address. Uninitialized pointers have NULL as their value, meaning they don't point to an address. Since it would be difficult to memorize how many bytes are in a single datatype, let alone our player structure, we use the sizeof function to figure that out for us. Sizeof returns the number of bytes in player to malloc, which finds enough free memory for a player structure and returns the address to our pointer.
If malloc returns the memory address 502, Hero will now point to a player who exists at 502. Pointers to structures have a unique way of calling members. Instead of a period, we now use an arrow (->).
Remember, pointers don't contain values like integers and chars, they just tell the computer where to find those values. When we change a value our pointer points to, we're telling the computer "Hey, the value I want you to change lives at this address (502), I'm just directing traffic." So when you think of pointers, think "Directing Traffic". Here's a table to show what pointer declarations of various types meanː
| Declaration | What it means. |
| char *variable | Pointer to char |
| int *variable | Pointer to int |
| float *variable | Pointer to float |
| player *variable | Pointer to player |
| player **variable | Pointer to a pointer to player |
Now that we're using pointers, we can write a function to dynamically allocate players. And while we're at it, let's add some new ideas to our specification.
Players shouldː
* Have stats that tell us about their abilities. DONE
* Be able to interact with each other (i.e. Talking, Fighting)
* Be able to move from one location to another.
* Be able to carry items.
* Have classes (Warrior, Mage, Ranger, Accountant) NEW
** Classes have unique stats when they are created. Exampleː Warriors have high health, mages have low health. NEW
dynamicPlayers.c
Before we move on to the next major development, you'll want to modularize what you've written. Start by making two header files, one named "gameProperties.h" and another called "players.h". In the game properties file, place your playerStructure and classEnum typedefs. The datatypes defined here will have the possibility of appearing in any other headers we may create. Therefore, this will always be the first header we call. Next, all functions related to creating and modifying players, as well as their prototypes, will go in our players header file.

### Fight System

Rome wasn't built in a day and neither are good fight systems, but we'll try our best. Now that we have an enemy we are obligated to engage him in a friendly bout of fisticuffs. For our players to fight, we'll need to include two additional stats in our player structure, Attack and Defense. In our specification, all that our Fight function entailed was an argument of two players, but with further thought, lets do damage based on an EffectiveAttack, which is Attack minus Defense.
In the gameProperties header, modify playerStructure for two more integer variables, "attack" and "defense".
gameProperties.h
In the players header file, modify the case statements to assign values to the attack and defense attributes.
players.h
Finally, include your header files in your main program. Instead of sharp brackets <> we use quotation marks instead. If the headers are located in the same folder as the executable, you only need to provide the name. If your header file is in a folder somewhere else, you'll need to provide the full path of the file location.
Let's also develop a rudimentary fight system to make use the attack and defense attributes.
player3.c
If we run compile and run this we get this outputː
TODOː Adjust class stats to something more diverse.
Now that we've figured out how to deal damage, lets expand on our earlier specificationː
Fight shouldː
* Loop until someones' health reaches zero, retreats, or surrenders.
* Display a menu of options to the user before getting input.
** Attack, Defend, Use Item, and Run should be basic choices.
* Tell us if we gave the wrong input.
* Give both sides a chance to act. Possibly by swapping the memory address of the Attacker and Target.
** This means that we'll need to distinguish between the User's player and non-user players.
** We may need to revise the swapping idea later if fights involve more than two characters. Then we might use some kind of list rotation.
*** Games that use speed as a factor (Agility), probably build lists based on stats before the fight to determine who goes first.
I'll refrain from posting the whole program when possible but I encourage you to continue making incremental changes and compiling/running the main program as we go along. For the battle sequence, we will modify the Fight function to loop until the Target's health reaches 0, whereupon a winner is named. A user interface will be provided by a "Fight Menu" which will pair a number with an action. It is our responsibility to modify this menu as new actions are added and make sure each individual action works when called.
When the User chooses an action, the associated number is handed to a Switch, which compares a given variable to a series of Cases. Each case has a number or character (strings aren't allowed) that is used for the aforementioned comparison. If Switch finds a match, it evaluates all the statements in that Case. We must use the keyword break to tell the switch to stop evaluating commands, or else it will move the to next case and execute those statements (sometimes that's useful, but not for our purpose). If Switch cannot match a variable to a case, then it looks for a special case called default and evalutes it instead. We'll always want to have a default present to handle unexpected input.
Testing the integrity of the program requires running it a few times after compilation. First we can see that if we enter random input like "123" or "Fish" we invoke the default case and are forced to pick another answer. Second, entering 2 will cause us to run away from the fight. Third, if we continue to enter 1, eventually Sir Leeroy will whittle down all of Sir Jenkin's health and be declared winner. Modifying the attack value on Sir Leeroy can help if you're impatient ː)
However, Sir Jenkins is still unable to defend himself, which makes for a very unsporting match. Even if Sir Jenkins was given a turn, the user would still be prompted to act on his behalf. The turn-based problem is solved by the idea proposed in the specification, that we swap the memory addresses of the Attacker and Target pointers on each loop. The solution to the problem of autonomy is to add a new property to our player structure, namely, a bool. A bool has a binary value, true or false, and, for us, it answers the simple question "To Autopilot or not to autopilot?". With the autopilot bool set to true, the Fight function, when modified by us to check for it, will know that they must automate the actions of these characters. To use bool datatypes, we need to include a new header called <stdbool.h>. Bools are declared with the bool keyword and can only be assigned true or false values.
Add the following line underneath int defense in your playerStructure from the "gameProperties.h".
Next, add this snippet of code to the NewPlayer function from the "Players.h" below the call to SetName.
The above code creates a persistent variable using the keyword static. Normally, once a function is called, the local variables disappear. By contrast, static variables maintain their value beyond the life of the function, and when a function starts again, it's value isn't reset. Autopilot is only turned on for players created after the first, main character.
That done, consider the following program. We've added our bools and IF statements to determine whether the player needs automating or prompting. The victory IF is moved inside the while loop, and declares victory if the condition is met, else, it swaps players for the next loop.
player4.c
Now that we've created a very rudimentary system for fighting, it is time once again to modularize. Take the Fight and DisplayFightMenu functions and put them in a new header file called "fightSys.h". This new header will contain all functions related to fighting and will be included in the next iteration of our Main program.

# Inventory System
### Inventory System

There is nothing quite so satisfying as equipping one's character. Most of the time, you start out at level 1, wearing rags and shackles. After being released from the local dungeon for one reason or another, you meet a Haberdasher with a heart of gold. He gives you some odd jobs so you can earn enough copper to eat. After weeks of punching things, fetching things, running from things, and still without two copper pieces to scratch together, you at last come across the "Unremarkable Sword of Rusty Might". Huzzahǃ It nothing compared to what the City Guard is using, but now those sewer rats shall feel your wrath. So let's get to itǃ
An Inventory Shouldː
* Contain a list of items.
* We should be able to ADD and REMOVE items from the list, as well as FIND items.
* Similar items should be aggregated. When a similar item is added, quantity is increased, not list size.
* Players should have their own inventory, as should chests and other containers.
An Item Shouldː
* Have a name and description.
* Health and mana.
** These are the restorative properties of potions. 20 Health heals 20 health points if consumed.
* Similar items should be aggregated. When a similar item is added, quantity is increased, not list size.
* Have the option of multiple uses.
* Have an ID that uniquely identifies it.
Putting the above specification into practice, we start by defining the kinds of items available, via an enumeration. In the future, we may want to import a list of items from a file, rather than keeping all of them with our source code. However, it's best to keep things small for testing purposes.
Each item that we create will be embedded in an item node. A node is a single unit which can be linked to other nodes in order to form a data structures such as lists and trees. In this case, the data structure is a doubly linked list. As you can see, the itemNodeStructure points forwards, backwards, and to its own item. When defining the itemNodeStructure, it is necessary to use "struct itemNodeStructure" to declare the pointers because the itemNode typedef is not yet in effect and the compiler will not understand.
Going back to ye olde playerStructure datatype, we add a new value to it.
Because the functions required for a basic inventory setup are somewhat involved, it cannot be broken up into more digestible pieces. My code is very likely not the most elegant solution to the problem, so there is room for improving the clarity. For now, if you want to understand how the functions for the inventory work, you'll need to read through the comments until you can identify what each piece of code is doing.
inventory.c
inventoryFinished.c