CAP 211 -
Interactive Design and Game Development
Mastering Unreal Technology, Chapters 2 and 3
This lesson discusses developing games in general terms, and begins a series of tutorials for using the Unreal 3 Editor. Objectives important to
- Sample story treatment
- Working on a design team
- Using the Unreal Editor
Chapter 2 presents some truisms about game design that echo what has been presented in your design theory lessons. The concept of iterative design is one you should accept as necessary in all but the simplest projects. For example, when you anaylzed a game for the first time, you should have immediately thought about what you might do to make such a game better. This illustrates the cyclic nature of any software design project. We can call it a game development cycle (page 32), or a systems development life cycle, but the meaning is the same.
You begin with an idea. You develop the idea into a plan for the game. You build a system around the idea: the game, version 1. You test it and get feedback about what needs to change, which becomes the next version of the idea. In theory, you either run out of things to change and improve, which means the game is finished, or you find a flaw you can't fix, which means you change one or more of your basic ideas. Parker Brothers originally reviewed and rejected the board game Monopoly as having 52 design errors. Personally, I think we would be happier if they had stopped there, but the game was developed further, and it became a best seller, and the cause of many arguments and bad feelings.
In this chapter, the authors describe turning an initial idea into a story treatment, a more fully realized version of the story than the initial inspiration. Assume that their initial idea is "alien combat game, post holocaust, space themes". Pages 34 through 38 of the text present a model for expanding this idea into a story treatment. A problem exists in this treatment. Pages 34 through 37 are background information about the universe this story takes place in. 37 and 38 begin the actual story, but that's where it stops.
This is less a story treatment than a pitch for a game idea. The authors propose that you would present material like this to your design team, and would create what follows together. That could happen. It might also happen that you would be told you have only provided a hero, a villain, and a shipwreck, with no real story about what happens to them. That could describe Treasure Island, The Tempest, Pirates of the Caribbean, or Flapjack.
If you are plotting out a story, there needs to be more: what does the player do to play this game? If you are plotting a narrative, there needs to be more. If this were a comic book, the authors have not plotted beyond page 3. If you are only providing an alien background for a technological first person shooter, be honest about it and move ahead with that idea, but don't tell me this is an epic role playing/strategy game. Both kinds of games sell. You have to decide which kind you are creating.
A set of design documents for a game should include:
- an introduction like the one in chapter 2, but it should be extended to include an overview of the actual game play
- a document about the mechanics of the game (story): what can the player do, what must the player do, what the rules of the game allow and do not allow
- a definitive version of the narrative/plot of the game that all developers can follow. The introduction in the text is fine to get a player interested in the game, but it is painfully incomplete for a developer who will need to know what story elements to reveal to the player at what points/events in the game itself. Your team needs to know the game's story and its plot.
- descriptions and examples of the game's aesthetics, which include the art, the music, the tone of the game, and way the player experiences the game's world
- specifications for the technology that will be used to create the game, as well as the technology that will be required to play it (what platforms, what hardware requirements, what hardware recommendations)
Returning to the idea of a team working on the project, the authors describe some of the skills you need to work on such a team:
- communication - sharing ideas, promoting new ideas, jointly deciding which directions to follow are all important when working with other professionals
- presentation of your ideas - making an effective pitch for your own ideas is important to getting those ideas across to the rest of the team, whether you are in charge of the team or not
- respecting teammates - hearing the ideas of others is important if the game is going to be anything other than a one-man show
- give and take - you have to give up an idea sometimes in order to get to a consensus the team can accept: they won't all work in the same game; you also have to decide when to push hard to convince the team about your concept if you think it is vital to the game. The difference between a visionary and a nut is whether you believe in the vision. Remember that you are not always right.
Testing a product should be done first by members of the development team, but this logically expands to testing by people who have not worked on the project, who have no preconceptions about the game. Note the discussion on page 43 about the progression from alpha testing, to closed beta testing, to open beta testing. Each level of testing should be resolving a potential set of problems that is different from the previous level. It is also true that you never really leave the development cycle, since new issues come up in actual play that testing does not find.
In chapter 3, the text turns to a series of tutorials about the Unreal Editor. This begins the hands on lessons in building game maps (also called levels or scenes). To begin the first one, run Unreal Tournament 3 Editor, not the game. (It takes a significant amount of time to start.)
Tutorial 3.1: Creating your first room
- Follow the instructions in the text. When I did this, I was alerted about a lot of INI files being out of date. If this happens, click the Yes to all option.
- Follow the instructions in the text.
- Follow the instructions in the text. Make sure to select Subtractive.
- Right click the cube icon (shown on the right) to open the properties dialog box for a cube.
- Set the properties for the cube as illustrated in the text. Click Build, then click Close. You will not see the box you have just made yet. To see it in the Perspective viewport (lower left, black viewport) place your mouse pointer in that viewport and drag down, or roll the mouse wheel down. This will dolly the camera back, and you will see the edges of the box in red. Do this before continuing.
- Hover over the buttons on the tool bar to find the CSG: Subtract button. Click it once. You can't see what just happened, so we will turn on a light.
- Notice that each of the viewports in the Unreal Editor has its own set of buttons. In the row above the Perspective viewport (the one you are working with), find and click the Unlit button, which should be the fifth from the left. Once it is clicked, you will be able to see the walls of the new room as a checkerboard pattern.
- Save your current file as instructed.
Tutorial 3.2: Adding a Second Room
- Open the file you made for the first tutorial.
- Create a cylinder as instructed.
- The Translation widget should already be selected. If not, select it.
- The drag grid setting should already be set at 16. Check it in the lower right corner of the Editor window, and change it if necessary.
- The text says to use the Top viewport. Note that each viewport can be changed from one view to another by clicking the appropriate letter in its toolbar: P, T, F, or S (for Perspective, Top, Front, and Side). This would be a good time to zoom all the viewports so that you can see the new hexagon/cylinder in each of them. If you lose the translation widget while you are doing this, click the hexagon again, and it will reappear.
Drag the red arrow of the gizmo until the bottom of the hexagon appears to be two rows above the original room in the scene. This is illustrated on page 53, but you will not be able to see it until you shine a bright light on the page. (And even then, the grid is poorly illustrated.)
In the image on the right, the cube is shown dimly, two rows below the hexagon. It is easier to see the hex because it is selected. The nasty trick being played on us is that if you zoomed in farther, you would see that the two figures are actually separated by four rows, not two. The editor does not draw all lines at all zoom levels, so you have to zoom in pretty far to be sure. (In case you have not noticed it, 3DS Max has the same problem.)
- Adjust the hexagon in the Side viewport to place the floors of the two rooms at the same level.
- Confirm that the rooms are positioned as required by the text, then click the CSG: Subtract button. Warning: the next exercise will not work if the rooms are not aligned correctly before you click the CSG: Subtract button.
- This instruction makes no sense, if the rooms are aligned properly already. It should be obvious to you that they are not connected.
- Save as instructed.
Tutorial 3.3: Connecting Your Rooms
- Open the file you made for the last tutorial.
- Create a box as instructed.
- Use the Translation widget to move the new structure between the other two, connecting them like a hallway. If it is too small to fit exactly in between, move the hex object again so they all line up. After you do, click the CSG: Subtract button for whichever of the rooms you moved.
- Align the floor of the "hallway" with the floors of the original structures using the widget in the Side viewport.
- Confirm that the hallway is in the correct position and click the CSG: Subtract button for it. You should be able to look at the scene in the Perspective viewport and see through the hole, all the way across the hex shaped room.
Tutorial 3.4: Illuminating the Level
- Open the file you made for the last tutorial.
- Zoom out in the Top viewport until you can see the center of the square room. Hold down the letter L on the keyboard, and click in the center of the square room. Release the letter L. You have added a light to the scene.
- Switch to the Perspective viewport. The Unlit button for this viewport is currently selected. Click the Lit button, which should be just to the right of the Unlit button. The room will look like it is lit by one omnidirectional bulb.
- The light should still be selected. If it is not, select it. Then, press F4 to see the properties of the light. Follow the instructions to see the LightComponent sub-category properties.
- Follow the instructions in the text to set Brightness and other properties.
- Switch back to the Top viewport. Alt-drag the light to the center of the hex room to place a copy of it in that room.
- Open the properties of the new light and change its radius property as instructed. Note that the text states that this will increase the range of the light. This is not true, since the radius was originally 1024.
- Save the file incrementally.
Tutorial 3.5: Testing the Level
- Open the file you made for the last tutorial.
- Click the Build All button on the main toolbar.
- The Map window may appear, and it may show errors. Click the Close button on this window.
- Right-click a place in one of the rooms, and choose Play From Here. You will see a game window containing an armed character. Run around and shoot your initials into a wall. Press Escape to close the game window.
- This time, right-click the square room again, and choose Add Actor, Add PlayerStart. This will place an object in the room marking where a player will appear in this level. Move it with the associated widget.
The text points out in this step that the PlayerStart object has an arrow icon on it. You will not see this arrow until you turn off the Transform widget or switch to the Rotate widget. The arrow points in the direction that the character will be looking when he/she appears in the scene. You can change the direction the character faces this way.
- Open the Build menu and select Play Level. This method does not work unless there is a PlayerStart object in the level. Press Escape to exit the game window.
- Save incrementally.
Continue with the remaining lessons in this chapter. There are 21 in all, each one depending on the work done in the previous one. Descriptions of the remaining lessons in Chapter 3:
- Add textures to the walls and floors.
- Add a pipe to the level and give it a shadow.
- Add a doorway mesh to the opening between rooms.
- Add four lights to each side of the doorway. This follows the idea of practical lighting in 3DS Max.
- Create a particle system to emit steam in the scene. Note that the icon shown in the text for Show Generic Browser in the Cascade Editor is incorrect.
- Configure "base modules" for the particle emitter.
- Add and configure other modules to the particle emitter.
- Add the particle emitter to the scene.
- Add a door that will open and close.
- Configure the trigger to play a sequence when touched and untouched in the Kismet Editor.
- Use the Matinee Editor to create an animation sequence for the door. Before you open the Kismet or Matinee Editor, select the door object that was added in exercise 14. Note: In step 6, you are told to click the Add Key button. This is the button on the far LEFT of the Matinee button bar. It is unfortunately identical to the Toggle Snap button near the right end of the button bar.
- Add several crates to the scene. Remember to Ctrl-click to select multiple objects, and use alt-drag to copy objects.
- Add some physics properties to the ten crates, and try to move them with a new gun. This does not work very well. Instead of using the physics gun, just roll your mouse wheel and use the impact hammer that your character already has.
- Add fog to the level. Note that adding it to one room adds it to the second as well.
- Add weapon drops and ammunition to the level.
- Review the four prefixes used to distinguish what type of level you are creating, Publish your level to your installed copy of Unreal Tournament 3, if possible.