Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

COMPENG 2SH4 Course Project [100 marks]

You must submit all the source codes to both the Git Repository and Avenue to Learn dropbox before the posted code submission deadline.

IMPORTANT: Your submission must compile without syntactic errors to receive grades. Non-compilable solutions will not be graded.

About the Course Project

Tips for Completing the Course Project

Project Introduction 

Snake game is one of the most common introductory programming projects that allows many programming principles tobe applied in practical scenarios. The snake game can be further customized with different data structures and algorithms for improved user experience and increased variety of gaming modes. As a result, the CE2SH4 project will take on the C++ OOD version of the snake game, constructed from the ground-up using all the C procedural and C++ OOD knowledge that we have covered in the course. Moving into the subsequent COMPENG courses, more customizations and improvements will be added to the CE2SH4 project, thereby illustrating the advantages and applicability of different data structures and algorithms in CE2SI3 and CE3SM4. It is important to note that the design experience covered in this project is mostly transferrable to other programming languages – even including the assembly language in CE2DX3.

Your project team’s goal is to create the same game using the OOD principles described in the Project Procedure section. Submissions not written in C++ OOD structure will not be accepted.

A sample executable is provided for your reference. All above-and-beyond features are not included in it.

Project Starter Code

A separate test suite project is provided to allow you to develop an Array List classindependently of the main project, using the test-driven development approach that you have used in all the labs. The validated Array List class will then be includedas a data member of the Snake object in the project implementation, similar to how you have done in Lab 3 for the customstring library/class.

Recommended Workload Breakdown

Preparation (Both Developers Together)

Implementing player object phase 1 – FSM transplant from PPA3, single segment movement validation after OOD refactoring. 

Phase 2

Ex. Shorten the snake body while increasing the score by 10, etc.

-Note: In the project, this above-and-beyond feature is a true bonus. This means that you can score beyond 100%in the project!

Project Overview – UML

In the simplified UML diagram illustrated here, objects and data members that are marked in RED are mandatory – theyare part of the skeleton code and will have to be implemented. You may expand on them but do not modify orexclude/delete their basic provided form. Other objects built on top of these mandatory features are customizable to yourdesign approach.

Mandatory Objects Implementation (Shown in RED in the UML diagram above)

-Object Position Class with Pos Struct holding X-Y Coordinate Information

- Object Position Array List Class

- Data Members involving the above two classes

IMPORTANT: Submissions that do not respect this design criteria will not be graded. Zero marks will be awarded for the project component of the course. 

The design of these mandatory objects is intended to be somewhat overcomplicated, and you will have a chance to apply your OOD intuitions on how you would improve this portion of the design at the end of the project. 

objPos – Object Position Class

For this OOD project, the bottom-up design approach is deployed. Recall the game board that we have been using in PPA2 and PPA3 – every single ASCII character on the game board has a unique x-y coordinate as well as its ASCII character representation, or symbol so to speak. Every single feature drawn on the game board, whether stationary or moving, occupies exactly one ASCII character space. As a result, it makes sense to objectify the ASCII character space on the game board into a class “object position”, or objPos in short.

Important Advantage: This encapsulation results in a critical simplification – throughout the remaining design process, every new class we deploy will remain coherent in handling game board coordinate information, as long as they all use the objPos class to track positional and symbol information. Analogously, objPos is our 1x1 Lego block, the smallest unit from which all bigger Lego pieces can be derived and positioned upon.

Unusual Design Choice: However, this encapsulation design deploys an additional struct, Pos, as positional struct containing the x-y coordinate information. The objPos class holds a pointer that can refer to an x-y coordinate instance on the heap or simply leave it uninstantiated. While one can claim that this is a memory-conserving strategy, it is up to you and your teammate to discuss at the end of the project whether this is a good design choice, and if not, how would you improve it. However, throughout the project code development phases, you will have to accept the objPos class design as is – as if you are tasked by your supervisor to develop the software with the existing and unchangeable design blocks.

Rule of Six / Minimum Four: As we plan to instantiate, copy, assign, and pass objPos instances very frequently in the Array List as well as in the game implementation, it makes sense to apply the Rule of Minimum Four. You and your teammate must implement the required special member functions to ensure no memory leakages or errors occur throughout the game runtime.

objPosArrayList - Object Position Array List Class

As discussed in class, Array List, or list in general, is a continuous sequence of items organized in an orderly fashion. An array list of objPos class therefore is a continuous and orderly sequence of ASCII symbols on the game board. We can use it for at least the following purposes in our project:

For any additional features, you may find list being an optimal building block as well. We will examine more of these features in COMPENG 2SI3.In Lego analogy, objPosArrayList is our 1xN Lego strip. Who does not love 1xN Lego strips? It may not be as atomic as the 1x1 block but is much more convenient and structurally sturdy. With different varieties of 1xN strip, we can achieve different designs faster and more reliably. This is the power of List in software design.

Since List is such a powerful building block, encapsulating it into an object is the next sensible move in the bottom-up OOD process.

As far as the Rule of Six is concerned, objPosArrayList can be designed with just the default constructor and destructor, as the typical usages of a list, at least in this project, do not involve “copying list contents to make another list”, or “passing the entire list by value into a function”. As a result, copy constructor and copy assignment operator overload are optional.

The objPos and the objPosArrayList classes together complete the groundwork of our project. We are now ready to take on the Snake Game using OOD principles in C++.

Recommended Basic UML Design

For your reference, here is the more detailed UML design containing our recommended features. Your implementation can deviate from this recommended design, as long as the RED mandatory features are identical.

Marking Scheme

The project has a total of 100 marks and the following two evaluation components:

The evaluation schemes of these two components are outlined as follows.

All project groups will be randomly paired up with another team. Completing the peer code evaluation on time will earn your team a total of 25 marks.

For Peer Code Review, do not exceed 2 paragraphs per question.

For Project Reflection, limit the discussion in two pages with supporting UML diagrams.

Peer Code Review: OOD Quality

1. [3 marks] Examine the main logic in the main program loop. Can you easily interpret how the objects interact with each other in the program logic through the code? Comment on what you have observed, both positive and negative features.

2. [3 marks] Quickly summarize, in point form, the pros and cons of the C++ OOD approach in the project versus the C procedural design approach in PPA3.

1. [3 marks] Does the code offer sufficient comments, or deploys sufficient self-documenting coding style, to help you understand the code functionality more efficiently? If any shortcoming is observed, discuss how you would improve it.

2. [3 marks] Does the Snake Game cause memory leakage? If yes, provide a digest of the memory profiling report and identify the possible root cause(s) of the memory leakage.

Recall the unusual objPos class design with the additional Pos struct. After reviewing the other team’s implementation in addition to yours, reflect on the following questions:

Please provide your genuine and engineeringly verifiable feedback. Ungrounded feedback will lead to deductions.

Functional Evaluation by Teaching Team

Your project will be evaluated functionally by the teaching team with the provided marking scheme, and the peer code review results will serve as a validation reference. Functional evaluation by the teaching team will earn you 75 marks.

[Submission Not Accepted] The project must be compilable from GitHub pull. The teaching team will not debug for any syntax errors. Triple check your submission before doing Git push.

[Penalties] The project must be developed on top of the objPos class and the objPosArrayList class. If you do not utilize these classes properly then the maximum score will be capped at 50%. If you do not use these classes at all and take a non-OOD approach, 100% marks will be deducted.

Full Functional Evaluation [Total 55 Marks]

WARNING! These features are only evaluated if your project delivers all the basic Snake game features. If your submission does not result in a functional classic Snake Game, you will not score any additional marks in this section.

• [3 marks] Food bin class implemented with objPosArrayList composition.
• [1 mark] Sensible random food generation logic for generating multiple random food items around the board.
• [1 mark] At least 1 special food feature leading to different snake growth and/or scoring behaviour.

Recommended Workflow

As usual, you may choose to use the recommended workflow to complete the project using our recommended OOD approach for your learning purpose. Besides the mandatory features described in the previous section, your team is free to deploy your own design to complete the project, as long as the OOD principles are respected.

Reminder AGAIN!! Unless you are an experienced programmer, DO NOT attempt to develop this program in one shot. Always, ALWAYS make sure the current feature is working as intended before adding more features to prevent creating a debugging nightmare.

If this is your first time working with an OOD language, please watch the briefing video and attend all the in-class/in-tutorial coding activities. Most of the implementation procedures will be demonstrated in the live coding sessions.

Use Iterative Workflow! Iterative design strategy is an absolute must as you progress on to higher level software courses. With less hand-holding instructions provided in the project manual; iterative workflow will help you keep the software development under control.

Pay Attention to Dynamic Memory Allocation! Remember to return every single piece of heap memory back to the computer when done with it! In OOD, this translates into:

• Read the skeleton source code and the comments to get a good understanding of the code structure.
• Apply the Rule of Six / Minimum Four to complete the implementation of the provided objPos class.
• STOP! You must complete the objPos class implementation with all the required special member functions to avoid memory errors and other disasters. Do not proceed until done.
• Create a new Draw routine implementation to draw the game board border using ‘#’ as its symbol, and a few ASCII characters on the game board with arbitrarily chosen coordinates and symbols.
• Many features will be very similar to what you have seen in PPA2 and PPA3.
• STOP! Make sure the above implementation is validated using objPos class, NOT your own custom implementation.
• DO NOT PROCEED UNTIL BOTH TEAM MEMBERS ARE FAMILIAR WITH OBJPOS CLASS USAGE

From this point onward, the recommended workflow assumes that the two members are working in parallel. Each pair of parallel paths in the same iteration is denoted as A-path or B-path. Nonetheless, your team may still choose to follow these iterations sequentially, allowing both team members to learn the OOD workflow together. Neither approach is incorrect.

Iteration 1A – Player Class Implementation

This refactoring task may appear rather unnecessary with the current project scope; however, Snake class encapsulation will prove to be an extremely beneficial task as we move into COMPENG 2SI3.

The class diagram of the Player class is not complete yet. It only contains thefeatures to be refactored from PPA3. The rest of the features will be implemented in Iteration 3.

• Private Data Members (Fields)
• objPos playerPos
• Holding the player position and its ASCII symbol.
• enum Dir myDir
• The direction enumeration instance for tracking the direction state of the player.
• GameMechs* mainGameMechsRef
• This is a typical OOD-based object feature – object holding the reference of another object it will interact with in the program runtime.
• Upon Player class instantiation, the reference of the GameMechs in the main program must be passed into the Player object in the constructor, so that the player can call the methods in the GameMechs class for whatever information / interaction is required.
• Hint: Moving forward, any new classes added to the program that will interact with the Player object must pass their reference into the Player object. The Player class in turn must hold a reference to every object it will interact with.
• • Public Member Functions / Methods (Interface)
• enum Dir {…}
• This is the same enumeration from PPA3. Just copy it over and place it in either public or private scope.
• Player(GameMechs* thisGMRef);
• Constructor
• Must require the GameMechs reference so to access the boardSizeX and boardSizeY when determining the movement wraparound.
• ~Player()
• Destructor. Delete heap members here to prevent memory leak.
• objPos getPlayerPos() const
• Getter method for obtaining the current position of the player (Snake head).
• The objPos is returned by value.
• void updatePlayerDir()
• This method should contain the player FSM.
• It obtains the most current input from the GameMechs reference, updates the FSM as needed, and clears the input buffer via GameMechs reference.
• This method should be called in every game loop in the main logic.
• void movePlayer()
• This method should contain the player position update algorithm.
• This method should be called in every game loop in the main logic.

For ease of development, define and implement the Player class at the top of project.cpp. Only package the contents into Player.cpp and Player.h when done with the class development.
Implement all the data members, the direction enumeration, the constructor, and the destructor.

• In the constructor, make sure to initialize the Player initial position and the symbol the same way as in PPA3.

For simplicity, you should use the ASCII character ‘ * ’ (asterisk) for representing the player object.
Implement the getPlayerPos() method.
STOP! We need to test the above features first before proceeding to implementing FSM and position update.

• Declare a pointer to Player object in the global scope.
• During initialization, instantiate a player object on the heap and keep its reference in the global pointer.
• Update the draw routine such that it draws the Player object at the correct position with the correct symbol.
• Do not proceed until you can confirm that the player object is correctly drawn on the game board.

Next, port the FSM implementation from PPA3 to updatePlayerDir() method.

• Make sure to update the statements involving user input – you now have to access it via the GameMechs reference.
• Deploy debugging messages to confirm your FSM is correctly responding to the keyboard input.
• Then, in the main program loop, call this method on the Player object in the suitable routine.

STOP! Do not proceed until you can confirm your FSM is responding to keyboard inputs correctly!
Finally, port the player position update logic from PPA3 to movePlayer() method.

• Again, remember that boardSizeX and boardSizeY are now part of the GameMechs class. Use the reference to access them when dealing with border wraparound.
• In the main program loop, call this method on the Player object in the suitable routine after updatePlayerDir().
• STOP! Do not proceed until you can control the player object movement the same way as in PPA3.

Iteration 1B – Refactor PPA2/PPA3 Code and Deploy the Game Mechanism (GameMechs) Container Class

However, you may realize in PPA3 that these features result in rather scattered variables in the global scope (bad practice). When accessing them, you would need to be extra careful to prevent tempering the values in them. In addition, you need to be highly aware of their visibilities around the program, so to access them correctly in the correct routine. This is one of the shortcomings of procedural programming – when designing a program without too much organizational effort, your program works well but does not sit well with feature expansion. The OOD features in C++ are intended to enforce code organization through syntax features, so that your code can be more expansion friendly. Of course, this is assuming that you are not using C++ only for procedural programming.

As a result, we recommend deploying a GameMechs class. This class can be referred to as a container class, because its main purpose is like a toolkit used to collect and manage scattered parameters related to the underlying game mechanics under a single class for ease of parameter management.

Such a class may not be necessary in smaller software projects, because the organization effort of creating such a class is not expected to outweigh the effort of maintaining individual parameters without functional confusion. However, as a sustainable practice, for any work under development, container classes like this are often deployed anyway so to “leave the hooks” for future feature expansions.

There is no right or wrong here, just engineering trade-offs.

The class diagram provided is the most basic design. You may need to add more fields and methods as needed in future iterations.

• Create a pointer to GameMechs class in the global scope. You should delete all other global variables related to game mechanics (in fact, you should delete all global variables other than the GameMechs pointer).
• During initialization, create a GameMechs object on the heap, and initialize its fields accordingly.
• Update the program loop so that it is accessing the exit flag in the GameMechs object instead of the global flag (which should now be removed).
• In input collection stage, collect the input ASCII character into the corresponding field in the GameMechs object using thecorrect setter method.
• In input processing stage (main logic), access the correct field in the GameMechs object through the getter method to process the input character, choose the correct action, then clear the input field in GameMechs to avoid double-processing the input.
• In the clean up stage, make sure all the required end-game actions are taken before deleting the GameMechs object from the heap.
• STOP! Make sure the above features are implemented such that you can start the program and shut it down using your selected exit key before proceeding onward.
• After the basic GameMechs class is validated, you should further implement and confirm the following features:
• Set up a debug-use key to test whether you can increment the score in the GameMechs object. Print appropriate debug messages to confirm its functionality.
• Set up another debug-use key to test the lose flag. Make sure you can print different messages at the end of the game according to the lose flag status.
• STOP! Make sure the above features are implemented and validated before proceeding onward.

It is important to note that the above GameMechs features are NOT the complete set of features. Your team has 100% freedom in adding / removing features to and from this container class as needed to make your game more feature rich.

By completing iteration 1, you will have refactored your PPA2 from a procedural C program into the Object-Oriented C++ program. Please confirm that your project code works identically as your PPA2 code (yes, NOT PPA3).

Iteration 2A – Deploying and Validating objPosArrayList Functional Class

The objPosArrayList class can be referred to as a functional class, because its instances serve as the functional backbone of many other larger objects in the project. A separate folder named “objPosArrayList_TestSuite” is provided in the project repo to allow you to develop the objPos array list using the provided test bench project. You can also set the workspace temporarily to the Array List project folder to run the debugging session on it. The UML class diagram of the objPosArrayList class is provided for your reference.

The description of each data member and member function is provided below.

• Private Data Members (Fields)
• objPos* aList
• Pointer to the start of an objPos array list, with the array size specified by arrayCapacity.
• Heap Data Member.
•  int listSize
• The number of valid list elements in the list.
• int arrayCapacity
• The number of array elements allocated in the heap array.
• Public Member Functions / Methods (Interface)
• objPosArrayList() / ~objPosArrayList()
• Array List Constructor
• Initialize the arrayCapacity and listSize data members.
• Allocate an array on the heap with the size specified by arrayCapacity.
• The default arrayCapacity is 200. You may change it as needed.
• Array List Destructor
• Deallocate all the heap data members.
• Defense against memory leakage.
• int getSize() const
• Returns the size of the list (i.e. listSize).
• NOT the arrayCapacity (Array Capacity!!).
• void insertHead(objPos thisPos)
• Inserting thisPos as a new objPos element to the head of the list.
• Do you need to “shift” the elements? Think about it.
• void insertTail(objPos thisPos)
• Inserting thisPos as a new objPos element to the tail of the list.
• Do you need to “shift” the elements? Think about it.
• void removeHead()
• Remove the head element from the list.
• Do you need to “shift” the elements? Think about it.
• void removeTail()
• Remove the tail element from the list.
• Do you need to “shift” the elements? Think about it.
• objPos getHeadElement() const
• Return a copy of the objPos element at the head of the list.
• objPos getTailElement() const
• Return a copy of the objPos element at the tail of the list.
• objPos getElement(int index) const
• Return a copy of the n-th objPos element from the list, where n is specified by index.

STOP! Make sure you have passed all the default test cases, as well as some additional test cases of your own, before proceeding. The robustness of your array list implementation will critically affect the debuggability of your code in future iterations.

STOP! TRUST ME, VALIDATED LIST ROBUSTNESS IS AN ABSOLUTE MUST!

Once fully validated, you may copy the objPosArrayList.h and the corresponding .cpp file from the objPosArrayList_TestSuite folder into the main project folder.

Your custom Array List for handling objPos is now ready.

Iteration 2B – Random Food Generation

In this iteration, the random food generation mechanism will be deployed in the project. You have two design choices to implement the Snake Food:

There is no right or wrong here. The only difference between the two design choices is that the former one (on the left) saves you time right now but may present more challenges later when developing advanced features (bonus part), while the latter one (on the right) will incur more work right now but will give you an easier time if your team chooses to implement above-and-beyond bonus features.

Either way, here are the high-level steps you should take to make sure the food generation mechanism can be implemented. The steps below are only for generating a SINGLE FOOD randomly on the board.

We now have completed the C-to-C++ OOD refactoring for all the in-game objectsin PPA3 and are ready for further feature expansion using our objPos array list.

We now have all the required features ported from PPA3 and refactored into C++ OOD style, and there are only three more features to implement in the Player class to complete the Classic Snake game implementation.

Feature 1 – Snake Body Implementation using Array List

The key to keeping track of all the snake body segments on the game board is the use of Array List. The diagram below illustrates the basic idea.

The conceptual trick here is that the snake movement takes place by inserting a new snake segment to the head of the list at the targetx-y location after the movement and then removing the last snake segment from the tail of the list. This way, the visual snake movement can be completed as easily as one list insert and one list removal. To implement this clever snake movement algorithm, we need to deploy one of the most commonly used OOD principles – Composition. More specifically, we need to make use of the Array List object that we have previously created, turn it into a member of the Player object, such that the Player object can be said to be “an object composed of another object”.

Here is the high-level procedure for realizing this composition relationship:

STOP! Make sure you have validated the composition implementation carefully with at least three different initial snake lengths (1, 3, 5, etc.). Check all the wraparound logics, movement correctness, etc.

DO NOT PROCEED UNLESS FULLY VALIDATED

Feature 2 – Snake Food Consumption and Snake Body Growth (also Score)

Once you get the first feature implemented, you’ve completed the most challenging OOD feature of the project. The remaining two features simply build on top of feature 1.

For snake food consumption, here is what you need to do:

As for the score system, it is as simple as getting the list length of the playerPosList from the Player Class. This is left for you to implement on your own.

Feature 3 – Snake Death Check (Game Over Condition)

At this stage, you should be fairly comfortable with the gist of OOD – incremental design within the class and/or classes involved. Thisdesign flow guarantees that changes are only made in the confined scope of classes and will not accidentally spill over to unrelated components of the project by accident.

Now, looking at the game over condition, you probably can see that this is a behaviour change within the Player Class, and you probably have a clear game plan of how to implement this.

Here is the high-level procedure for your reassurance:

And, at the end of the COMPENG 2SH4 project, you should know very well the drill – STOP!!! Do not proceed until you have tested the feature well.

Additional Iterations – Above and Beyond Feature (Bonus 5% for Project)

As usual, this section contains only tips and high-level guidelines for deploying the above-and-beyond features. However, note that in the project, the above-and-beyond features count as an additional bonus (unlike the PPAs which had no bonus). Do not attempt these features unless your team has completed and validated the base implementation of the project.

WARNING! It is HIGHLY recommended to keep a working copy of the base project implementation as a fallback submission. (Or learn about how you can revert your project back to an earlier version using an appropriate Git command).

Remember, we will only accept compilable solutions.

Bonus Feature – Generating more than 1 food objects at random positions with special food functions.

The only unacceptable solution is an OOD-decomposed solution, a.k.a. a solution with only procedural programming approach with absolutely no regard for OOD principles.