C# Workshop – Project 3: Combat Simulator Note: Participants will have 2.5 weeks (ending Sunday, September 30th at 00:00) to complete the project. Introduction Welcome to the third project of the C# Workshop. This project is designed to give you an opportunity to challenge your understanding of the material we’ve already covered. For those with previous programming experience, this project won’t be overly difficult, but it will give you an opportunity to test your understanding of the programming syntax provided in C#. For those with no previous programming experience, this project will be a challenge. Not because it’s technically difficult or overly complex, but because 90% of being an adequate programmer is your ability to solve problems. Being able to logically break a project description down into discrete, manageable components is one of the most valuable skills any programmer can have. Unfortunately, this is not something that can be taught, it’s something that can only be learned with practice and the development of an analytic mind. Topics Covered As the third project has slipped to the final weeks of the workshop, it may test and exercise your understanding of any of the following topics: The System.Console Class

• The System.Console Class
• Strings and Primitive Types
• Expressions, Selection, Iteration, and Arrays
• Classes, Structs, Methods, Fields, and Objects
• Exception Handling and Properties
• Inheritance and Polymorphism
• Operator Overloading, Interfaces, Interoperability
• Events, Delegates, Files, Streams, String Theory
• Generics, Nullable Types

Background Information Gladiatorial combat - a fight to the death (or near death), is one of mankind’s oldest and most brutal forms of entertainment. Whether between humans, hounds, chickens, or wild cats, we are fascinated by the raw physical and mental power required for one member of a species to overcome equal odds against someone (or something) of equal skill and ability. In modern video games, the combat between one individual and another has taken on many forms. Perhaps the earliest forms were as two paddles trying to match each other’s speed at ping-pong, or opposing tanks trying to blast each other with missiles, snakes trying to cut each other off, or even worms lobbing sheep bombs at each other. Recently, however, one-on-one combat has entered all styles and genres of gaming. From First-Person Shooters, to Real-Time Strategy Games, to Fighting Games, and finally, to Role-Playing Games. The Dungeons and Dragons 3.5ed rule system has an entire sub-system based around the idea of combat (not necessarily 1v1). This includes elements such armor and armor classes, weapons and attack bonuses, special abilities, spells, saving throws, and even positional elements such as hidden or partially hidden enemies, and opportunities for attack when one enemy carelessly moves in or out of range of another enemy. And, while the positional elements can be complicated to implement in a Text-based RPG, the non-positional elements make for a challenging yet entertaining project for those who want to see wizards square off against rogues, one-on-one. Feature Requirements / Use Cases For this project we will be building upon the groundwork layer in project 2 with our character generator, by implementing an interactive Combat Simulator. The combat simulator will take on the appearance of a gladiatorial arena, where the player pits his character’s skills and abilities against randomly generated enemies, one at a time in a sort of tournament, to try and advance himself up the ladder, and become one of the Tournament Champions. Being based on our previous project, the combat simulator will use stats, skills, abilities, and combat rules roughly equivalent to that which can be found in Dungeons & Dragons 3.5 Edition’s “Combat 1.rtf” System Reference Document. And since D&D is a Trademark/Copyright of Wizards of the Coast, let me say that all content contained herein is subject to the Open Gaming License, and while I am encouraging people to implement a character generator and/or Interactive Game, I do NOT encourage them to distribute the software either for Free or for Profit. Such actions would likely be against WotC’s license agreement, and might get you sued. This exercise is strictly for learning purposes. Also, to avoid duplicating a large amount of information already in print, I will instead provide links to documents on the Wizards of The Coast website which will contain the relevant information. Before I go further let me say much of this project description is optional. I’ve tried to add in all the relevant rules for basic combat in D&D 3.5ed, however only implement that which you feel comfortable with. I’ve specifically stated in the clarification sections below which are expressly optional. But, as I said, feel free to make all or none of this project description optional. Where the first project was technically simple, but logically difficult, the second one was logically simple, but a bit more technically difficult. This project is both. From a logic standpoint, it might be difficult to comprehend much of the combat system and how it might interact with other elements of the system. Meanwhile, although there are simple designs possible, the project description as laid out below may require event handling, delegates, operator overloading, and interfacing…all of which can be technically difficult for the new C# programmer. Get as much done as you can, but don’t hesitate to ask questions about the more difficult stuff. CHALLENGE YOURSELF! 1. When the user first launches the program, they should be shown an intro screen, similar to that found in project 2. Feel free to use the same intro screen if desired. 2. On the main menu (also shown on the intro screen) the user should be shown the following options:

• Create New Character
• Load Existing Character
• View Tournament Champions

2a. If the player selects “Create New Character” they should be shown a series of screens designed to create a character. The fields: name, class, race, gender, height, weight, and age should be settable by the player. I.e. There should be one prompt for each, asking the user to enter in his choice for those fields. Following the selection/choice of the above fields, the player should be able to randomly roll for his character’s ability scores. If the player likes the scores he is presented he can “continue”, if he doesn’t, he can request the scores be re-rolled. The player can re-roll ability scores until he finds a set he’s happy with. After the above are all determined the random character generator used in project 2 should be used to set the remaining attributes of the character, including starting gold and inventory. Additionally, 10 other characters should be randomly generated, all level 1 as well. Finally, the character, and the associated list of challengers should be saved to disk, and advanced to Use Case 3 below. 2b. If the player selects “Load Existing Character” he should be shown a list of all the characters which have been created and the option to return to the previous screen. If he chooses to return to the previous screen, back up and show them the main menu again. If they select a character, load it from disk (along with the challengers), and advance to Use Case 3 Below. 2c. If the player selects “View Tournament Champions” he will be shown a list of all the characters (loaded from disk) which have completed 19 full tournaments, what their name, class, and race were, how much money they had earned from gambling, and optionally, what gear they were wearing upon attaining level 20. 3. Once the player has either created or loaded a character, they should be shown the “Character Menu” listed below:

• Buy/Sell Items
• Equip Items
• Manage Spells
• Examine Roster
• Enter Arena
• Exit to Main Menu

3a. If the player selects “Buy/Sell Items” they should be shown the Arena’s Store. The store should contain as many of the items listed in the SRD as possible. This includes armor, weapons, potions, spell scrolls, rods, wands, or other magical items. From this screen the player should be shown the amount of money they posses, and be given the option to either buy 1 or more items from the list, sell 1 or more of their items, or return to the Character menu. If the character buys or sells an item, their inventory should be updated and their character info saved to disk. 3b. If the player selects “Equip Items”, they should be taken to a screen which allows them to pick a slot, either Armor, Weapon 1, Weapon 2, Potions 1-5, Scrolls 1-5, etc…in which to equip his items. The number of potions and/or scrolls allowable in the tournament is entirely up to the programmer, and no restriction will be provided such as weight or carrying capacity. Feel free to implement this if you desire. 3c. If the player selects “Manage Spells” (assuming you’ve implemented spells either in Project 2 or Project 3), they should be shown a screen which lists which spells they know, and which they have memorized (for the case of wizards, etc…that must memorize). 3d. If they select Examine Roster, they should be shown a list of the 10 challengers in the tournament, along with their name, gender, class, race, and level. There should also be an indication of which one the player will be fighting next. Alternatively, you can choose to only show the remaining combatants. 3e. If the player selects Enter Arena, his health, spells per day, mana, and any other temporary effects are removed and restored to their full values. At this point, the player will be given the opportunity to place a wager upon the upcoming combat. The player may select a minimum of 10% of his monies, and a maximum of 90%. Finally, the character will enter combat against the next challenger in the list, using the rules of combat outlined below, and based on the characters’ initiatives. Upon completion of combat, the player will advance to Use Case 4a below if he wins, and Use Case 4b if he loses. 3f. If the player selects “Exit to Main Menu”, he is returned to the Main Menu, and both the character and challenger list is saved to disk and removed from memory. 4a. After the completion of combat, if a player has won, he will be shown a screen which tells him of his victory and that he was awarded monies equal to the amount he wagered. So if he wagered 10% of 10g, he will be awarded 1g. Additionally, the player will be notified on the screen of his next opponent – name, class, race, gender, etc…. This should be taken directly from the information listed in the tournament Roster. Once the user hits any key to continue, his character, position in the tournament, etc…will be saved to disk and he will be returned to the Character Menu. From there he can buy items with the money earned, equip new spells, and examine the roster, which should indicate again who his/her next challenger is. 4b. After the completion of combat, if the a player has lost, he will be shown a screen which tells him of his loss, and that he lost monies equal to the amount he wagered. Additionally, the player will be notified on this screen of his failure to complete the tournament. After hitting any key to continue, the character, his position in the tournament, etc…will be saved to disk and the player will be taken back to the Character Menu. From there he can buy items with the money he still has left, equip new spells, and examine the roster, which should indicate that his next challenger is in fact the FIRST challenger in the list. (Losing a combat starts the tournament over, keeping the player’s gear, but taking away the money gambled). 5. After the player has defeated all 10 challengers in the tournament, two things will happen. First, upon completing a tournament round of 10 competitors, the player’s character will gain a level. At this point, the player should be able to select his new feats, skills, spells, and any other attributes of a character which were implemented either in Project 2, or as part of Project 3. Once the player has completed leveling his character, the program should randomly generate 10 new combatants equal to the character’s new level, and then return to the player to the Character Menu. 6. The player can continue to compete with his character until he has successfully completed 19 Tournaments (making him level 20), in which case he will be declared a “Tournament Champion” and then retired from the tournament scene. Attempting to Enter “Arena” with a level 20 character should simply state “There are none brave enough to challenge you.” And then return to the Character Menu. When a character is declared a “Tournament Champion” they should be added to the list of tournament champions to be viewed from the Main menu. How Combat Works As indicated in the SRD, combat in Dungeons and Dragons is cyclical (not necessarily turn-based). When combat first begins there will be an initial startup phase, and then combat will progress in rounds. During the startup phase each character’s FlatFooted flag is set to true. When a character is flat footed, they may not use their dexterity bonus as part of their Armor Class. Additionally, each character will roll for their initiative. This is a number which determines each character’s position in the sequence of combat, and will be used to determine the order of attack. As this is an Arena environment, we are assuming that both combatants are aware of each other, and thus, there are no surprise rounds as indicated in the SRD. Once the initial setup has begun, and both combatants have their initiative calculated and are set to flat footed, the player will be given a menu which provides the following choices:

• Attack
• Use Item
• Use Ability
• Use Spell

Which of the above menu items are provided is dependent upon which features of the SRD have been implemented either as part of Project 2 or as part of Project 3. For example, if the programmer did not implement the ability to cast spells, then do not list the “Use Spells” menu item. If the player selects Attack, have him attack with his weapon. If the player selects “use item” give him a list of usable or consumable items to “use”. If the player selects “Use Ability” list the abilities which still have available uses this battle. If the player selects “Use Spell” list the spells which the player may still cast based on casts per day, mana, or whatever spell system is available for the current class. Once the player has chosen his action, compare his initiative against the enemy character. If the player’s initiative is higher, perform his attack first, then the enemies, if the enemies is higher, perform the enemies next attack first, and then the player’s. Once the player’s action has been performed, display the combat menu again, and continue the process. Basic Combat Rules As indicated in the SRD “Combat1.rtf” there is several things which can be done within a round of combat, most notably is attack, use a special ability, or cast a spell. When attacking, there are rules which dictate what is done to determine if an attack succeeded or missed, and if it hit, how much damage was done. Although I will not duplicate all of that information here (as it’s in the document), I will break it down very simply. Step 1. An attack roll is made, which is a 20-sided die, and an attack bonus is added to it (either Strength or Dexterity), depending upon what type of attack it is, and what type of weapon is being used. Step 2. The attack roll is compared against the enemy’s Armor Class, which is 10 + Armor Value + Dexterity Modifier + Size Modifier + ….etc. If the attack roll is greater than or equal to the enemies Armor Class, the hit was successful, and we move on to step 3. Step 3. Upon a successful hit we must calculate damage. This is just a roll based upon the weapon type. (And in theory whether it was used 1handed or 2handed, but we’ll ignore that for now). There are further rules, such as having multiple attacks, fighting defensively, critical hits, etc…all of which are outlined in the SRD and will not be duplicated. But can be optionally implemented at the desire of the programmer. For more information on the Basic Combat Rules (and the optional rules listed below) see: Combat I Injury and Death Upon either the player or the NPC “monster” reaching 0 hit points, the tournament round is over, and the person with HP > 0 is declared the victor. Combat Timing and 5-Second Delays (Optional) It is commonly believed that a standard action in D&D is something that can be done within a 5-foot radius and which takes approximately 6 seconds to complete. Since we are not dealing with proximity, we may optionally decide to implement time-based systems instead. As a modification to the “How Combat Works” above, you may attach the Non-Player Character’s actions to a 6-second timer. If the player has not performed his action within 6 seconds of either the start of combat, or his previous attack, the NPC will automatically attack, regardless of initiative. Then, when the player next performs his action, it will again occur either before or after the enemies, based on initiative. Here’s an example to illustrate: - Combat Begins – Round 1 - Player Attack 1: Player Performs his attack at T=3 seconds, but has lower initiative, so it is delayed - Monster Attack 1: Monster attacks at T=3 seconds in response - Player Attack 1: Player’s first attack finally lands at T>3. - Round 2 - Monster Attack 2: The player did not attack within 6 seconds, so the Monster attacked automatically at T=9. - Player Attack 2: The player finally chose his action at T=12, but has lower initiative, so it is delayed - Monster Attack 3: The Monster attacks again at T=12 seconds in response - Player Attack 2: Player’s second attack finally lands at T>12. Round 3 - Player Attack 3: The player performs his attack at T=15, but has lower initiative, so it is delayed - Monster Attack 4: The Monster attacks again at T=15 seconds in response - Player Attack 3: Player’s third attack finally lands at T>15. Using the system above, if the player ever misses his 6 second window, the NPC will attack anyways, and then combat continues as normal with the next round, effectively causing the player to “skip” a combat round. Action Types (Optional) According to the SRD there are several types of actions, including Standard Actions, Move Actions, Full-Round Actions, Free Actions, etc…In our base implementation of the Combat Simulator, all actions are full-round actions. That is to say, when a player has selected his action for this round, the monster attacks either before or after based on initiative, and then combat moves on to the next round. However, the programmer may optionally implement action types. In doing this, certain actions such as dropping/using an item, or quick-casting a spell may not take up the full 6 seconds, and would thus allow the player another turn BEFORE the monster attacks at T=6, 12, 18, etc… Conclusion Well, here we are at the conclusion of the project description for Project 3. I’ve tried to give you a reasonable overview of what is expected from you in this project. The main idea is to have fun. In general, we’re just randomly generating enemies using our character generator from Project 2, and then forcing them to engage in combat with our player character, using attack roles, armor class comparisons, and damage roles. For people that implemented special abilities, the use of items, spells, etc…those features may be added to the combat simulator as well, but again, it’s completely optional. If there is any confusion about what you should and should not attempt to implement, please do not hesitate to ask. And, when in doubt, leave it off. The best thing you can do is start with the easily computed combat rules, and then move onto the more difficult once you’ve got the easy stuff completed. If you have any questions about the logistics of the program, please feel free to post your questions here in the C# Workshop – Project 3 Forum. I do, however, request you not actually submit your entire source code until at least 1 week has passed. Though feel free to ask for help about sections you’re having a problem with. I encourage all people participating in the C# Workshop to complete this project, as you can be assured it will be used again in later projects. As before, I will try and provide hints every few days for the next week and a half or so, to help people keep moving. Feel free to use or not use my advice or hints, as they just provide insight into A WAY to implement this project, not necessarily THE WAY. Cheers and GOOD LUCK!

There are a few completed versions posted in the Project 2 thread. People can feel free to use those as learning tools while completing their own.