The projects in this book were written in Visual Basic .NET using Microsoft Visual Basic 2008. VB.NET, like VB before it, is easy to learn and write, and yet quite powerful. With the advent of VB.NET in 2001, VB no longer carries an inherent performance penalty compared to other languages. You will need to install VB to use the software on the CD that is included with this book. Once you have installed it, you’ll bring up the development environment and proceed through the walk-through example in this chapter.

Visual Basic 2008 requires a Microsoft Windows XP or later operating system. Older versions can run on Windows 2000. The Visual Basic 2008 Express edition is free for non-commercial use. Further details and the software itself are available at http://www.microsoft.com/Express/default.aspx. In addition to the software, the Express Web site offers tutorials and other information that may be valuable to first-time Visual Basic users.

VB is included in the retail versions of the Visual Studio development environment. The screens will be similar, but will carry more options. If you have Visual Studio, you can safely substitute “Visual Studio” wherever you read “Visual Basic” in this book with few problems. Note that the dialog boxes will not match exactly; Visual Studio is more sophisticated than the Express versions of the languages it supports.

If you are an experienced C programmer, you may prefer to use C# or C++. Download Visual C# 2008 Express Edition or Visual C++ 2008 Express Edition instead of Visual Basic. The C# and VB languages both utilize the .Net Framework Common Language Runtime, making them utterly interchangeable. C++ requires modest translations that should not prove taxing for an experienced programmer who happens to be new to AI.

For those new to Windows programming, a few brief words of description are in order. A Windows application starts with forms (the windows in Windows are forms). On the forms are controls such as buttons and text boxes. When the user interacts with a control, an event is fired and the application software handles that event. When the application software is done handling the event, it gives control back to the operating system. There is no “main,” familiar to C programmers, only a startup form that is shown to the user when the application launches. Giving control back to the operating system after handling an event does not mean that the application finishes execution and exits, only that it is done handling the last event and is ready to handle another. This is called event-driven programming.

The game projects in this book will be Windows forms applications written in VB. The forms will display the game and take user input. We will separate the AI for the game from the user interface. Not only is this an industry-accepted good practice, but it will also help provide focus and clarity on the AI portion of the code. Separating the AI from the rest of the code will make interfaces between the two explicit. One of the more important jobs of a game AI programmer is to make sure that the rest of the game will provide the AI with the information it needs to work effectively. In addition, the game AI programmer must insist that the rest of the game provide ways for the AI to manipulate the world and the interactive experience.

Our first project will be a hit point calculator. The user will input a character class and level, and the software will compute the maximum number of hit points for the character. The values match those used in numerous familiar fantasy role-playing games.

This project will familiarize you with creating a project, adding forms to it, adding controls to the forms, and writing code to handle events. Start by launching Visual Studio. From the File menu, select New Project. Visual Basic will show a dialog box similar to the one in Figure 1.1.

Figure 1.1. This New Project dialog box is for creating a new project.

On the left side of Figure 1.1, Windows Forms Application is selected. Instead of using the default name, WindowsApplication1, change the name of this application to HitPoints and click OK. Your screen should resemble the one shown in Figure 1.2.

Figure 1.2. Visual Studio, showing a new project.

The large area contains a window marked Form1. This is the editing pane. To the right is the Solution Explorer, showing all the files in the project. (A solution in Visual Basic can have more than one project, but we will not use this capability.) Below the Solution Explorer is the Properties window.

The Properties window lists the properties of whatever object was most recently in focus. Buttons near the top of the Properties window control what you see and how it is organized. Starting from the left, the first two buttons control how the window is organized. Click the first button (marked with two plus signs) to organize the properties by category; click the second button (marked with an A and Z and an arrow) to arrange the properties alphabetically.

If the focus is on a form, you will see five buttons. The third and fourth buttons control what is displayed. The Properties window usually shows properties, which you select with the third button. Clicking the fourth button, marked with a tiny lightning bolt, shows events and event handlers. These two buttons are not visible in Figure 1.2 because the focus is on the file Form1.vb in the Solution Explorer. The form has one set of properties, and the file the form is stored in has a different set. These buttons will show up shortly when we change the properties of the form itself.

Figure 1.2 shows all the files with room for more but only part of the Properties window. You can adjust the height of the Properties window by clicking and dragging the area between the Solution Explorer and the Properties window. This is just one way in which Visual Basic is extremely adjustable; another is the way you can choose to hide or display various window elements. For example, note the pushpin icons. The Solution Explorer and Properties window are pinned in Figure 1.2, so you can see their contents. To the left of the editing pane is the Toolbox; click it, and it slides open. Clicking the Toolbox’s pushpin will pin it open. Clicking outside the Toolbox when it is unpinned slides it back out of the way.

Visual Basic created a default form and named it Form1. This is typical of Visual Basic, so one of the first tasks when creating a new form or adding a control to a form is to give the new object a more useful name than the default. Visual Basic also gives default values to other properties, some of which we will also change.

Our next task is to place controls on the form and operate them.

This finishes the user interface part of the project. Your application should resemble Figure 1.5.

Figure 1.5. The project, with a completed user interface.

Note that we did not change the name of Label1 or any of the other labels, but we did change the name of this last label. We did so because code that we will write later will need to refer to the label, so it needs a clear name. Label1 will never be referenced by code we will write, so since life is short, we did not bother to rename it. We added the word Label at the end of the name so that the name will tell us what kind of control this particular one is. Complex projects employ many controls. Often, they will have similar names; by adding the control type on the end of the name, we can distinguish them easily.

You may have noticed that there are many properties that can be set. One of the advantages to VB is that you can generally get away with setting the ones you need and safely ignoring the rest. The Toolbox offers more controls than we need, and we can safely ignore the extras as well. Curious students will want to learn more about them by using the help system and the MSDN library. By now, it should be getting obvious how this project will work.

It is time to write code. Our application needs code to handle three things: events associated with the NumericUpDown control, events associated with the RadioButton controls, and gracefully starting up. The easiest way of getting from a form or a control on a form to the code that handles the events for the form or the control is to double-click the form or the control. We start with handling the events related to startup.

Double-click the GameForm form background, taking care not to double-click one of the controls. Visual Basic brings up a tab labeled GameForm.vb. The code for the form and all its controls live here. Visual Basic added the skeleton of the event handler for the form’s Load event. The Load event is the most typical place to put startup code for a form. When the application launches, the form will be created, and the form’s Load event will fire. Let us look carefully at the code for the form.

All of the code lives between the Class and End Class lines. If you are unfamiliar with classes, we will expand on them in Chapter 3, “Finite State Machines (FSMs).” For now, all the code for the form goes inside the class. We are more interested in the event handler.

Private Sub GameForm_Load(ByVal sender As System.Object, _
        ByVal e As System.EventArgs) Handles MyBase.Load

Going from left to right:

We will add our initialization code between the Sub and End Sub lines shortly. We can ignore the complexities safely as long as we remember that the code we add here will run when the form is loaded, which for us means once, at startup.

Our application will want to compute the correct value of maximum hit points and show it as the text in the HitPointsLabel field instead of 888. To do this, the code needs to compute the product of the level of the character times the size of the character’s hit dice. It would be nice if the radio buttons would directly tell us the size of the character’s hit dice, but they do not. The Level control will give us a numeric value for level, but we need an integer variable to hold the die size. Just like on a car radio, we have to program the number we want to associate with each button. To make life easier, we will store that number away whenever a button gets clicked.

Below the Public Class GameForm and above the handler for Load, type the following and press Enter:

Dim dieSize as integer

Visual Basic will reformat and color the text as you go.

We want our software to “wake up sane.” That means the value shown for maximum hit points should be based on the level and class selected on the user interface. We could have set the Maximum Hit Points label Text property to 4 instead of 888 and selected Mage as the character class, knowing that we set the Level control to start with a value of 1. Doing so would force us into keeping all three controls synchronized whenever we reprogram any of them. It also means that the formula to compute maximum hit points would exist in two places: invisibly implied by the value we use in the Maximum Hit Points label Text property and explicitly stated somewhere in our code. If we change the formula, we would also have to remember to change the label.

There is a better way to ensure that our software wakes up sane. We are going to write code that changes the Maximum Hit Points label Text property whenever the user changes the level or class. Our Load event handler will act like a user and set the user interface to sane values. Then, all the code we have to write anyway will work on our behalf to wake up sane. We will be able to see at a glance that our code works.

We want the formula to exist in only one place. Add the following code between the end of the form Load event handler and the end of the class:

Sub ComputeHitPoints()
    HitPointsLabel.Text = CStr(dieSize * Level.Value)
End Sub

Adding this code sets the label text to the product of the character level (from the Level control) and their die size (the variable) all converted to a string, since the Text property is of type string and not of type integer. We need to call this code any time the user interface changes the level or class settings. How will our code know the user interface changed?

Whenever the controls are changed by the user, VB will fire events for the controls. We have an event handler for the form’s Load event; now we need handlers for the Level and Class controls.

That code takes care of all of the user interface events our code will need to handle. Let us see how well it works.

From the Visual Basic main menu, select Debug→Start Debugging or press F5. You should see something like Figure 1.6. Note that the application changed the value of 888 to 4 as expected. You can stop debugging by clicking the Close button (the red button with an × inside) in the upper-right corner of the application window or by selecting Stop Debugging from the Visual Basic Debug menu.

Figure 1.6. The project, running for the first time.

We can tell at a glance that our code does not wake up sane. It shows no class selection, and 888 is probably not the right number of hits points for a first level character of any class. At least the Level control is sane. Click one of the radio buttons to select a class and see the number of hit points change to the correct value. Change the Level and Class settings and verify that the code properly handles user input. Stop debugging so that you can edit the code.

We need our code to wake up with a class selected. The Level control wakes up sane, but the Class settings do not. We could set the Checked property to true for one of the radio buttons using the Properties window, but there is a better way. Add the following line to the empty GameForm_Load routine:

MageRadio.Checked = True

Now when our code wakes up, it will check the MageRadio radio button. This means that the radio buttons will appear to the user to wake up sane. One button will be selected. Run the application again. Notice that the maximum number of hit points is shown as 4 and not as 888. We did not directly change the label text, so why did it change? When our code selected the radio button, the system did as we asked and selected the button. The system also did as it always does and fired the CheckedChanged event for the control. The event handler we added for that event of that control ran, setting the die size to 4 and calling ComputeHitPoints. ComputeHitPoints set the label for us, using the formula. Not only will user interaction cause events to be fired, but actions by our code cause them as well.

We exploited the capability of our code to raise events in order to let it use the regular code for operation to also work for initialization. This cut down on the coding and the complexity. We eliminated a hidden dependency between the formula and the initialization code. Getting rid of special initialization code gets rid of potential bugs; there are no bugs in code that is not there.