Unity Collaborative Development - Classmate Prefabs and Level Design Considerations

DES315 Technical Design Methods Week 4: Unity Collaborative Development. Classmate Prefabs and .TXT files Level Design considerations and integrating a classmate prefab into your designs.

Week 4 Plan: Classmate Prefab Selection: Considerations for choosing a classmate s prefab to integrate in your level Process for integrating a classmate s prefab, as it is still being improved! Is it OK if no one chooses my feature? Level Design: Designing for Gameplay Mode. Micro Level Design / Macro Level Design Tutorial-izing your level to teach your feature: Signifiers, Affordances, and Feedback Managing your Difficulty Curve Playtesting: Playtesting features / levels in progress Playability Functional Feedback and Suggestions

Considerations for choosing a classmates prefab Level Design considerations: What is the genre / style / core game mode of your level? Is it an action level, and therefore what kinds of prefabs support that mode? Is it a puzzle level, and if so, what kinds of prefabs support that mode? Is it a stealth level (timing)? A shooting level (precision)? Something else? Consider features that COMPLIMENT your feature (like a different puzzle element to go with your puzzle element), vs those that COMPLETE your level, like a particular type of enemy that could offer time-pressure to your puzzle level. How many classmate s features can I use? Please just choose one classmate s feature to integrate into your level. This single feature may include multiple prefabs (like a laser + movable block). We are asking you to choose only one classmate s prefab/s so that you can focus on the Level Design that will showcase just these two, rather than be inclined to throw the kitchen sink in.

Process for integrating a classmates prefab 1. FIND the feature prefab/s in the classmate s Prefab folder. 2. READ the .TXT file left there to explain how to use the feature. 3. DRAG the prefab/s into your Scene, and follow the .TXT instructions. 4. LINK your exit door to your collaborator s level. Please use the classmates prefab as-is: You are welcome to change the local exposed variables to suit your scene, but if you want a new element in the feature, you are expected to ask the creator. There may be exceptional reasons to make local adjustments. Please contact the teacher with questions about this expectations. Creators: You are not obligated to accommodate every request, but please make a reasonable effort to consider them. Please also try to reply in a timely fashion, on the same day. The first reply does not need to be I completed this it can simply be I see your message . Do you feel overwhelmed by requests? Please contact the teacher for help!

Is it OK if no one chooses my feature? YES. There are many reasons your feature might not get chosen by anyone else Your feature might be highly idiosyncratic: something cool in your level, but which your classmates did not imagine for theirs. Your feature may be similar to others that may be a slightly better fit for those particular levels. Your feature may be completed a bit later than another s There is no negative grade-impact to your feature being chosen You still get the experience of working with another s prefab in your level, and communicating with the creator! There IS extra credit for those who are chosen excessively, who make a lot of edits (please keep track of the number of requests you fulfill). The student whose feature is used the most (and whose level therefore has the most scenes linking to it) will get a cookie. This is not a competition; it is compensation for potentially significant extra work. Consider revising your MainMenu button prefab to attract some attention (within reason)

Week 4: review of micro/macro level design How do we incorporate another person s prefab into our scene how can we make them work well together? Show a bunch of examples from previous terms!

Check-in: Homework For this Wednesday: In addition to the reading (if it was not done by today), please have progress to show on your project 1 feature: 1. A working draft of some part of your Feature Prefab. This does not need to be the entire feature for this Wednesday: choose 1-2 elements that will be most important for playtesting. Please only merge your GitHub branch after you are sure the code compiles and runs on your machine, has unique script names, and no local hard coded dependencies. This prefab s name should include your name and a word or two about what it does (humpCap and/or underlines, no spaces). Any scripts should also be named with your name, to prevent accidental conflicts when you merge. Locate the prefab in the student prefabs folder, for your classmates to use in their scenes! 2. A draft of your Showcase Scene, to show off your prefab. Must include at least the Player, Game Hander, and Canvas from the teacher or student samples. You are encouraged to start by duplicating the StudentSample scene, renaming it for your name, and moving it to the Students Scenes folder. Be sure to change your Menu Button Prefab so it directs to your scene! Next week, merge final feature Prefab and Showcase Scene by classtime!

Questions Part 1 What questions do you have about the class projects or anything else we are doing?

Questions Part 2 Let s look at the questions you posted about the first reading: Jesse Schell s Art of Game Design, on Iteration. (Edition 1: pp 75-95, Edition 2: pp 90-113)

Group Meetings You now have 30 minutes to discuss two things: 1. (8 minutes) How much should you trust playtester feedback in making decisions about your game? 2. (20 minutes) Share your feature ideas! What is the concept, and how can it potentially be used on each other s level? Discussion leaders: open your breakout room and facilitate conversation: help everyone to speak, and bring digressions back on topic

I am excited to see your feature progress! (end of second lab)

1 week to complete your Dungeon Feature / Showcase! Due next Wednesday is your completed Scene to showcase your Feature. The Feature Prefab should not be a first draft: it should have gone through multiple playtests and stages of iteration. Your feature should include visual/audio FEEDBACK to make it clear what it does, and how player actions interact with it. This feedback should be tested and revised. The Showcase Scene can start as a duplicate of the provided Student Sample Scene, to include the Player and GameHandler Prefabs and the Tilemap Grid and UI Canvas templates. You are expected to re-fill the Tilemap layers with your own arrangement of walls etc, and you are welcome to add additional UI elements. Most importantly, your Showcase Scene is expected to show off your Feature Prefab, and to meaningfully include at least one Prefab from your classmates. To this end, everyone please go to the class Whiteboard and post a sentence describing your intended Feature Prefab (if you haven t yet).

Unity Collaboration: Hooking up Placeholders Let s get your Showcase Scenes and Prefabs in the project. If you have not already done so, please: 1. Create a placeholder for your Showcase Scene: copy the StudentExample Scene file and rename with your name (humpCap notation, no spaces). 2. Create a placeholder for your Feature: create an Empty GameObject, Reset Position Transforms to 0,0,0, name for your name and the feature name (humpCap notation, no spaces). Drag in a relevant piece of art (or make an GameObject > 2D > Sprite), set position to 0,0,0, and make a child of the EmptyGO. Drag this object into the Project panel Prefabs folder to make it a Prefab. 3. In the Prefabs folder, find your designated MainMenu button object (from the whiteboard ). DoubleClick to open it, and in the Inspector add your scene name to the script slot. For good measure, change the button color to show it has been updated. NOTE: button will not work until Build Settings are updated to include your scene, which must be done in the main Githhub project, NOT a branch! 4. Are you able to Play the project without compile errors? Are all your scripts named uniquely and there are no hard-coded script paths? Then save, save project, and in GitHub Desktop commit and push!

Unity Collaboration Limits/Concerns for Unity Collaboration: Scene conflicts: Scenes cannot be easily merged. If two people work on the same scene at the same time, one will need to discard their changes in order to pull/push in GitHub. Unity creates a TON of extra files: these files are auto-generated and specific to a play session, like all the files in the Library, and will easily create GitHub conflicts. Solutions for good Unity Collaboration: Nested Prefabs! Unique file names (add your name) Avoid scripting hard-coded file locations (that are specific to your local computer directory) Include a good GitIgnore Communication Advanced: Nested Scenes

Unity Collaboration: Solutions: Nested Prefabs Fill a Scene with Prefabs to represent all major interact-able elements, and then adjust those elements from the Prefabs folder, so you can PLAYTEST in the Scene but never again change the Scene directly. No Scene conflicts! A Prefab is created when we drag an object from the Hierarchy into the Project panel (and organizationally place it in a Prefabs folder). This object should ALWAYS be an Empty Game Object, set to transform position 0,0,0. Optionally it can include Art (a 2D Sprite or visible 3D object) parented under it. The Empty GO gets all Scripts/Physics/AudioSource Components and any Tag or Layer ID. The child Art object optionally gets an Animator Component. Both objects will appear blue and have a cube icon. The Hierarchy Object is now an Instance of the master Prefab in the Project panel, and most changes to the Project panel Prefab will then appear in the Hierarchy Object (and its duplicates!). This allows us to change many objects at once. On the other hand, direct changes to the Hierarchy Object will be specific to that object.

Unity Collaboration: Solutions: Nested Prefabs For example, we can create an Empty GO with a child Cube and a simple rotation script on the Empty GO. Drag the empty into the Project panel to make a Prefab. Now, DoubleClick the master Prefab in the Project panel to open it, and we can add Components, like an AudioSource and a collision script to the Empty. At the top of the master Prefab Hierarchy, hit the little arrow to return to the Scene view, and select the Hierarchy Object to see the Components have been added there, as well. If we duplicate the Object in the hierarchy, we can choose the audio clip for each, thus making that parameter unique for each of those copies of the prefab (shows boldfaced). We can also change their names in the Inspector and add additional components without effecting the original prefab (as long as we do not try to change the order of the original Components). If the Master Prefab in the Project panel is ever deleted, the Hierarchy Object will appear red, indicating it is missing the Master. To break the connection between an Object in the Hierarchy and it s Master Prefab, RightClick the Hierarchy Object and choose Unpack Prefab .

Unity Collaboration: Solutions: Unique File Names: When working on multiple GitHub branches it can be easy to create conflicts through identical file names. Good communication can prevent this, and a way to make your files for this course safe is to include your name in the file name. So, if you are working on a new enemy, the script could be named EnemyMove_DianaPrince.cs (if you are Wonder Woman). Your scene and feature prefab should absolutely include your name for this course. Avoid scripting hard-coded file locations: Are you scripting a feature that needs to speak to a j.son file? Make sure you are not directing it to look in a location that is specific to your local computer directory.

Unity Collaboration: Solutions: Good GitIgnore: Make sure your GitIgnore file has no text before the folder paths. The default Unity GitIgnore provided by GitHub adds a + before each. I typically create the default when setting up the GitHib to confirm placement in the folder structure, and then replace it. This has already been set up for our projects this term, but you should know about it. Correct: [Ll]ibrary/ [Tt]emp/ [Oo]bj/ [Bb]uild/ [Bb]uilds/ [Ll]ogs/ [Mm]emoryCaptures/ Incorrect: + [Ll]ibrary/ + [Tt]emp/ + [Oo]bj/ + [Bb]uild/ + [Bb]uilds/ + [Ll]ogs/ + [Mm]emoryCaptures/

Unity Collaboration: Solutions: Communication: Have you chosen Charlotte s Fire-Breathing NPC and David s Temperature State to include in your Scene to showcase your new Ice-Wall feature? Be in communication with them to see when they push new versions and to learn about their evolving plans for their feature! Most project problems can be prevented through regular communication. The stand-up meetings in Scrum are intended to offer these opportunities to catch issues before they become problems.

Unity Collaboration: Solutions Advanced: Nested Scenes with Multi-Scene Editing: While out of scope for this course, it is possible to load a Scene inside of another Scene (more like, parallel to), so a Main Scene contains critical coding interactions and all of the other scenes contain environments for particular areas of the world. In this way, we can avoid merge conflicts and get more work done in parallel. This workflow is explained well in this video: https://youtu.be/KRmqy22z0SM Normal Multi-Scene Editing allows us to view and edit multiple Scenes at once in the Hierarchy (by RightClicking a Scene in the Project panel and choosing Open Scene Additive, and switching which is active by RightClicking scenes in the Hierarchy and setting one active at a time). https://docs.unity3d.com/Manual/MultiSceneEditing.html A simpler version of this idea is to use Prefab groups for areas of a scene: to make all of environment assets into a Prefab, for example, and all of gameplay objects another, so that those elements can be changed in the Prefab group rather than directly in the Scene. This makes use of Nested Prefabs, which have been available since 2018 (https://www.raywenderlich.com/9330-how-to-use-the-new-unity-prefab-workflow). If everyone is making changes on either Object Prefabs (like a particular tree) or a Prefab group (like the arrangement of all trees in the forest), then no one is making changes directly to the Scene that can cause a bigger merge conflict. As noted in this article, a team that decides to institute this practice should use it consistently: either everything in a Scene is in prefab groups, or none are: https://www.gamasutra.com/blogs/LeonArndt/20200513/362875/Using_Unity_pref abs_to_avoid_scene_merge_conflics.php

What Online Resources Can be Used for this Course? This is a tricky question. For most professional studio preproduction Prototyping work, the only law is How fast can I test my idea? In those cases, using whatever resources you can legally grab or reasonably purchase are fare game. The work is no intended to be shown to anyone outside of the studio, and any functions that are greenlit for production will be re-programmed anyway. But this is an academic setting, and we want you to build muscles in solving coding challenges you have not solved before. In general, we want you to find tutorials and use them to write the code yourself, not simply purchase a package on the Unity Asset Store. Exceptions can be made on a case-by-case basis. If your intended Feature has five high-priority elements and three other elements on the wish-list, and using an Asset Package for one of them will enable you to accomplish the other seven in the time allotted, contact the teacher to discuss it.

Art of Game Design by Jesse Schell: 10 Prototyping Tips Every game poses Risks: ways in which the game as proposed may not be as fun or create-able in the time allotted. The purpose of prototyping is to answer questions about the game s Risks as fast as possible. These risk-questions should go from the general Is this game/feature fun to the specific Is the time interval of this attack satisfying and sustainable against this particular boss. We want to try solutions to these risk- questions that we can test as quickly as possible, thus closing the loop on that question. We want to run through as many questions-solution-test loops as possible before Production begins.

Art of Game Design by Jesse Schell: 10 Prototyping Tips 1. Answer At Least One Risk Question (but don t try to test the entire game). 6. Avoid Digital where possible (paper is usually faster!). 2. Avoid Quality (graybox art and audio, undocumented code just draft the wok so we can test and complete the loop!). 7. Prototypes do not always need to be interactive (especially for raw load tests, or NPC behavior). 8. Use a fast-loop game engine (Unity lets us change code and test while in play mode saves much time) 3. Plan to Throw the Prototype Away (this will help you work more quickly to close the loop) 9. Spend time building the core toy, to be sure it is fun (maybe first). 4. Prioritize (which risk-questions must be answered first?) 10. Take advantage of more loops (your game will improve with more prototypes to answer risk questions before production!) 5. Parallelize Prototype Productivity (have a team? Work on multiple questions at once often, those answers will inform each other, and the next questions to be asked!)

Unity Collaboration: Project Workflow Organization QUESTION: How do we make a prototyping mindset an integral part of a team collaboration? First, let s see the non-iterative process that used to be standard at most software development companies.

Unity Collaboration: Project Workflow Organization Waterfall Model : Sequential (non-iterative) development process. It is Anti-loop: more interested in plowing ahead fulfilling the starting vision as efficiently than pivoting based on user concerns. No room for User Experience to meaningfully influence the project. Parts created in isolation (not seen together until the end, often kludged together). Why did we ever do this? Manufacturing, like building a bridge: plan it and then do it. Materials make it too costly to redesign halfway through. But software is different

Unity Collaboration: Project Workflow Organization Barry Boem s Spiral gives us loops: risk assessment, prototype, evaluate, repeat. The entire idea is to test ideas before investing serious development time. QUESTION: What do you know about Agile and Scrum ?

Unity Collaboration: Project Workflow Organization Agile is a time-boxed, iterative approach to software delivery that builds software iteratively from the start of the project, instead of trying to deliver it all at once near the end. Agile works by breaking projects down into little bits of user functionality called User Stories (features customers want), prioritizing them, and then continuously delivering them in short cycles called Iterations (short periods for team to build working software to deliver top User Stories). The Agile MANIFESTO: Individuals + Interactions > Process + Tools Working Software > Comprehensive Documentation Customer Collaboration > Contract Negotiation Responding to Change > Blindly Following a Plan There is value on the right, but we value the left more

Unity Collaboration: Project Workflow Organization Scrum is an Agile framework for completing complex projects, to improve teamwork, communications, and speed. The Scrum framework: 1. Backlog: Team creates prioritized wish-list. 2. Team Planning = pulling top chunks from Backlog and deciding how to implement those pieces. 3. Sprint:Team spends time heads down to complete work. 4. Daily Scrum: Team meets daily to assess progress. 5. ScrumMaster keeps the team focused on its goal. 6. At Sprint-End work should be shippable: ready to test! 7. Sprint ends with a sprint review and retrospective. 8. Next sprint: choose next chunk and begin working again.

GitHub Some important GitHub reminders: Work in a separate GitHub Branch. Be sure your code compiles and is safe to merge with the main branch. Feel free to create a folder with your name to contain your work, or work in the provided student folders. Use unique file names, to avoid naming conflicts with other students. A safe bet is to include your name in the file name, as well as the feature name. Please never Revert the project, ever, ever, ever. Are there horrible conflicts with your local copy, such that you need a scorched earth solution? Duplicate the files you want to save to a new folder on your computer, then delete your entire copy of the project from your computer, and re-pull the project to a new folder. Contact the teacher rather than make changes to the core assets, but feel free to nest the core teacher assets in your work, as needed.

Unity Project 1 Resources Our course site includes a page of USEFUL UNITY TUTORIALS: MadWomb.com/Unity Check out these tutorials or your work on the first project: How to work with Unity Tilemapping: http://madwomb.com/tutorials/GameDesign_Unity2DTilemap.html Re-using white 2D sprites to color in the Sprite Renderer: http://madwomb.com/tutorials/GameDesign_Unity2DTilemap.html#white 2D Character Animation: Mecanim/Animator State Machines: http://madwomb.com/tutorials/GameDesign_Unity2DTilemap.html#move How to work with the GitHub Desktop App: http://madwomb.com/tutorials/GameDesign_UnityGithub.html

Project 1 Final Feature Submissions! It s week 3! Your final Showcase Scenes and Feature Prefabs are due this week! How are you doing? The goal of this week is: 1. PLAYTEST your Showcase scenes and Feature Prefabs! 2. Give feedback on clarity and usability. 3. Discuss which other student Features might be good fits for your scene. 4. Revise your scenes, conduct further playesting, and submit our Sprint Summary/Playtesting report. Everyone please open Github Desktop (or equivalent), make sure you are pointed to the Main branch, and Pull everyone s Unity work! Please open Unity and our Project 1.

Project 1 Final Feature Submissions! THIS WEEK we will playtest your Scenes and Features. Final Revisions to your Feature and Showcase Scene based on our feedback are due Saturday, Noon, Pacific time. Saturday afternoon we will post a web-enabled build of them game on itch.io, to support further playtesting. You are then expected to conduct further Playtesting with at least 2 people not in this course: Please contact people soon to make sure they can playtest for you this weekend, at a time when you can observe them playing (over Zoom, etc). Final Project Summary and Playtesting DOC is due Monday!

Project 1 Final Feature Submissions! Your FEATURE is expected to include: 1. Functional behavior, along the lines of the description you offered in the first Spec Doc and the class Whiteboard: https://docs.google.com/document/d/1-nS-niPQpW7R396Gw- kUDRcpvxuh9FpuPju3J5rWP2s/edit 2. Feedback that clarifies what your Feature is doing. Consider using color, animation, and anything else to indicate change, potentially including Canvas instructions. Contact the teacher on Chat for help! 3. APrefab containing all parts, that can be dropped into any classmate's scene, located in the Prefabs > Student Prefabs folder. Your SHOWCASE SCENE is expected to include: 1. Your functioning Feature! The Player, the Canvas with Health (and any stats you want added), and any other provided features (lava, spikes, etc) 2. Design of the 2D space (using the Windows > 2D > Tilemapping system and provided Tilemap) that offers an experience that highlights how your feature would operate in a level (1-2 ish minutes of gameplay) 3. At least one Feature prefab from a classmate that complements this experience. 4. An Exit (switches optional) that leads to a classmate's Scene (ideally one that "fits" along a difficulty curve: one that is a little more challenging than yours)

Project 1 Playtesting! You have three goals with today s playtesting: 1. Get Feedback on your level and feature You will use this to consider revisions to your Prefab and Scene before this Saturday! And a summary will go into your playtesting report. Yay! 2. Give feedback to each other Take the opportunity to share your insights! 3. Find features you want to include in your level Look through your classmates scenes to see which feature/s you might want to incorporate into your own Showcase level. Which could interact well with yours, in terms of driving interesting player choices or providing useful player feedback?

Project 1 Playtesting: prep Open the class Whiteboard doc. Note the playtesting grids for each student. Find yours! Enter the missing top information for your grid: Your Discord handle (to more easily reach each other on the class discord) The Classmates Feature/s you are using so far in your Scene. Notice the four basic questions asked of all projects. They are for general playtesting, and will hopefully lead to useful insights. Now, add 1-2 questions for Focus Playtesting: questions that are specific to your project! Examples could include did you have time to grab all the gems before the exploding enemy appeared, etc. Write down your 1-2 Focus Questions in the slots provided.

Project 1 Playtesting! NOW WE PLAYTEST! Choose a Scene in the class Whiteboard (one that does not already have more than 4 playtesters) Add your name in the Playtesters slot. Play the MainMenu Scene, find the chosen Scene and play it. If your player dies and you want to see it again, hit the MainMenu for the lose screen and re-enter the Scene. You can also restart from the pause menu ([esc]). Once you have played it enough to get a sense of the main Feature and how it is showcased, return to the Whiteboard and provide feedback in answer to most/all of the questions. Please be constructive and specific in what you think works and what could be improved, and include your name in parenthesis at the start. For example: (JasonWiser): I could see there was a power-up ability with the cool-down bar in the canvas, but I could not figure out how to activate it. I suggest adding a short text instruction to the Canvas.

Level Design: How to Introduce your Feature (and not let the borrowed feature steal the initial spotlight) Student 1 creates a monster feature that replicates. They design a Scene space that has the player moving all the way to the left, then to the right, snaking upwards to the door, so that the player encounters a wave of duplicated monsters by the final area! So far so good. They decide to include a classmate s feature that builds bridges over lava, which is a nice pairing of mechanics: slow the player down as they race to escape the monster population explosion. BUT, if the lava is a big part of the first area, the player will not have the chance to focus on the monsters replicating: they will focus on learning the bridging mechanic to escape.

Level Design: How to Introduce your Feature (and not let the borrowed feature to steal the initial spotlight) The first area should have no lava and start with one monster, and should give the player a chance to see the replication, including animation that makes it super clear that each monster becomes two. Then the second area could include some lava to introduce that, but have a walking path around it. Then the third layer can have the lava block the path, and introduce the bridge mechanic with instructions. Offer one thing at a time when teaching the player something new, so they can focus on that you want them to see and learn!

Level Design: How to Introduce your Feature (and not let the borrowed feature to steal the initial spotlight) Student 2 created the bridges Feature. Their level does a good job of offering a low-pressure scenario to learn the bridging, with only one monster to avoid and a space full of lava to bridge. The classmate s Feature they chose is the runaway door, which is a great surprise as it runs sway into lava, making the player act more quickly with the bridges they have learned to make. The initial learning experience could be enhanced if the player started in a room without all the non-lava path choices and without enemy pressure. Start with instructions and a single lava-filled corridor to the main area, so the player has to focus on learning well to bridge.

WEEK 3 To-do List: 1. Revise your Feature Prefab in Unity based on class feedback. Strive for better player feedback (clarity with colors and animation, concise canvas text instructions) and usability. Due by Saturday, noon, Pacific Time. 2. Revise your Unity Scene Showcase Level to show off your feature, including at least one classmate feature. Due by Saturday noon, Pacific Time. 3. Playtest your final level: We will post an itch.io build of all progress Saturday afternoon. 4. Complete the Project 1 Summary/Playtesting Report (3 pages, due Monday). Please contact the teacher on Teams Chat time to help with anything in Design, Unity, or GitHub! HAVE A GREAT WEEK! JasonWiserArt@gmail.com