Design Project #3: Video Games

Transcription

1 PROF. MCGUIRE Design Project #3: Video Games For your third design project, you will work in a self-selected team of 2-5 students for two weeks to design, implement, document, analyze, and present a game playable to completion by 1-3 players in no more than 25 minutes. The development of your game must contain a programming element. It can be a classic video game, interactive fiction, a hybrid that has physical elements as well as a computer component, or a board game in which you programmed a significant amount to produce or analyze the design. You ve only been programming for about a week in this course, so scale your expectations accordingly. A polished Pac Man or Missile Command game would be a spectacular and challenging project. Although we directly studied how to produce arcade-like games in previous activities, your game may be turn-based, real-time, text-based, audio-based, etc. It must be playable on a CS lab OS X computer and source code must be submitted for evaluation. The TAs and I can provide the most support for codeheart.js games, but you are welcome to use other technologies such as Twine or Java if you wish. Submit your game via the turnin folder. If your game requires physical components, then you must provide two identical sets of those components. I will keep one of them to show future classes and return the other. If your game is a hybrid that is packaged as a mod for an existing board game that I don t own, then you must lend it to me so that I can play your game. If you want to create a mod for a video game, discuss it with me well ahead of time to ensure that the scope is reasonable and I ll be able to evaluate it. Given sufficient notice and a reasonable budget (less than $8 per team member), I can purchase board game components for you. Master Schedule and Deadlines Tue, Mar 3 Brainstorm projects in class Thu, Mar 5 Elevator pitch proposals due in class. Tue, Mar 10 Receive approved proposals. Negotiate groups and projects in class. Thu, Mar 12 Programming activities in class all day. No midterm work this day! Tue, Mar 17 Checkpoint. Demonstrate significant progress during class. The main mechanic should be playable in some form. Thu, Mar 19 Work on midterm in class in the afternoon (Spring Break You re welcome to work on midterm projects during break, but I assume you are not.) Tue, Apr 7 Tue, Apr 7 Wed, Apr 8 Thu, Apr 9 Reading Quiz due at 10 pm (you may want to do the reading during break) Checkpoint. Demonstrate completed game and presentation outline during class Project due at 10pm Presentation due in class Each team member may spend at most 36 hours on the project between 8:30am March 10 and 10:00pm April 8. You do not have to track your time exactly. Please make a good faith effort to keep this project about working smart instead of hard and respecting your other commitments, as well as those of your teammates. 1

2 Details The elevator pitches are 1-paragraph proposals, each submitted on a single sheet of paper. You can submit as many as you wish (including none), and may submit them in groups. I ll review all of these and green-light the ones that I think you can succeed with given the resources available. Anyone can then make a game based on anybody else s approved proposal, and multiple groups can use the same proposal. You will tell the class about your final game in an oral presentation in class. It will have a short, fixed maximum duration that will depend on the number of groups but will be at least eight minutes. This presentation should be formal and academic in nature. Do not attempt to capture the development process or all of the details of the game instead, present a brief overview and then detail one or two elements in depth. For example, how you produced physical pieces, analysis of the core mechanic, or elements of your visual design language. The games, design document, and visual aids for your presentation are due at 10pm on April 8. To save you a trip to the science center late at night, I don t require you to physically submit the work at that time, but ask you under the Honor Code to stop all work on the project at that point. Part of the reason for this deadline is to ensure that you get a good night s sleep before your presentation. The game design document should be at most eight single-sided printed pages using 1.5x line spacing and a 10pt or larger serif font. The page limit excludes the change log, supplemental process information, and bibliography. Start each major bullet-point described below on a new page. Use section titles, equations, pictures, bulleted lists, equations, tables, and other concise forms to present your arguments and ideas. I will be less critical of writing quality than for your critiques, however good writing always enables you to communicate your ideas in the most favorable light. The documentation should leverage the terminology from class and the textbook. Do not include stories of your production, subjective comments, or high-level self-criticism. A good structure for your documentation is: Cover page o Team name o Game name o Representative picture o Team members names, with addresses and areas of primary responsibility o Art/CS107 and the due date, April 1, 2015 Proposal, in approximately the Academic Worksheet format found at I recommend incrementally completing this throughout the project as you iterate on design to document your vision; writing it too early is hard and unnatural, and writing it too late forgoes much of the benefit of focusing your thinking Schedule o Entries include deadline times, objective deliverables, and team member names o Example: Wed March 11, 5:00pm. Marty: Original art for five characters as 512x256 PNG images o When creating the schedule, work backward from what you need at the end and let that recursively drive your earlier deliverables. This process will probably lead you to reduce scope and expectations. 2

3 o Optionally include text or a table outlining the contributions of each team member. While a majority of the grade for the project will be based on the final product, in cases where quality is uneven across aspects I may assign different grades to different students and will use this information to guide that process. Analysis o The strengths of your design o Lingering flaws of your design, how you tried to address them, and why they are hard to fix o How did you measure the result of playtests, qualitatively and quantitatively o The most significant changes to your design, why you made them, and how you evaluated them o How you balanced the game, with objective analysis. Take the most critical mechanic and explore it in detail A change log of major changes in historical order from oldest to newest, structured as a simple bulleted list with short notes explaining motivation. You may wish to intersperse playtesting summary paragraphs. Examples: o o Supplemental documentation of your process. This can be explanations of how you approached problems, snapshots of your team working on physical production or during playtests, and design notes and equations. Give evidence of a principled and academic development process. I only see your design document, not what happened to bring the game to life. This section is a good way for you to reveal work that otherwise is only known to your team Supplemental collections of concept art and reference art. Include URLs where possible, but this section does not require citations. Acknowledgements and bibliography Evaluation I will evaluate your work by playing the game with the TAs and reading your design document. I am looking for evidence of a principled and academic development process based on topics explicitly studied in class and the readings, plus a level of design artistry that aspires to the games we ve studied. As on your previous projects and critiques, different students and groups will manifest these elements in different ways. The ideal project is both a self-evidently good game with documentation demonstrating that you know why it is good and that the quality arose from an intentional process instead of luck. Use the technical vocabulary (correctly!) wherever appropriate, reference previous games and seek out feedback during development from your peers, the TAs, and me. 3

4 To submit your work using the Turnin folder on OS X from a computer in TCL216: 1. Put your project in a folder named midterm-gamename -00. The 00 is the revision number and you can increase it if you need to submit again later. 2. Structure your folder so that it contains a file named gamename-gdd.pdf that is your design document and one or more other folders that contain the computer components of your game. If running your game is more complicated than clicking on play.html in a single folder, then make sure that you leave clear instructions for launching it in a file named README.TXT. 3. From the Finder menu bar, select the "Go" menu 4. Select "Connect to Server" from the Go menu 5. Type "afp://fuji.cs.williams.edu/" in the Server Address text box. 6. (Optionally push the "+" button to save this choice) 7. Push "Ok" 8. In the new dialog, select "Guest" and press "Ok". If you log in as yourself, then I will not be able to access and grade your files. 9. Select the "Courses" volume and press "Ok". 10. In Finder, open the cs107/turnin folder. 11. Copy your project folder into Turnin. You will not be able to see it once dropped. The original should remain on your own CS account (don't delete it--you'll want to look back at your work later!) 12. If you need to update your solution, increment the revision number and re-upload. 4

5 As advice for how to scope and schedule your work, I recommend the following development process: 1. Day 1 a. Form a team and choose a project manager b. Name the team (as a team building activity as well as practicality) c. Discuss your ideas as a group d. Discuss your ideas with me and the TAs; we ll suggest related games that you should look into as well as approaches e. Play some related games, ideally together (as background research and team building) f. Collect concept and reference art 2. Day 2 a. Create a minimal playable prototype without attempting to document your design or organize your team. Even though you are making a video game, try to make this a board game prototype of the key mechanic so that you can playtest before implementing the code b. Choose areas of responsibility (e.g., documentation, visual art, audio, game writing, mechanics, analysis, programming, physical production) and draft a schedule 3. Rest of the first week a. Finish the schedule (but keep updating it throughout the process) b. Iteratively and incrementally update your design document. Keep the documentation minimal but accumulate as much process information as you can. c. Playtest and get feedback at regular intervals 4. Second week a. Test with fresh players and no designer intervention, in the way that your game would naturally be encountered: a closed box and written rules for board game components, or starting from the title screen for a video game. I highly recommend on-screen control guides or a printed one-page guide if your controls are at all complex. b. Polish the implementation. Make title, control, and end-game screens, add audio and final graphics. c. Produce the final game (and box if you have physical components) 5. Last few days (after Spring Break) a. Prepare your presentation b. Rehearse your presentation c. Rehearse your presentation again d. Rehearse your presentation in TCL206, using the podium computer or your own laptop if you have slides or images you wish to show. Make sure that: i. You can access the files you need from that location ii. You have any computer adapters needed to connect to the projector iii. Your visual aids look good on the projector, given its resolution and brightness e. Submit your game f. Give your presentation! 5