CSE 1321 Lecture

You are free to create an original game or implement a game that already exists.  Your game can be a puzzle game or any other type of game.

What you submit must be fully written in Python by one or more members of your team.  It must use the Pygame module and it must not contain any libraries that aren’t part of Pygame or the Python standard library.  

In addition you:

• Must use at least 10 different Surface objects.
  • Only objects which are blitted and visible in the Display Surface count
  • The Display’s Surface (retrieved using set_mode()) counts as a Surface object
• It must access at least 5 different files, for either reading or writing.
  • Opening a file isn’t enough: Files being read must change the state of the game; files being written to must have their content be based on the state of the game.
  • Files containing code or similar (e.g: DLLs) do not count towards this requirement
• It must play at least 2 different sounds.
  • If the sounds come from files on disk, they also count towards the requirement.
• It must take inputs from either the keyboard, mouse, or a controller.
• It must feature some sort of movement (i.e.: surfaces moving across other surfaces)
  • In general, Surface A is said to be moving across Surface B if:
    • Surface A is blitted onto Surface B at different locations between frames
    • There is overlap in the area of where Surface A was previously blitted and where it will be blitted next
  • Consult your professor if you are unsure if something constitutes movement
• The user must be able to quit the game without pressing the X button at the top right or stopping the project that runs the game.
• There must be a way for the game to “end”.
  • If the game is some sort of puzzle, the puzzle must be solvable and the game must acknowledge that the puzzle has been solved.
  • If the game has win and lose conditions, these must be implemented.
  • Either of the above must close the game or allow the user to restart it.
• Game instructions must be present within the game using correct English.
• Game must not crash or stall.
  • Calling pygame.time.delay() or pygame.time.wait() will usually cause the game to stall and should be avoided.
• Game must show no obvious flaws, such as dropped inputs or rogue Surfaces.

• You must submit a video presentation of your video game.
  • You should submit a link to the video on YouTube.  If you cannot upload it to YouTube, you can submit the entire video on D2L, however, note that it’s easier to have one team member upload it to YouTube.
  • You do not have to create PowerPoint slides for the presentation.  However, you MUST demo the game live in the video.
  • All contributing members of the group must:
    • Be visible in the video (cameras on) in a well-lit room.
    • Introduce themselves and say what they did for the project.
    • Speak clearly.
  • The video must be less than 10 minutes in duration.
  • In the video, you must:
    • Explain and demonstrate the rules/gameplay.
    • Explain the objective of the game.
    • Explain how input works, specifically what each key/button does, then demo each control/button at least once.
    • Play the game sufficiently so we can see how it works.
    • If your game has several levels, you just need to beat one.
      • If your game normally takes a while to finish, you can change some variables around to beat it faster.
      • If you make changes to your code, show us where and what you are doing.
    • Point out all of the game requirements.  For example, show the 10 surfaces, explain how you utilize the 5 files, mention and play the 2 sounds, etc.
      • Let us know where the artwork and music came from.  Did you design it from scratch?  Did you use something from the internet or did you have AI generate it?
    • Show how to win the game and what happens when you do.
    • Show how to lose the game and what happens when you do.
    • Show how the user exits the game.
    • Each member must explain their contribution to the game. 
    • You must talk about the challenges you encountered while working on the game.  For example, which part of the game was the hardest to write and how did you overcome it?
    • Talk about what you would like to have implemented if given more time.
  • Remember, the presentation is part of your grade.  Don’t leave it to the last minute and try to throw something together or you’ll score poorly.

While you are welcome to make the video any way you like that meets the requirements, here is a suggested method to get you started:

• Schedule a Microsoft Teams meeting at a time when all group members are available.
  • When each person joins, be sure they connect from their KSU email account.  Their name should be set so it shows correctly in Teams.
  • Ensure each person has a working webcam and microphone.
  • Hit the “Start Recording” option to record the meeting.
  • Download the resulting meetup video and submit it.
• Ideally, do a test call first to check that everyone’s camera/mic are working and everyone is visible and audible.
• Have one student share their screen and demo the game. 
  • While they are demoing the game, all team members should take turns speaking, explaining how the game works and what their contributions were.
  • If it makes sense, during the video different people can screen share at different times.  Be sure to practice this ahead of time.
• Once you have the recording, upload it to YouTube and submit the link to the video as part of your submission on D2L.

• You must submit your game in the Assignments drop box titled “Project”, which you can find on D2L.
  • Emailed submissions will not be accepted.
• Only one group member needs to submit for the entire group.
  • If more than one group member submits, only the latest submission will be graded.
  • See “Group participation” for what happens if a group splinters into smaller groups.
• For the game, all necessary files must be put inside of a zip file. If your game is expecting a file to be inside a particular folder, that folder must be present in the zip file.
  • Your professor should be able to create an empty Pycharm project, install Pygame, unzip your submission into the project, press play, and your game should work.
  • Do not submit any files which your game doesn’t require (e.g. Virtual environment files, gitignore, POM files etc)
• For the presentation, submit a text file outside the zip file with a link to the YouTube video of your presentation.  If you cannot upload it to YouTube, then submit the video file directly in D2L (this is strongly discouraged, as it’s more difficult).

• Your grade will be based on:
  • Meeting all of the game requirements outlined above.
  • The quality and completeness of the game you created.
  • Meeting all of the requirements of the video presentation.
  • The quality and completeness of the video presentation.
  • Professor’s Discretion: Reserved to the professor and awarded at their discretion.
• In general, games and presentations with less effort will get less points.  For example, if a team member’s only contribution was to make the artwork and they simply downloaded stock images from the internet, they will get less points than someone who created their own original images.
• Likewise any team that implements an online demo that is fully coded online, or uses an existing game and only makes minor changes will get a bad grade, and possibly an academic misconduct charge

Your grade will be broken down as follows:

 

At the start of the semester, you have each been assigned to a group.  You can see your group in D2L by clicking on “Groups” near the top of the page.  

 

It is not possible to change groups.  We understand that you’d prefer to work with friends, but part of this project is learning to work with others.  It is often the case that some members of the group will not contribute equally.  We have measures in place (see grading) to give lower scores to team members who did not contribute.  However, even if some members of your team are not contributing, the remaining members will still need to complete the project.  We will take the number of active participants into account when we grade your project.

At the end of the semester, a quiz named “Peer Feedback” will open under “Quizzes” where you’ll be able to rate how much your teammates participated in the project. You’ll give them a grade between 0 (didn’t participate) and 5 (participated fully) and they will do the same to you. Your professor will then add up the grade given by your teammates and apply it to your “Group Participation” grade. There can be 2 types of groups:

Cohesive group:

• Applies when all team members are participating towards a single game.
• If a group has less than five members, non-existing members rate their teammates “5”.
• If a group member abandons the course or is otherwise non-responsive or non-participating, they rate their teammates “5”.
• You can only rate your teammates: rating yourself does nothing and will be ignored.

Non-cohesive group:

• Applies when different team members are working on and submitting different games.
• If a group has less than five members, non-existent members rate their teammates “0”.
• You will only be able to rate teammates who worked with you.
• You can only rate your teammates: Rating yourself does nothing and will be ignored.
• Inform the professor that this is the case as soon as possible.

As an example of a non-cohesive group, suppose that you are in a group with Alice, Bob, Charlie, and David. David never showed up to class, so he abandoned the course. You and Alice want to make a game called “Fruit Blasters,” but Bob and Charlie want to make “Bomb Slicers” (all fictional titles). You are unable to agree, so you inform the professor that you and Alice will be working on one game while Bob and Charlie will be working on another.

Given that you are all in the same group and are supposed to be working together, the maximum number of points you can get for “Group Participation” is 5 out of 20:

• Alice can rate you between “0” and “5.”
• Bob and Charlie cannot rate you, as they have split off from you; your group is non-cohesive.
• David will not give you his automatic 5 points because your group is non-cohesive.

While disagreements may arise between you and other team members, you should always strive to work together.

At the end of the semester, each instructor will pick the best game from each lecture section.  These winners will go through to the Game Expo which will happen around the second week of the following semester (Spring/Fall).  

During the Game Expo, faculty, staff, and students will come by and see the games, then vote for their favorite.  

The winner will receive prizes.

Any team that submits code that they did not personally write will receive a 0 on the project and may be submitted to SCAI for investigation.  This includes submitting any code written by AI, copying code from any online source, or submitting code from any other source.  Submitting a previous project is also considered cheating.  If anyone in the group suspects others in the group of cheating, let the instructor know as soon as possible.

If you have an SDS accommodation which affects the project, please bring it to your instructor’s attention immediately.

Working in a group is challenging.  Different people will have different ideas on what they want to create, various abilities, and different levels of engagement.  However, this is a real world skill you’ll need to master, because nobody codes alone.  It’s always done in groups.  Here are some tips which might help:

1. Reach out to your group members immediately and try to get together in person.  Suggest that everyone meet before/after the lecture one day since everyone will be there anyway.  If that doesn’t work, select a row of seats in lecture and have everyone sit together.
2. Don’t spend weeks deciding what you are going to do.  Try to ensure you have decided on exactly what game you are creating and what features it will implement within the first couple of days.  That way, people can start making progress.
3. Don’t be too ambitious.  You are not going to write Call of Duty in three weeks.  Ensure that what you pick is something you can REALISTICALLY produce in the time allotted.  Remember, if you pick something too easy, you can always add new features to it with any remaining time.
4. Somebody needs to be a leader in the group.  If someone volunteers to do that, great, otherwise pick someone (e.g first person named within the group list in D2L, or perhaps the person with the first alphabetical name).
   1. The leader should be in charge of organizing meetings, ensuring everyone knows what they are responsible for, and checking in to ensure people are making progress.
   2. The leader needs to ensure that everyone understands and agrees to what the team is going to create.
   3. The leader can also break ties if there are disagreements on which way to go.
5. Identify each person’s strengths. 
   1. If someone in the group is an artist, let them create the artwork/music. 
   2. Have the strongest coder lead the coding effort.  Note, this doesn’t mean that only the strongest coder should code.  This person should divide up the coding effort.
   3. Have the person with the best eye for detail be the tester/QA person.
   4. Someone with good organizational skills can be in charge of the presentation, telling everyone when to speak and coming up with any material that you’ll use in the presentation.
6. Meet often and look for measurable results at each meeting.  Don’t just meet and say “Yeah, we are all doing great.”  Have each person show what they’ve done in order to ensure everyone is making progress.
7. Remember, this is a group project.  Everyone can’t get their own way in a group.  You have to agree on a direction.  This means everyone needs to be flexible and work with the others in the group to produce the best game possible.  Sometimes, deals will need to be struck e.g. “I’d prefer to make Tetris.  Since the rest of the group wants to make a puzzle game, how about we make the puzzle game, but I make the focus of the 3rd level a best-fit puzzle, similar to Tetris?”
8. It’s not unheard of to have team members who never reply.  This is unfortunate.  Perhaps they’ve decided to drop the course, give up on the course, or have fallen behind due to sickness.  Either way, the group must go on, so proceed to divide the work without that team member.  If the team member returns later, find a way that they can contribute.
   1. Remember, we’ll take into account how many people you have when we grade.  If there is a team with only one person working and they still produce a working game, they’ll earn more points than a team of five people who submit an extremely basic game which shows low effort.
   2. This also applies to team members who agree to do things but don’t follow through.  This is why you should meet often and ask to see incremental results at each meeting.  If something is assigned to a team member, but the task isn’t getting done, then the task needs to be reassigned.
9. If additional help/guidance on group dynamics is needed, ask your instructor for specific help.

• Welcome to FYE
• Module 1 Part 1 - Algorithms and Abstraction
• Module 1 Part 2 - Skeletons and I/O
• Module 2 - Part 1 - Selection
• Module 2 - Part 2- Repetition
• Module 3 - Methods
• Module 4 - Part 1 - Intro to PyGame
• Module 4 - Part 2 - PyGame Surfaces
• Module 4 - Part 3 - Rectangles and Movement
• Module 4 - Part 4 - Collisions
• Module 4 - Part 5 - Events
• Module 4 - Part 6 - Multimedia
• Module 4 - Part 7 - File IO
• Module 5 - Sequence Types
• Module 6 - Object Oriented Programming
• Module 7 - Python Review

• Python Exercises with Solutions

• Think Python 2nd Edition
• Python Game Programming
• Python Quick Tour
• Dive into Python
• Sweigart Making Games
• Programming Fundmentals
• Pro GIT