The Nitty Gritty

I realize that I may have skipped some valuable explanation with my last post. Here I am blabbering on about my performance issues like a senior at his annual checkup and you have no idea how my code works! If you're going to read these articles then understanding the architecture of my code is going to be important. Luckily for you, I'm here to set things straight.

The Initialization

These are the first lines of code that are executed in the game. This comes before the game loop and any other process. Here I load files from my computer in order to make the game work and set up variables that I may need to use later on. For example, the clock I use for my FPS counter is initialized in this step.

The Game Loop

Maybe I'm too literal.

Here's where the fun part starts. Unless you find loading fonts fun and assuming "Wanderer" resembles something enjoyable in it's finished product.

This is where the "game" part of the game comes in. This is the point where I register your keystrokes, mouse clicks, etc., use your input to manipulate variables and render images to the screen. This done through a series of classes.

Quick lesson - If you know what a class is, skip this part. - A class is a collection of variables and functions... wait...

Okay, quicker lesson - If you know what a function is, skip this part. - functions are very self explanatory. They are grouped lines of code that can be used at any time to do a specific task. Sort of like the chorus of a song. When you need the function called "chorus" you use chorus() and the chorus of the song gets played.

...Back to classes. A class is a collection of variables and functions that are all associated with each other under a name. The idea is generally that it creates the properties and actions of a specific object in your code. For example, you can have the class "car" which has the function "start_ignition" and the variable "paint_colour" You can create many unique instances of the class which will all have the same variables and functions but will have different values assigned. For example, if I want a red Mazda (sponsors?) I can create the instance of the class referred to as "Mazda" and assign "red" to "Mazda.paint_colour"

The Major Players

These are the main classes that are used (as of right now) and how they interact with each other.

a) The Player class.

This is the class that contains all of the information for the player. As of right now, that's primarily x and y positions as well as the image (sprite) but in the future the stored information will include health points, hunger, etc. This class contains an "act" function which, when called, checks what the player is doing and changed the variables accordingly. For example, if the player is pressing the "a" key, the act function checks if it's about to collide with a wall (more on this later) and if not, subtracts one from the x coordinate. This moves the player left.

b) The Block class.

This is the class that contains all of the information for the wall segments. Mostly just x and y but also the sprite. Maybe more in the future?

c) The Zombie class (future)

This contains all of the information for the zombies. It will mostly be similar to the Block class but will also contain brain craving subroutines.

d) The controller class.

This class contains all of the game state information. It contains all of the wall positions, player positions, eventually zombie positions. Every time any object wants to interact with any other object, it's going to go through this class.

When the player class checks for collisions, it sends it's coordinates to the controller class and the controller class checks the position it wants to move to for an obstructing object. If the check returns false, that means there is no object in the way and the Player is free to move. If the check returns true, that means that the Player can not move to where it wanted to.

In the future, this class will contain all information not directly related to the Player, Zombie, Wall or whatever class. This includes score, and level generation.

So there you have it. That's the basic architecture of the game as it stands right now. I might do a bit of an update and make this a sort of map to the code.

My current plans are to get the collision detection working for more than just stationary objects, then add some zombies to be collision detected!