408 APPENDIX A ■ DESIGNING THE WRAITH Our shockwave in action is shown in Figure A-8. Figure A-8. Shockwave in action Hit Logic We’ll need to add some functionality to HitManager.CheckHit() to implement the nolifty status, rocket strikes, and chainsaw smashes. The way that we’ll set up the nolifty character will primarily prevent the monster from being lifted into the air by uppercut attacks, but also will cause the monster’s animation to sometimes not be affected by attacks. This means you’ll be able to smash away on the wraith for a couple of seconds, and he will be reacting to every hit, but then for the next three seconds, he will be able to attack in the midst of your barrage. We’ll add a flag to the Character class called stunFrame, which will decrease at a rate of 1f per second if above 0f. If stunFrame is between 0f and 3f, the monster won’t be affected by attacks. We get the previous state and previous location of the wraith. If we don’t want him lifted, we’ll check to see if he is currently airborne and previously grounded; if this is the case, we return him to his previous state. Also, we now need to check for noAnim before every trajectory and animation change to prevent us from moving characters that shouldn’t be moving. int pState = c[i].state; Vector2 pLoc = c[i].loc; bool noAnim = false; if (c[i].stunFrame > 0f && c[i].stunFrame < 3f) noAnim = true; if (c[i].noLifty) APPENDIX A ■ DESIGNING THE WRAITH 409 { if (c[i].stunFrame <= 0f || c[i].stunFrame > 5.2f) c[i].stunFrame = 5.5f; } if (typeof(Bullet).Equals(p.GetType())) { } else if (typeof(Rocket).Equals(p.GetType())) { pMan.MakeExplosion(p.GetLoc(), 1f); hVal *= 5f; if (!noAnim) { c[i].trajectory.X = (p.GetTraj().X > 0f ? 600f : -600f); c[i].SetAnim("jhit"); c[i].SetJump(300f); } Game1.slowTime = 0.25f; r = true; } else if (typeof(Hit).Equals(p.GetType())) { if (!noAnim) { c[i].SetAnim("idle"); c[i].SetAnim("hit"); } switch (p.GetFlag()) { case Character.TRIG_WRENCH_SMACKDOWN: case Character.TRIG_CHAINSAW_DOWN: hVal *= 15f; pMan.MakeBloodSplash(p.GetLoc(), new Vector2(-50f * tX, 150f)); c[i].SetAnim("jfall"); c[i].SetJump(-900f); Game1.slowTime = 0.125f; QuakeManager.SetQuake(.5f); 410 APPENDIX A ■ DESIGNING THE WRAITH QuakeManager.SetBlast(.5f, p.GetLoc()); break; } } if (c[i].state == Character.STATE_AIR) { if (c[i].noLifty) { if (pState == Character.STATE_GROUNDED) { c[i].loc = pLoc; c[i].state = pState; c[i].SetAnim("hit"); } if (c[i].trajectory.X > 300f) c[i].trajectory.X = 300f; if (c[i].trajectory.X < -300f) c[i].trajectory.X = -300f; } } This leaves a few odds and ends, like adding and loading wraith graphics to ZombieSmashers, adding wraith.zdx to our project, and loading the character definition in Initialize(): charDef[CharDef.CHAR_DEF_WRAITH] = new CharDef("chars/wraith", CharDef.CHAR_DEF_WRAITH); Also, there are a couple of places where we tied a string to an object for scripting purposes; we used this for the character script AI command and the map monster spawning commands. In Script, we’ll add a new case: case Script.COMMAND_AI: switch (line.GetSParam()) { case "zombie": character.ai = new Zombie(); break; case "wraith": character.ai = new Wraith(); break; } break; APPENDIX A ■ DESIGNING THE WRAITH 411 Likewise, in MapScript, we add a case to GetMonsterFromString(): public static int GetMonsterFromString(String m) { switch (m) { case "wraith": return CharDef.CHAR_DEF_WRAITH; } return CharDef.CHAR_DEF_ZOMBIE; } We’re now able to add wraiths from map scripts. We added a new map and linked it to the current ones. We put in some nice water and a bucket full of wraiths. You can see the new map and wraith in action in Figure A-9. Figure A-9. Wraith in action! That should wrap it up! This appendix should have helped you get a better handle on what goes into creating a new character. We’ve created graphics, animation, and new particle effects; and incorporated everything into a neat chainsaw-wielding creature. 413 ■ ■ ■ APPENDIX B Storage Saving Your Settings This appendix will show you how to get a storage device, read from it, and write to it. In Windows, it’s easy enough to just read from and write to a saves folder in your game folder. On the Xbox 360, you can’t do this. You must use a special object called a storage container, which resides in a storage device. A storage device can be a hard drive or memory unit. If both are present, the user is prompted to choose. Once you have your storage device and opened a storage container, file reading and writing is fairly simple. Managing Devices and Containers We’ll start with the Store class, which we’ll use for all storage management functionality. If you’ve read Chapter 12, you may notice some similarities between this class and NetConnect. We’ll set up the class as a sort of common gateway for all reading/writing functionality, and then we’ll implement a Settings class for reading and writing game settings (of which we have one, but really, who’s counting?). Starting at the class level, we’ll declare our StorageDevice, which will be a hard drive, memory unit, or null (meaning the device search failed). public class Store { public StorageDevice device; IAsyncResult deviceResult; public bool pendingDevice; public StorageContainer container; bool containerOpen; public const int STORE_SETTINGS = 0; public const int STORE_GAME = 1; 414 APPENDIX B ■ STORAGE private string[] storeStr = { "settings.sav", "game.sav" }; Have you ever played an Xbox 360 game that asked you where you would like to save files? A dashboard blade pops out, letting you select the storage device. This is an asynchronous operation, meaning that the rest of the game doesn’t grind to a halt while you select the device. We’ll be using this technique here, and that’s why we’ve declared IAsyncResult deviceResult. While we’re waiting on our device result, pendingDevice will be set to true. We’ll call GetDevice() from Game1 during initialization. This will pop out the device selector blade and give the player a chance to pick the device. If the player has only one storage device, he won’t see a selector blade, but the operation will still do its stuff asynchronously. public void GetDevice() { deviceResult = Guide.BeginShowStorageDeviceSelector( PlayerIndex.One, null, null); pendingDevice = true; } We’ll call Update() from Game1.Update(). All this will do is attempt to follow up on our asynchronous device retrieval. If we just got the device, we’ll read our game settings. public void Update() { if (pendingDevice) { if (deviceResult.IsCompleted) { device = Guide.EndShowStorageDeviceSelector(deviceResult); pendingDevice = false; Read(STORE_SETTINGS); } } } In attempting to read or write, a couple of things could have gone wrong. We could still be in our asynchronous device finding operation, the user could have closed the device selector blade (giving us a null device), or the device could have been detached. CheckDeviceFail() checks for these issues. We’ll use this function before any reads or writes. private bool CheckDeviceFail() { if (pendingDevice) return true; if (device == null) return true; APPENDIX B ■ STORAGE 415 if (!device.IsConnected) return true; return false; } We need to open our container only once for all writes and reads within the same device. This next function does just that: private void OpenContainer() { if (!containerOpen) container = device.OpenContainer("ZombieSmashersXna"); containerOpen = true; } Our Write() function uses our device and container to get a path. Then it creates a FileStream using this path and writes to it. We use a BinaryWriter that we can just pass along to whatever object we’re using to save. Here, we’ve implemented only the Settings object, which will ultimately be a public static at the Game1 class level. public void Write(int type) { if (CheckDeviceFail()) return; OpenContainer(); string fileName = Path.Combine(container.Path, storeStr[STORE_SETTINGS]); FileStream file = File.Open(fileName, FileMode.OpenOrCreate, FileAccess.Write); BinaryWriter writer = new BinaryWriter(file); switch (type) { case STORE_SETTINGS: Game1.settings.Write(writer); break; } file.Close(); } Likewise, our Read() function does almost the same thing. Just substitute “read” for “write” in all cases, and we’re good! 416 APPENDIX B ■ STORAGE public void Read(int type) { if (CheckDeviceFail()) return; OpenContainer(); string fileName = Path.Combine(container.Path, storeStr[STORE_SETTINGS]); FileStream file; if (!File.Exists(fileName)) { return; } else file = File.Open(fileName, FileMode.Open, FileAccess.Read); BinaryReader reader = new BinaryReader(file); switch (type) { case STORE_SETTINGS: Game1.settings.Read(reader); break; } file.Close(); } } Reading and Writing There isn’t much left to do. We just need to create a Settings class and plug everything in. We’ll only use one setting: rumble. This will determine whether our controller vibrates to accentuate things like gunshots, explosions, and the like. Up until now, rumble was on by default. public class Settings { public bool rumble = true; public bool Rumble { get { return rumble; } set { rumble = value; } } APPENDIX B ■ STORAGE 417 public void Write(BinaryWriter writer) { writer.Write(rumble); } public void Read(BinaryReader reader) { rumble = reader.ReadBoolean(); } } Had we implemented a SaveGame class (we have the structure in place to do so from within Store at least), we could have created a more complex example, but we can make do with this one. Bringing It All Together In Game1, we’ll declare our Store and Settings as public statics: public static Store store; public static Settings settings; We’ll initialize them and start trying to get the storage device in Initialize(): base.Initialize(); store = new Store(); settings = new Settings(); store.GetDevice(); Don’t forget that our store likes to be updated! If we don’t call any updates, our asynchro- nous device retrieval will appear to never complete. In the Game1.Update() function, throw this: store.Update(); In Menu, we need to add the user interface to let us turn rumble on and off. In Update(), we have a big switch block that normally does transitions whenever the player hits A or Start. We’ll modify one of the cases to cause the game to write the settings when Back is pressed and toggle rumble when the rumble options are selected. case Level.Options: switch (option[selItem]) { case Option.Back: Transition(Level.Main); Game1.store.Write(Store.STORE_SETTINGS); break; 418 APPENDIX B ■ STORAGE case Option.RumbleOn: Game1.settings.Rumble = false; break; case Option.RumbleOff: Game1.settings.Rumble = true; break; } break; We put this content together between Chapter 10 (which does most of the work on the main menu) and Chapter 12 (which adds a multiplayer level to the main menu), so we definitely snuck in a bit of extra functionality on this menu. We added the RumbleOn and RumbleOff items to the Option enumerator, added some items to the graphic, as shown in Figure B-1. We also added the following case to the switch block in PopulateOptions(): case Level.Options: if (Game1.settings.Rumble) option[0] = Option.RumbleOn; else option[0] = Option.RumbleOff; option[1] = Option.Back; totalOptions = 2; break; Figure B-1. Options image [...]... method, adding character building and depth to, 267 ■L Land() function, defining, 144 ledge, code for landing on, 140 Ledge class, defining in mapClasses folder, 81 ledge palette, adding, 84 ledge segments, modifying in Map.Read() function, 131 ledgeAttach, holding ledge’s index in, 135 Visual C# 2005 Express Edition, 19 ledges, creating function to draw in Game1, 82–83 XNA Game Studio 2.0, 19 legs2.png,... variable, for holding decimal values, 4 adding to XNAPong, 27–32 task list for, 27 game messages fluffy white blobs, creating, 174–176 example of, 377 flying attack, script commands for, 157 sending and receiving, 376–391 fog drawing, 316–317 game options, sprite sheet in options.png, 306 fog[], using for fog particles, 309 game plan, for Zombie Smashers XNA project, 49–50 fog case, 272 game project,... intelligence) alpha blending vs additive blending, 180 421 422 ■I N D E X Audacity shot-in-the-face wave file in, 223 simple audio editing with, 223–229 web site address, 223 audio adding for XNAPong, 36–39 coding for XNAPong, 38–39 creating wave banks and sound banks, 37–38 impact of in games, 221–248 obtaining and editing, 221–229 audio files See sound files AudioEngine, loading wave bank and sound bank... encapsulate screen shaking, 241–242 pixel shaders, working with in XNA Game Studio, 333 QuakeManager, making sure rumble is not set in, 419 Platform-happy side-scroller (Mario), 398 QuakeManager class play swing command, adding to Guy character, 236 playback preview, 120–122 PlayCue() calls, adding to game, 234 playing = = true, checking for in XNAPong, 31 playing class-level Boolean, 121 PopulateOptions()... address for purchasing, 328 weapon creation, 43 do while loop using instead of for loop, 14 vs while loop, 14 DoJob() method, case-by-case behavior in, 260 Cross-Platform Audio Creation Tool (XACT), for XNA audio, 36–39 Doom, rockets without contrails introduced in, 171 Ctrl+F5, for debugging code, 12 DoScript() method, 161 cues, for playing sounds, 229 curline command, 278 adding case in to act on new... game, 316 background image controlling flow with, 9–10 how it works, 9 Box class removing a top when a Box is opened, 10 adding GetXLim() and GetYLim() to, 152 use of properties by in OOP, 7–9 adding to XNAPong, 33–35 with new HasTop Boolean property, 9 adding to ZombieSmashers game, 150–153 creating class-level variable for, 152 drawing background for, 151 hard-coding screen size, 152 locking scroll,... ledge drawing system in, 81 427 428 ■I N D E X Game1 class constructor, objects instantiated in, 25 Game1.Update() adding ledge nodes in, 83–84 Game1.CopyFrame() method, 116–117 changing, 76 Game1.cs, XNAPong class-level variables, 28 changing block that checks for dragging, 76–79 Game1.Draw() method, 26 adding method calls to, 88 checking if middle button is clicked, 74–75 creating segment palette,... breakpoints, used in debugging code, 12–13 brightness, of colors, 344 Bucket class, implementing, 284–285 bucket monster spawning, turning off, 394–395 background.bmp, 34 BucketItem class, 285 ball logic, for XNAPong, 31–32 Bullet particle ballTraj, updating, 31 checking for map collisions in, 197 base.Draw(), Begin()/Draw()/End() requirement before calling, 27 creating, 194–195 base.Draw(gameTime) method,... Multiplayer-intensive game, 398 music audio, adding to game, 236–239 Music class, creating in ZombieSmashers, 238–239 MuzzleFlash particle, defining, 194 network control, 371–372 setting up in Zombie Smashers XNA, 361 networking system, suggestions for improving, 396–397 NetWriteParticles(), sending off particles flagged for a send in, 391 new operator, rewriting functionality provided by a base class with,... putting NetWrite() method in, 387–388 particle collision, simple, 197–198 particle net data, 386–391 object or reference types, 4 particle sprite sheet, creating, 174–176 object-oriented programming, in C# 2.0, 6–17 particle systems, 171–220 objects, in object-oriented programming, 6–9 particle types, defining constant values for, 387–388 ok value, determining if button has been pressed with, 313 onionskin . track, 22 6 applying Cross Fade Out effect to, 22 6 applying echo to, 22 6 final clean up of, 22 8 22 9 fixing excessive reverb in, 22 6 22 8 removing shell-casing from in Audacity, 22 4 22 6 ■A add. for, 26 5 26 7 hit logic, in Wraith, 408 –411 Hit particle, creating, 21 1 21 2 hit points (HP), pummeling zombies, 25 0 25 1 HitManager class creating, 20 4 20 6 handling bullet impact in, 21 1 21 2 setting. monster type strings with, 28 1 28 2 GetTransVal() function, using, 301 GetTrigName() function adding string names to, 21 0 21 0 adding strings associated with constants, 25 0 25 1 defining, 189 globalFlags