Graphics Reference
In-Depth Information
In terms of this topic as a cookbook, think of the framework as a base soup and the
scripting components as ingredients. We can mix and match script components from dif-
ferent games that use the same framework to make new games, and we can share several of
the same core scripts in many different games. The framework takes care of the essentials,
and we add a little “glue” code to pull everything together the way we want it all to work.
This framework is, of course, optional, but you should spend some time familiarizing
yourself with it to help understand the topic. If you intend to use the components in this
topic for your own games, the framework may serve either as a base to build your games
on or simply as a tutorial test bed for you to rip apart and see how things work. Perhaps
you can develop a better framework or maybe you already have a solid framework in place.
If you do, find a way to develop a cleaner, more efficient framework or even a framework
that isn't quite so efficient but works better with your own code, and do it.
In this chapter, we start by examining some of the major programming concepts used
in this topic and look at how they afect the design decisions of the framework.
1.1 Important Programming Concepts
I had been programming in C# for a fairly long time before I actually sat down and figured
out some of the concepts covered in this chapter. It was not because of any particular prob-
lem or difficulty with the concepts themselves but more because I had solved the prob-
lems in a different way that meant I had no real requirement to learn anything new. For
most programmers, these concepts will be second nature and perhaps something taught
in school, but I did not know how important they could be. I had heard about things like
inheritance, and it was something I put in the to-do list, buried somewhere under “finish
the project.” Once I took the time to figure them out, they saved me a lot of time and led to
much cleaner code than I would have previously pulled together. If there's something you
are unsure about, give this chapter a read-through and see whether you can work through
the ideas. Hopefully, they may save some of you some time in the long run.
1.1.1 Manager and Controller Scripts
I am a strong believer in manager and controller scripts. I like to try and split things out
into separate areas; for example, in the
Metal Vehicle Doom
game, I have race controller
scripts and a global race controller script. The race controller scripts are attached to the
players and track their positions on the track, waypoints, and other relevant player-specific
race information. The global race controller script talks to all the race controller scripts
attached to the players to determine who is winning and when the race starts or finishes.
By keeping this logic separate from the other game scripts and contained in their own
controller scripts, it makes it easier to migrate them from project to project. Essentially, I
can take the race controller and global race controller scripts out of the game and apply
them to another game, perhaps one that features a completely different type of gameplay—
for example, alien characters running around a track instead of cars. As long as I apply
the correct control scripts, the race logic is in place, and I can access it in the new game.
In the framework that this topic contains, there are individual manager and control-
ler scripts dealing with user data, input, game functions, and user interface. We look at
those in detail in Chapter 2, but as you read this chapter, you should keep in mind the idea
of separated scripts dedicated to managing particular parts of the game structure. It was
