We will now take a closer look at the architecture of Canyon Bunny. A so-called class diagram is used to help us visualize and explain the architecture in a standardized and structured form. The class diagram is illustrated as follows:

In this class diagram, you will find a lot of classes that will be used in this game. It also shows important information about the kind of classes and how they are interconnected. Firstly, before we continue, don't be scared of all these boxes, lines, and arrows pointing in every direction. If you are not familiar with reading class diagrams or UML in general, take a look at the following section for a quick explanation of what you should know to be able to read it. Otherwise, simply skip to the next paragraph to continue.

Each class is represented in a rectangle. If it is a special kind of class (a stereotype in UML), it is indicated in double angle quotation marks above its name, such as "abstract" for an abstract class or "interface" for an interface. Lines are used to show the relationship between two classes.

A line without arrows designates a bidirectional relationship between two classes, meaning that they depend on each other in order to work correctly. If there is a line with a filled arrowhead at one end, it means that the class that points to the other class needs it to work properly and not vice versa. On the other hand, if there is a line with an unfilled arrowhead at one end, it always points from an implementing class (specialization in UML) to its super class (generalization in UML), which can either be an interface or an abstract class.

Lastly, there are numbers to describe the multiplicity or, in other words, how many instances of an object will exist from one class in another. The syntax for this is as follows:

You should now be able to read the information in the class diagram.

At the top of the class diagram, you will see CanyonBunnyMain. It is the starter class of the game and therefore necessarily needs to implement the ApplicationListener interface provided by LibGDX. It holds a reference to an Assets class that will be used to organize and simplify the way to access the game's assets. There are two more references pointing to WorldController and WorldRenderer.

The WorldController class contains all the game logic to initialize and modify the game world. It also needs access to CameraHelper—a helper class for the camera—that, for example, enables it to target and follow any game object; Level that holds the level data; and a list of AbstractGameObject instances representing any game object that exists in the game world.

The rendering takes place in WorldRenderer that apparently also requires it to have access to the list of the AbstractGameObject instances. As the game objects need to be created before the process of modification and rendering, Level needs access to the list of the AbstractGameObject instances as well when a level is loaded from a level file at the beginning of the game.

What is still left is the bottom row of classes in the diagram, all of which point to the abstract class: AbstractGameObject. They all implement a specialized type of this class, and thus share a common functionality of being a general game object that can be rendered in the game world. Furthermore, these classes have been grouped in this diagram to indicate their purpose in this game. You might want to peek at the end of Chapter 1, Introduction to LibGDX and Project Setup, again and take a quick look at the sketch that shows all the relevant game objects in one picture. Here is a brief description of the grouped classes:

These classes will be covered in much more detail from Chapter 4, Gathering Resources, to Chapter 6, Adding the Actors.