C++代写:FIT2071-TextQuest2

Task Details

The Weeks 4 to 7 laboratory exercises contain a designated “Main Portfolio Exercise”. These are a series of exercises that add to each other to form a main portfolio program: ClassyTextQuest. Note that these build upon the Weeks 2-3 portfolio exercises for request 1. If you did not satisfactorily complete request 1, you may optionally use the sample code for request 1 available on Moodle. You are to submit a final, completed version of the game, along with a document detailing your program design (diagrammatically explaining the class structure and textually explaining the operation) and detailing any changes to the specification, including all extra functionality and advanced concepts.

Successful completion of the exercises as described in the laboratory exercises may obtain you up to a maximum of 80% of the total request marks. In order to obtain a higher mark you should seek to include some advanced functionality (as described in the Bonus sections of the portfolio description). The additional functionality should demonstrate advanced or more complex application of principles covered to date. It need not be large amounts of work but should demonstrate a willingness to explore new and advanced concepts. You must detail what you have done in the accompanying document.

Explicit assessment criteria are provided over the page, however please note you will be assessed on the following broad criteria:

  • Meeting functional requirements as described in the exercise description
  • Demonstrating a solid understanding of the C++ concepts taught up to and including week 7, including good practice
  • Following the unit Programming Style Guide
  • Creating solutions that are as efficient and extensible as possible

NOTE! Your submitted program MUST compile and run. Any submission that do not compile will be awarded zero marks. This means you
should continually compile and test your code as you do it, ensuring it compiles at every step of the way.

If you have any questions or concerns, please contact Tim as soon as possible.

Week 4

Design

This week we are going to reconsider the design for request 1.

Start thinking about how you can use object oriented design to achieve a more structured program.

What could be the different classes in the TextQuest game? What data members and member functions (methods) do these classes need to provide?

Create a diagram (any drawing software or just pen and paper is fine). You will eventually need to submit your design together with your working code as part of your documentation.

Remember we have a character, vocations, events and maybe more depending on what extra functionality you have considered: e.g. enemies, items, etc.

Coding

Now we are going to consider how some of the new C++ features we have learned can help us better structure our code and add extra features.

Functions:

How can you reorganise your code from request 1 into clearly defined functions that keep the different “concerns” of the program well separated? For now, create some functions in the global scope of your main C++ file from request 1. In coming weeks we will learn how to separate these across different files and achieve better “encapsulation”.

Arrays:
You may have found the gameplay from request 1 became tedious after a while since the events always occurred in precisely the same order. Let’s start to make it more interesting. Change your program to load the events into two arrays (an array of descriptions and another for the health modifiers).

Last week we had a lab exercise to generate random numbers from 0 to 100. Now you can do the same thing, to generate a random number between 0 and the number of events, in order to randomly select which event comes next.

Week 5

This week we will continue our rewrite of TextQuest with classes. Now that you can write your own custom classes, it is time for you to write three of the classes you will need for your game. These should be based upon your Class Diagrams from last week.

Week 6

This week we are going to create two new classes: Player and Enemy that both inherit from Character.

Character will have a virtual function called attack. The attack function’s parameter is a list (such as a vector) of potential target characters.

The Player class’ implementation of the attack function should prompt the user to choose one of the targets. It will then apply damage (a health deduction) to the target based on the relative magic and strength of that target (up to you precisely what formula to use – choose something that seems fair and fun).

The Enemy’s attack function will also choose a target but do so automatically (i.e. without prompting the user. There are different strategies enemies might use: e.g. always choose the player, do it randomly or based on any logic you like: it could even damage multiple targets!).

Now, in the main game loop, in addition to the events that are currently being applied, you should add a random chance of a fight occurring (make fight a separate function).

When a fight occurs, you should populate a vector of Character containing the Player and also one or more randomly generated Enemy. Now a sub-loop should start iterating over the vector giving each Character a chance to attack. That is, you will call the Character’s implementation of the attack member function, passing in the contents of the Character vector. After the attack is complete, remove any dead characters (whose health is <= 0) from the vector. If the Player is dead, the fight and the game ends. If the Player is the only one left, then they win the fight and you can return to the main game loop.

Bonus: how you generate the enemies is up to you. A simple way would be just to have random stats and a random name (from a list of possibilities). Alternately, you could design sub-classes of Enemy, each with their own interesting variation on the attack function - and randomly choose which ones to construct in each fight.

Week 7

This week we will finalise our Classy TextQuest RPG. To this point you have the basic skeleton of the game as well as classes for the major components (e.g. Character, Player, Enemy, Event, Vocation, etc). Now that you know all about pointers and class inheritance you can finish off the classes and the final game play. Also, we talked this week about overloading the operator. Have a think about where you might use this in your code. You also know how to plug memory leaks now, so make sure any objects you create with new are also deleted at the appropriate time.