Homework: Pong
Goal
Reimplement the classic arcade game ‘pong’ using SDL2. More information on the game ‘pong’ can be found
Core Requirements
The following core requirements should be implemented (the weight of each requirement is provided for your convenience):
• The game should be played in an 1024x768 window. Changing the size of the window should be disabled (10%).
• A well-defined game loop that coordinates game timing and event management (20%).
• A single player version should be implemented where the user controls a single paddle (15%), and the computer the other paddle (15%). The paddle can be moved by keyboard or mouse
(one method of control is sufficient). The paddle of both the player and the AI should move at a constant speed.
• A ball should bounce of the top and bottom edge of the playfield and the direction of the ball should change to the reflected direction (15%). To add an element of uncertainty, a small
random perturbation could be added/subtracted from the reflected direction (5%).
• A player scores when the ball hits the edge of the competitors’ side (5%).
• The game starts with both players having zero points, and ends when one player reaches 11 points. A message should be shown to indicate whether the player won or lost. The player should have the option to restart the game or quit (10%).
• The current score should be shown in the window (5%).
Bonus Features
In addition to the above core requirements, additional bonus points can be obtained by implementing one or more of the bonus features listed below.
• Additional support for correct resizing and maximization of the window (10%). As well as pausing of the game when the window is minimized (5%).
• Add sounds when hitting a wall, pad, or when the ball is leaving the screen (15%).
• Make the pad moveslower when just starting to move, and accelerate the longer the pad is moving in the same direction up to some maximum speed (10%).
• Take the speed and direction of the pad motion in account when computing the reflected direction (15%).
• Add obstacles (10%).
• User selectable difficulty by setting the game speed (i.e., more difficult == faster game) (10%).
• Add a title screen with selectable options (e.g., which pad to play with, difficulty level, etc...) (15%).
• Add randomly placed power-ups that can be enabled to hitting it with a ball (e.g., hold ballon pad, safety net behind pad, double size pad, etc..) (10%).
• Something else creative (?%)
Practical
This homework should be solved using the SDL2 library (we use SDL version 2; we will not use the legacy 1.x SDL version, or the recent SDL3). Precompiled libraries exists for a wide variety of operating systems and C++ compilers. SDL2 should be preinstalled on the lab machines. This homework also relies on
CMake (http://www.cmake.org) to provide cross platform Makefile support (CMake supports both
Linux and Windows). Linux or OSx requires minimal additional packages to be installed (Ccompiler,
CMake, and SDL2). Many distributions include precompiled packages (note: when installing SDL2 also
include the ‘development’ version if available). For windows I recommend using MSYS2 with MinGW64 as C++ compiler. Warning, windows setups area bit more complicated, so start early. Please refer to the README.txt file of the skeleton code for detailed setup instructions for Windows-based machines.
A skeleton-code that provides a basic SDL2-based ‘Hello World’ program. You will need to request access to the repository (open the URL in your web-browser, login, and select the three dotson the right next to the project title). Once
you have you should ‘fork’ the project as private in your own code.wm.edu code repository (button on the right next to the title). Next, goto Manage->Members and invite me (ppeers) as “maintainer” (the default is “guest” which is not sufficient), with an expiration date of 06/01/2025. Next, create a token (or setup an ssh key and use git:// instead of https:// below): Settings->Access Tokens (set your role as Owner, and enable all options). You can now clone the project with :
git clone https://code.wm.edu/
(replace
alterations. Do not forget to commit your changes (git commit -am ‘Description of change’) and push your commits to the server (git push).
It is highly recommended to start from this skeleton code; you must use the CMake configuration. To
compile the skeleton code (see the included README.TXT), create a subdirectory ‘Debug’,and from
within this ‘Debug’ directory run'cmake ..' to generate the Makefile. SDL2 might not be found if it is not
installed in a standard location. You can specify to cmake where to search for SDL2 via the “-DSDL2_PATH=
cmake -DSDL2_PATH=/home/me/nonstandardlocation/SDL2 ..
Don’tforget the ‘dot dot’ at the end. If you want to use a different compiler than the default (on linux or OSX) or in case there is no default compiler (Windows), you will need to specify to cmake for which compiler to generate Makefiles for. For example, if you want to use mingw64 as the compiler, then:
cmake -G “MinGW Makefiles” ..
Please run ‘cmake’ without arguments to get the full list of compile targets. Note, if you want to change your compile target, it is best to fully remove the代 写A Game pong using SDL2 ‘Debug’ directory, and recreate it.
Normally, you do not need to rerun cmake, unless in the situation described below. The CMake files in this skeleton have been setup to simplify adding files without the need to alter the CMake files:
• If you want to add a new executable, just add the corresponding ‘ .cpp’ file in the 'bin'
subdirectory, and rerun 'cmake ..' to update the Makefiles. This cpp file should contain a ‘ main’ function.
• If you want to add a source file, just add the corresponding ‘ .cpp’ file in the 'src'subdirectory, and rerun 'cmake ..' to update the Makefile. These source files should not contain a ‘ main’
function.
• If you want to add a header file, just add the corresponding ‘ .h’ file to the 'include' subdirectory. You do not need to update the Makefile by rerunning cmake.
• Adding an external library requires more work – you will need to add a FindPackage entry in the CMakeLists.txt file. Please refer to how SDL is added in the included CMakeLists file as a template.
In case you want to remove all compiled files, just remove the ‘Debug’ directory. Based on the directory name,cmake will generate a makefile to compile your code in either Debug or Release mode. In Debug mode, debug information is included in your executable, and certain checks are included. Release mode, runs faster, but it is advised to on use this when you know your code works. To compile in release mode, just create a directory ‘Release’,and run ‘cmake ..’ from within this directory.
Submission Details
Fork your own version of the homework code skeleton as soon as possible. Granting access requires me to take action, and thus is not instantaneous. Do not change the repo name I will clone your project on or after the deadline, and use the cloned version to grade your project. Make sure you have your final version committed by the deadline
and you have added me as “ maintainer” to your repo (preferably as soon as you fork the repo)! The delay between the deadline and granting me access (as “ maintainer”) will be counted as a late
submission. In addition, by the deadline you need to add a PDF report (max 1 page) in the root of the forked repository, named ‘report.pdf’ (git add report.pdf) that contains the following information:
o Time required to finish the core requirements this homework
o Time spend on the bonus features (if any).
o A list of any external libraries (besides STL or Boost) that you used and why.
o A list of core features that do not work correctly.
o A list of implemented bonus features, indicating whether they work or not.
Remarks
• The estimated time required for the basic requirements is 16 hours, excluding time to master C++.
• This homework accounts for 2/9th of the total for this course. Additional bonus credits (max 1/9th) can be obtained by implementing the bonus features.
• The grading for this homework will be as follows:
o 5% whether or not your code compiles (without excessive changes to the compile process).
o 50% on correctness and playability. Does the ball move correctly? Can the pad be
moved correctly? Are scores being tracked? Does the game end? The percentages
listed in the ‘core requirements’ and ‘bonus features’ pertain to this component of the grade.
o 25% on code quality. See below.
o 15% on the separation in the code of logic versus view(s).
o 5% on the report.
• This is not a group project; this homework should be solved alone.
• You are not allowed to use existing SDL pong solutions found online - your code will be
compared to available online solutions, and if a (partial) match is found, you will receive 0 credits.
• You are allowed to use external libraries, but you will need to justify their use in your report. In general, external libraries should be used sparingly. If in doubt, contact the lecturer.
• Late policy: score -= ceil(hours_late / 24) * 10. Negative scores are possible. An extension needs to be requested at least 48 hours before the deadline. Each extension request needs to clearly justify why the extension is needed.
Code Quality Criteria
• Clean readable code. Feel free to pick any bracketing style you prefer, but be consistent. Indentation help is making the code readable. Use a consistent indentation style.
• Sufficient comments.
• Your code should be Object Oriented. There should not be many functions or constants not contained in a class. Each class should be meaningful; a near-empty class or a data container is
only needed in exceptional circumstances. Similarly, avoid putting (almost) all code in a single big class. If you class exceeds 250 lines of code, you should carefully consider if your design is good.
• Your class should enforce access via access specifiers (public and private). Your code should expose the very minimum of its internals.
• Only when a user is allowed to alter class data members without limits or side-effects, only then should a user from outside the object have direct access to data members; use getter and setter methods otherwise.
• Methods should be placed in the proper class. A method should only alter the state of the
object it belongs to (it can call modifiers on another class). An object should never be
responsible to keep the state of another object consistent. For example, a ‘Game’ object should never have to worry about whether any coordinate of a ‘ Ball’ object’s position is positive. This is an example that the position of the ‘ Ball’ should be private, and the set method in ‘ Ball’ should check the condition (i.e., position remains positive).
• Each class should have its own header file and source file. There should not be anything else in the header/source file.
• Each header file should have proper #ifndef guards (see CPP overview lecture). No #pragma
• Pass method parameters by reference. Only when passing basic data types (Boolean, int, char, float, double, long, pointers) may you pass them by value. Avoid passing pointers as a
parameter unless the variable was originally declared a pointer.
• Correct use of ‘const’ on both parameters being passed to methods, as well as the methods
themselves (see C++ overview lecture). In general, if a method does not alter the object, then it should be declared const (e.g., void getValue(void) const). Furthermore, if a variable is passed by reference and its content will not be altered by the method, then pass as const (e.g., void
addHealth(constint& increment)).
• Data that is always passed as whole, likely needs to have its own container class/type. For example: void setColor(const Color& col) instead of void setColor(int r, intg, int b);
• Do not use SDL data types to pass data to non-SDL methods. For example, don’t use SDL_Point to represent 2D points. Write your own point class. The reason for this is that you want to
have a strict separation between view and logic (SDL should be fully contained in the view). You can add methods in your data containers to cast to SDL types.
