Q11: Project Proposal

Table of Contents


Objectives

  • 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 and followed by a fuller description, like:
    Main Characters: Paula Programmer
    Description: The main characters who walk, run and jump and throw projectiles.
    

    This means you are the sole owner of this subsystem and will write most all of the code for the software classes. Each susbsytem label must be unique though some subsystem concepts may be the same. For example, two guild members may develop enemies, but the enemies must be different and their code must be original and not just be copied with different images attached.

    Under your subsystem label and description, include the following information with the subheadings shown below in bold.

  2. Class names and descriptions: list at least three class names that you will write for your subsystem with a short description of the objects significant role in the subsystem or project. Remember that your classes must have at least 150 lines of code combined (excluding comments and braces) when written. For example:
    Classes names and descriptions:
    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, the event triggering the collision, and planned actions as result. For example:
    Object Collisions:
    -Jane-Platform: Jane walks, runs and jumps on platforms; also bumps into platforms which causes her to move back.
    -Jane-Creature: Jumping on a creature kills it.
    -Jane-Creature: Jane dies when creatures run into her.
    

    The listing must include both actors in the collision and a description (with a noun and verb at a minimum) of the response of your actor as a result of the collision. A button press or mouse click is not a collision. As the subsystem owner, you are responsible for writing all the collision code for your objects.

  4. Planned animations: identify and describe at least two animations planned for your subsystem, the object name implementing the animation, and a description of the animation (3+ words). 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. As the subsystem owner, you are responsible for writing all the animation code in the classes for your subsystem objects.

  6. Planned images and sources: list at least three specific images for your subsystem, the object that will display the image, a short description of the image (3+ words), and where you will get the images. 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 throws a projectile left or right.
    -George pacing: walking back and forth inside his prison.
    -Image sources: Charas, online RPG character generator
    http://charas-project.net/
    

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

  7. Planned sounds: list at least two specific sounds, the object generating the sound and the triggering event. For example:
    Planned sounds:
    -Jane grunting when she hits a wall.
    -Jane success sound (yodel?) when she outwits or defeats an enemy.
    

    As the subsystem owner, you are responsible for writing the code that controls the playing of these sounds.

  8. 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

Deliverables

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 20 2018 @00:12:16