
Introduction to DES315 Technical Design Methods Week 1 Projects
Explore the experimental course approach focusing on developing with a prototyping mindset and using GitHub for projects in DES315 Technical Design Methods. Get insights on syllabus, GitHub handles, and course expectations.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
DES315 Technical Design Methods Week 1: Intro to the course and projects. Developing with a Prototyping Mindset: questions, risks, speed testing / failing.
Before we begin: Syllabus Let s make sure everyone sees the syllabus : Check your email for the link to the course website: www.Madwomb.com/DigiPen. Note the weekly breakdown, and expected materials. Download the syllabus (upper right corner) Please review the syllabus while I take attendance.
Before we begin: GitHub handles Let s make sure that I am getting everyone on the first project GitHub: Open the class Whiteboard (Google Doc, posted in Teams) Please enter your full name, email, and your GitHub handle, which you can get by signing up at www.GitHub.com. If you are new to GitHub, we will primarily use GitHub Desktop in this course. It is a reliable and straightforward tool, if somewhat blunt. Please download and install it before our next meeting (like, right now!): https://desktop.github.com/ Here is our GitHub best practices page, I will review this when we start using GitHub next week: www.madwomb.com/Github If anyone here is highly experienced in GitHub using UnGit or GitKraken, please identify yourself in the whiteboard, as we may call on you in emergencies this term (we had just 2 last year not bad!)
Welcome to the course experiment The first thing I want to say is this entire class is highly experimental. We are trying some wacky things here that I have never attempted with a class of students, in the 20 years I have been teaching college game design and animation. This includes having all of you in the same Github repo for 2 of the 3 projects, to experience contributing features to an ecosystem of other designs. If something in this course does not work, we will look to change it. If there is something you are hungry to explore that fits the purview of this course but does not seem a good fit for any of the projects, please come talk to me out of class, and we will discuss options for you to explore that idea.
Welcome to the Whale Dolphin Because you are all-second semester Juniors, I understand you are taking your major team production course with Matthew Picioccio at the same time. That is your Whale course, and we want it to be your focus. This class is intended to be a Dolphin by comparison; we want to keep a tight leash on project scope for this class, and there is no required peer work for homeworks. I have also tried to keep homework light weeks 5 and 9 for your big Whale milestones, and your final projects will be handed in the final week of classes, to have this class out of the way as you complete your final games.
Course Readings There will not be a lot of required reading in this course (aside from researching tutorials to help you make your projects). There will be at most 4 readings assigned, and they are critical to read on time: Due week #1, Friday: Chapter 7 of Art of Game Design by Jesse Schell (pages 75-95, on Iteration) Due week #7: Chapter 1 of Game Feel by Steve Swink (the introduction and pages 1- 33, which outline the concept) Due week #10: Chapter TBA of Game Balance by Ian Schreiber and Brenda Romero
Course Projects (1/3) There are three projects for this course, each to create a game feature/s for larger, shared projects. They are intended to offer opportunities to explore prototyping methodology in four areas: Level Design and Player Affordance Player Feedback and Game Feel Multiplayer Ability Balance NPC Behavior
Course Projects (2/3) All projects are in Unity. Projects 1 and 3 will be on shared GitHub repositories: all 40+ students on one repo, creating different features for the same game. This will be nutty; there are big risks involved which we will seek to mitigate with good back-up practices and clear work parameters, but it will also be up to you to follow those parameters and work carefully and considerately of your fellow developers.
Course Projects (3/3) Project 1 is a 2D top-down, single player exploration/combat/puzzle game, where you will each design a new Dungeon feature and design and implement a space to test that feature. Project 2 is to take basic 2-player Pong and add Game Feel enhancement features that create significantly (and positively) impact the player feedback experience. Project 3 is a two-player Robot Battle game like a high school Bot Battle challenges. You will create a robot to play in the game. The goal is not to create the most devastating bot: it is to create a bot that is strategically unbalanced within a specific set of parameters, like the stats on a D&D sheet, to give rise to interesting interactions in the ecosystem of each others Bots. You are encouraged to consider an independent component of this bot: projectiles, minibots, defense or attack systems that can run independently as NPCs once deployed
DEFINITIONS: What do we mean by a Game Feature? Go to the class whiteboard and respond to Question #1: What is an example of a specific Game Feature? Consider Positive and Negative Feedback Loops: A Positive Game Loop encourages current momentum: Those in the lead get more ability to win, those behind have less opportunities to win. A Negative Game Loop opposes/balances the current momentum: Those in the lead are hampered with greater difficulty, those in the back given more opportunities to catch up. So for this example: (Jason): Turret that shoots waterballoons to make the player soggy / slow Does it promote a Positive or Negative Feedback Loop?
DEFINITIONS: What do we mean by a Prototype in game dev? Go to the class whiteboard and respond to Question #2:
DEFINITIONS: Feature Prototyping A Feature can be anything that interactively impacts gameplay and player choice. It is usually a combination of design, coding, visual, audio, and UI (or other feedback) elements; essentially, game designing microcosm. Prototyping is a process of defining and implementing testable loops to explore the feasibility of a feature as quickly as possible. A Good Prototype (from the Schell reading, pp86-90): 1. Answers a Question ( Close a Loop ) 2. De-emphasizes Quality (within reason: still needs to communicate) 3. Avoids creator attachment 4-5. Is broken into smaller, rough prototypes: created in order of priority of user experience and when possible in parallel. 6. Is non-digital where possible, to close loops faster 7. When digital, uses a fast loop game engine (Unity does this well, encouraging modular design and editable scripts and properties during runtime) 8. Is built on a fun toy first (more important for full game prototyping, rather than feature prototyping).
Towards a Prototyping Mindset (1/4) Through these projects we want you to develop a Prototyping Mindset: ways of approaching a problem that are efficient and effective, particularly in a collaborative setting such as a game studio. 1. Identify EXISTING FEATURES in your area of interest 2. Ask QUESTIONS about what could enhance player choice and feedback in that area. Work to make those questions more specific. 3. List possible feature SOLUTIONS to those questions 4. Identify RISKS for these solutions. 5. Close LOOPS: Execute the SPEEDIEST play-testable versions in order to TEST as soon as possible, looking for PAPER PROTOTYPING opportunities, to evaluate whether it is worth putting more time into this idea.
Towards a Prototyping Mindset (2/4) A high priorities of this process is to test feature ideas as quickly as possible, to be able to discard them if they do work ( Failing as fast as possible ). We want to look for non-digital ways to test these ideas quickly, that can also start answering some questions about how they will be implemented. Let s watch this video by Colleen Macklin and John Sharp to get some ideas (and take a break) https://www.youtube.com/watch?v=ZzQY1OfDc-I
Towards a Prototyping Mindset (3/4) This video by Colleen Macklin and John Sharp offers ideas for prototyping game concepts: https://www.youtube.com/watch?v=ZzQY1OfDc-I An important thing to remember is that each non-digital prototype only needs to test a part of the concept you want to implement, not the whole. What was the first Prototype they made in this video? What were they NOT trying to test with that prototype? What could they test for with that first prototype? What was the second sequence of prototypes? What were they NOT trying to test? What could they test for with that second sequence prototype?
Towards a Prototyping Mindset (4/4) Prototypes are any experience you create to test an aspect of the feature you want to implement. We paper prototype to save time massive amounts of it. Even if you are the fastest, most efficient programmer in the world, it will always be more expensive to implement a major game feature in the engine than to explore Paper. An even earlier prototype than something tangibly playable/manipulate-able is a conversation: Sharing you idea with someone else, and observing their reactions. Do all the ways you are sharing your idea make sense to them? When do they seem to get excited? The real-world table-tennis experiments described in the video mostly applies to sport or dance/rhythm games. For games that involve a sequence of interactions with Ai, particularly at random, a card game prototype could help explore player reactions. For a feature that deals with making choices in a designed space, mocking up a board- game environment could make sense.
Towards a Prototyping Mindset: Examples Stone Librande (Designer for EA/Maxis, Riot games) paper prototypes for Spore:
Towards a Prototyping Mindset: Examples Clockwork Demon: Testing if blending exploration-based storytelling with emergent, sandbox mechanics was as compelling as we thought.
Towards a Prototyping Mindset: Examples One of my favorite examples of student prototype was for a team game in my Intro to Game Design course. One team was developing a game where the player acted as the immune system for a very diseased penguin. One of the core QUESTIONS they decided to answer early on was how the illnesses and antibodies would be distributed around the body, the core loop of player activity in the game. They asked: what if the distribution of virus and white blood cells was randomized?
Towards a Prototyping Mindset: Examples To test the engagement of this idea they developed a pachinko board the game where we drop a ping pong ball or a coin into a tall board of pegs and watch it randomly make its way down. The boxes at the bottom represented organs. They first dropped in the virus balls, and then the player dropped in the antibody balls, and if the ratio of the two in a box was sufficient than that organ would be cleared of virus, gaining points. Any organ with only virus was said to die, and the player learned what type of organ failure killed their penguin. The feedback they got was this randomness created some interesting momentary tension, but ultimately players wanted more agency over their success or failure, and the team decided to give the player a lot more control in the following digital implementation.
HOMEWORK BRAINSTORMING Please download and open the Game Feature Example Doc instructions for the course website, to see what is due for your first assignment. Let s get started by answering Question #3 on the whiteboard: a) What is a game you have enjoyed and played substantially, that you could imagine modifying with a new feature? Choose an interesting level / part of the game to enhance. b)Brainstorm potential questions about player choice in this area of the game. What can the player do? What are the goals? What are the pressures to achieve those goals? What if ? For example: What if the first space in Portal had a time-pressure feature, to encourage egress? c) Consider potential solutions to these goals: (Jason): a) Portal, first room b) How to create time pressure for the player to leave the glass box?
WEEK 1 To-do List: 1. Read the chapter on Iteration (pp75-95) in Jesse Schell s Art of Game Design and submit a question related to the reading before our Friday meeting. 2. Submit your first Game Feature Example DOC to Moodle by Friday 9am, including screenshots. 3. Want some practice in Unity? Do this tutorial (optional): http://madwomb.com/tutorials/GameDesign_UnityScripting.html HAVE A GREAT WEEK! JasonWiserArt@gmail.com