10/6/2001 -- The Target Arena splash screen and main menu screen are now available as LithTech DTX format textures. They are called TAsplash.dtx and TAmainmenu.dtx, and are located in p:\course\cs638-schenney\public. Also in that directory is a text file called P1dims.txt that gives the coordinates and dimensions of the "hot spots" where users can click on menu items.
Also, you can use the mouse cursor provided with the CUIWidget sample that comes with the LTDS.
The specifications for this project assume that you have completed Stages 0.0 and 0.5. If there is anything you do not understand, first make sure that you have read the assigned sections of the Programming Guide and the commented sections of the Target Arena source.
The LTDS comes with a sample program called CUIWidget. This sample illustrates one possible approach to implementing a user interface for a LithTech application. It shows you how to create windows and buttons, and also shows how to use input handling and function callbacks to make the buttons do what you want.
One way you can approach this project is to create some sort of a state manager that keeps track of what the user is currently doing. You can then specify certain rules that determine state transitions. For example, in Task 1 you are to implement a splash screen that pops up at the beginning of the game. When you click on the active area, a state transition should occur to either the "Main Menu" state or the "Playing Game" state, depending on whether you choose to implement Task 2. This could be implemented by creating a separate class to handle states and state transitions, or by adding a few functions to the client shell.
Something you should also consider is that the game starts up automatically as soon as you run it. To implement any of the first three Tasks, you must change this behavior. This means that the call to InitGame must be conditional.
You also need to consider how you will perform input handling. Currently, when a user hits the left mouse button, the player fires a rocket. However, this clearly shouldn't happen at the splash screen. Therefore, you need to use the state manager (or some other method) to determine what the user is allowed to do in any given state.
If you want to add a new command to Target Arena, you need to do a couple of things. First, you need to edit the autoexec.cfg file and add a new action. In the same file, you need to bind the action to a key or mouse button. Then, you need to edit the commandids.h file (shared between the client shell and server shell) and add it to the list of enumerated command IDs (taking care to use the same number as in the autoexec.cfg file). More information is available in the Input chapter of the Programming Guide.
Finally, the Update function in the client shell and game client must be modified or replaced. Right now, it automatically calls the player's input-handling function (which then calls the camera's input handling function for mouse-look). You should change this so that the input-handling function that is called depends on what the user is currently doing. Also, what you draw on the screen depends on whether the user is viewing a menu or playing the game, so the parts of the code that take care of rendering must be modified. Keep in mind that everything you want to draw to the screen must be between calls to Start3D and End3D.
When you run the game, its first behavior should be to display a splash screen. We will provide a splash screen in LithTech's DTX format. You can also use your own image (by creating a TGA file and converting it with LithTech's tools), but it must have some sort of graphical "hot zone" where the user can click to proceed. Instead of calling InitGame, you should set up the splash screen and write the input-handling code that will allow a user to proceed.
Look at one of the sample LithTech applications to see how they display the LithTech watermark as a 2D primitive in screen space. For mouse input, examine the camera.cpp file in the client shell project.
Keep in mind that some parts of the code receive a message via OnCommandOn when you press certain keys or mouse buttons. For example, the middle mouse button is mapped to the jump command, and the player client responds to this automatically. You should modify this event handling so that such actions do not cause problems when they are performed out of context (e.g., issuing the jump command at the splash screen).
This is an extended version of Task 1, so you should read the above section even if you're not doing Task 1. The main issue is implementing several hot zones and deciding how to control program flow. When the user selects Load Game or Save Game, you should display another window/button/etc over the menu screen that asks the user whether they want to load or save a game. As for Task 1, we have provided a texture you can use for this purpose, or you can create your own.
You must implement at least one setting for this screen. Some examples are: Y-axis invert (on/off), mouse smoothing (on/off as well as the "strength" of the smoothing), mouse speed (several different speeds or maybe a slider), and field of view (select from a list, use a slider, etc). You can also implement something that is not on this list.
Some of these settings are set up as constants in the game code. So, for example, if you want the mouse smoothing strength to be modifiable from the settings menu, you might add a member variable (or global variable) to the camera class in the client shell. This variable would be altered by a function called when a user modifies the setting. The mouse smoothing function would then use this variable in its algorithm.
Since the server has ultimate control over each client's game timer, you will need to use client-server messaging in this task. When the user presses the Pause key, the client shell should send a message to the server telling it that the player wishes to pause the game. The server, upon receiving the message, should change the player's state (you might implement a new "Paused" state in the game server class). If the user presses the key again, the client should once again let the server know, and the server should start processing that player again. You will need to modify the Update function in CGameSrvr.cpp so that it does not deduct time when the game is paused on the client.
Your client-server messages (e.g., MSG_CS_PAUSE and MSG_CS_RESUME) should be added to the enums.h file. You can look at an example of constructing and sending a client-to-server message in playerclnt.cpp (when a rocket is fired, at the bottom of the CPlayerClnt::HandleInput function). Messages are received by the server in OnMessage, which is where you should receive and handle the pause and resume messages.
If you implemented Task 2, the menu you display has to include options to "Resume" and "Restart" (along with the other menu items implemented for Task 2). Resume should unpause the game, and Restart is self-explanatory. There is code that restarts the game in playerclnt.cpp. If you didn't do Task 2, just display something on the client's screen when the game is paused (e.g., "Paused, press key to resume"). A function that displays text, called CGui::RenderText, is provided in ui.cpp.