Q11: Project Proposal

Table of Contents


  • Start working with other guild members to develop a final guild project.
  • Develop a plan for the final guild project.
  • Develop the core concept of the project.
  • Identify the subsystems to be completed by each guild member.

Academic Honesty

Read the Scholastic Honesty Policy and Assignment Integrity policies of the syllabus. Here are some clarifications for this particular assignment:

  • You are expected to work with your guild to develop a project proposal.
  • You may get help from people other than your guild members but must attribute ideas.

Project Proposal Specifications

Start by reading the entire Course Project to understand what you will be working on over the coming weeks.

Guild Requirements

All guild members must work together and are jointly responsible for completing the following requirements.

  1. Develop a project concept that is either a game or interactive simulation.
  2. Write a proposal document with a heading for each section shown below in bold.

    Here is an example Project Proposal.

  3. As a heading near the top of the document, state the guild name. For example:
    CS-12GP Project Proposal
    Guild: Phoenix
  4. Guild members: state the name of the guild and list the guild members (first and last name) involved in the project. After their name, include their short subsystem(s) name. For example:
    1. Phoenix Guild Members
    Cody Coder -- Enemies
    Dan Developer -- Scoring, status, instructions
    Ed Parrish -- Worlds and Platforms
    Emma Engineer -- Projectiles, Powerups
    Paula Programmer -- Main Characters
    Leroy Jenkins -- N/A

    Contact guild members you have not seen or heard from recently and ask if they are planning to contribute to the project. If the person does not contribute, then list N/A (not available) after their name like: Leroy Jenkins -- N/A.

  5. Core concept: clearly describe the core concept, which includes the core mechanics, in words. For example:
    II. Core Concept
    Our guild project is a platform game like Super Mario Brothers. However, the main character is Jungle Jane. Jane's goal is to save George from the evil creatures who have abducted him while he was napping. Jane's core mechanics are walking, runing and jumping on various jungle platforms and creatures. Jane will need to use her skills to outwit the evil creatures and free Jungle George.

    The core mechanic is the system of play in the game and are the main actions that the player performs repeatedly. In the above description, the core mechanics are walking, running and jumping on platforms and creatures.

  6. Game subsystems: organize the game coding into subsystems with planned objects and their classes. A subsystem is a self-contained system within a larger system. In the project, a subsystem is group of software classes, not just methods within a class. No one can be responsible for only art or audio assets and everyone is responsible for coding the use of collisions, animation, images and sound in their subsystem.

    It is also important that each subsystem is as self-contained as practical so that the failure of one subsystem does not cause the entire project to fail. However, some subsystems will always be critical to project success so choose who does what wisely.

    Here is the heading for this section:
    III. Game subsystems
    Here are some possible subsystems, all of which contain multiple classes:
    Worlds and platforms
    Main characters
    Enemies and NPCs
    Weapons, projectiles and splats
    Powerups and puzzles
    Instructions, messages and scoring

    Assign a guild member as the primary owner of each subsystem and its classes. All subsystems and classes must be named and have a single person as the owner.

    The guild is responsible for ensuring that each guild member has a subsystem that is allocated enough scope for the classes to code in their subsystem. The guild member is then responsible to contribute the information for their subsystem(s) to their section of the overall document.

    If the subsystems are largely identical, make certain that each subsystem has some significantly unique aspect so that the guild member can express originality. The guild member is then responsible for clearly describing the significantly unique aspects of their subsystem (see next section).

    If the project is derivative, then indicate which subsystems and classes are new to meet originality requirements.

  7. The proposal must be typewritten, not handwritten, with good grammar and spelling. Review each other's contributions for content and correct grammar, spelling and semantics as necessary for a well-written document. Make certain that class names and descriptions are included in the content.

Note that the project proposal document must be submitted to Canvas as a .txt, .rtf, .doc or .docx file and one guild member must turn in a paper copy to the instructor.

Solo Requirements

Each guild member is individually responsible to complete the following part of the project plan for their assigned subsystem.

  1. Subsystem label: develop a short label (one to four words) for your chosen subsystem and include the label with your name attached like:
    Main Characters: Paula Programmer

    This means you are the sole owner of this subsystem of complete software classes. Under your unique label, include the following information with the subheadings shown below in bold.

  2. Subsystem description: list at least three class names that you will write with a short description of how the objects provide a significant role in the project and will have at least 150 lines of code combined when written like:
    Description: The main characters who walk, run and jump and throw projectiles.
    Classes include:
    1. Sprite: superclass of game characters that can run and jump
    2. Jane: the user-controlled character
    3. George: the NPC that must be rescued.
  3. Object collisions: describe specific planned collisions for objects of your subsystem for which you will write the code. for example:
    Object Collisions:
    -Jane walks, runs and jumps on platforms.
    -Jumping on a creature kills it.
    -Jane dies when creatures run into her.

    The proposal must describe at least two collisions, where you, the subsystem owner, will write the code, and the purpose of those collisions. Thus each guild member is responsible for defining a set of collisions interacting with their subsystem for which they will write code. If you cannot imagine and describe these collisions then your subsystem is inadequate and must be expanded.

  4. Planned animations: identify and describe at least two animations planned for your subsystem, for which you will implement the animation code. For example:
    Planned animations:
    -Jane walking, both left and right.
    -Jane running, both left and right.
    -Jane jumping, both left and right.
    -Jane throwing projectiles, both left and right
    -George walking back and forth inside his prison.
  5. Planned images and sources: list at least three specific images for your subsystem, the sources of the image and a short description of the how the image will be used in your subsystem. For example:
    Planned images:
    -Jane standing: standing still when not moving.
    -Jane moving: a series of images when Jane moves either left or right.
    -Jane throwing: a series of images when Jane moves either left or right.
    -George pacing: walking back and forth inside his prison.
    -Image sources: Charas, online RPG character generator

    Note that an image name is NOT enough of a description.

  6. Planned sounds: list at least two specific sounds, what will generate the sounds and a short description of the how the sound will be used in your subsystem. For example:
    Planned sounds:
    -Jane grunting when she hits a wall.
    -Jane success sound (yodel?) when she outwits or defeats an enemy.

    Note that you will be responsible for writing the code that controls the playing of these sounds.

  7. Incorporate your subsystem information into the proposal document for the guild to review as described in the Guild Specifications.

    For an example, see the Project Proposal.

Grading Criteria

The instructor will evaluate your quest using the Project Proposal rubric in Canvas.

Maximum Score: 20


Follow these instructions carefully and exactly to turn in your quest (assignment) to Canvas and maximize your XP:

  1. Choose one person in your guild as the "submitter" who will submit the final project proposal from which everyone is graded.
  2. The submitter ensures that all the parts are combined correctly and submits the project into the Q11 quest slot of Canvas.

    Do NOT submit solo versions of the project as the last submission by anyone in the guild will be counted as the final version for the entire guild.

  3. In addition, one person in the guild brings a single paper copy of the guild proposal to class to turn in for grading comments.

Do not put any spaces or special characters like #, : or $ in zip file or folder names if used.

If the submitter makes a mistake, the submitter can resubmit up to the deadline but must resubmit all assignment files.

Last Updated: November 05 2018 @15:59:20