Tamagochi were all the rage in the 90's as a small toy that had limited functionality but modelled a pet.
The "owner" could do the following

• Feed the pet

• Heal the pet

• Play with the pet With that in mind, over time the "pet" would

• Get Hungry

• Get ill

• Get Bored

Note:

Create methods for making the "pet" hungry, ill and bored to demonstrate your class working, if you're feeling particularly clever, feel free to make these things happen over time.

Stage 1

You are to design, implement, test and provide suitable documentation for a program that mimics the operation of a tamagochi

Your program is to operate continually, allowing the owner to interact with the tamagochi, choosing from a main menu until they choose to stop by selecting an appropriate option.

Your program should include at least two working methods.

On termination the program is to display the final Status of your tamagochi. Your program does not need conform to an Object Oriented approach or deal timescales or time functions (see 3 below).
A very simple User Guide is expected to be provided.

Stage 2

As Stage 1 above but ALL methods for interacting with the tamagochi must be implemented.

Your program does not need conform to an Object Oriented approach or deal timescales or time functions (see 3 below). A very simple User Guide is expected to be provided.

Stage 3

As Stages 1 and 2 above but now your tamagochi should work continuously whilst the program is running, calculating how much time has passed to then inform methods for the tamagochi to incrementally become hungry, tired and bored. When the user interacts with the tamagochi, these values should be reset.

Your program should also have an Object Oriented approach

Stage 4

As Stages 1, 2 and 3 above plus at least one of the following additional

1) Your tamagochi should provide a user interface and a pictorial representation of the tamagochi and its status on the screen.

2) Add methods to your tamagochi so that you can instantiate 2 objects and have them interact in some way.

3) You may choose to record ‘performance' or ‘shut-down states' in an external file.

Guidelines and marking criteria

The intended audience for your report is to be considered that of your fellow students.

Presentation is to be typed, neat, legible, well structured and organised with a front page identifying what the report is, and who submitted it, a Contents page and page numbers.

Make sure that the work is clearly marked with your Student Identification Number (use of footers is useful should your report become separated).

All work is to be ‘fixed together' (preferably in a folder of some sort). If you do not wish to buy a folder I will accept stapled work as long as I can open it and read it easily and it does not fall apart.

Refer to the Generic Mark scheme for breakdown of scores.

Design

You are expected to provide documentary evidence of design. The design tool for this is to be ‘pseudocode' as used in the module notes. The pseudocode is expected to be indented where appropriate, as shown in the examples in the module notes.
The level to which you take the pseudocode is to be at your discretion.

Supplementing the pseudocode with other design methods that you are familiar with is acceptable, but not expected, and may not necessarily improve your mark for this section. You should also create a CRC card to demonstrate your knowledge of OOP, to include Methods created.

Coding

Marks will be given for suitable use of presentation (i.e. indenting), meaningful variable names, suitable commenting of code, legibility of code etc.

Marks will also be awarded for an Object Oriented approach when necessary.

The code is expected to match the design document.

A program that does not perform all the requirements will not necessarily be considered a failure - it can still earn marks for what it can do and how it does it. Clearly document any shortcomings.

Test Plan and Testing

A well planned, executed, and recorded test regime is to be provided. It should reflect the design intentions and the program created (even if the code does not ‘fully' meet the requirements stated). A proposed test plan layout can be seen in the module notes. You need not copy this exactly, but whatever plan you choose to use, it must be easily read, accurate, and thorough i.e. all operations in your code are expected to have been exhaustively tested and recorded in a repeatable manner.