This will serve as a collation of research into tutorialisation and how to create a good tutorial in general. The Tutorial Design itself will be in a seperate page after some ideation influenced directly from this document.

Point of Advice	Takeaways	Uses within our Game	Requirements
Less Text	Text is an awful way to convey vital information to the player	We shouldn't rely on the dialogue system to relay the information to the player, rather walking the player through it	Might need to develop tools for specific scripted events
No Front Loading	Not every piece of information needs to be conveyed right off the bat. Insteal slowly reveal information as needed.	Maybe we should break up the tutorial into chunks, one at the beginning for basic uses and concepts, then another one or two for advanced concepts later	Would require alot of testing to prevent sequence breaking
Make it Fun	Most people learn through engagement, interaction and through fun experimenting, not tedium	We should still treat the tutorial puzzles as fun encounters, not just a tutorial	Would need to iterativley design puzzles within tutorials as "Fun" is a very vague measurement. Instead we should focus on making it engaging and interactive, then iterate until it is fun
Reinforce Learning Through Play	The things taught in the tutorial ned to be highlighted and emphasized through play subtly	Each puzzle after the tutorial should be developed in the same vein as the tutorial, and reinforce the aspects taught.	We could use Dialogue to reinforce this, as well as puzzle completion conditions
Listen to your players	Playtest your tutorial the absolute most	We will need to possibly section off the tutorial from the main world to reduce edge cases and bugs occuring. If we make it in the main world then we must maticulously test.	Qualitative & Quantitative data gathering specific to the tutorial
Tutorials Should be skippable	Tutorials should never interupt the flow of play and should be optionally skippable	We could again section of the first chunk of the tutorial to teach controls and possibly edit mode	A seperate level for the beginning of the tutorial and any other elements of the tutorial having a skip option

This video delves into context sensitive design, in which the tutorial is custom tailored to each player through only occuring when and if the players need it. For example, if a player is constantly dying then a tutorial should appear to help them out, rather than front loading a tutorial and having the player forget the information.

This is very complicated to do, let alone get right. Especially for systems driven games, having to account for every variable is time consuming and possibly not even within scope. But we can implement various elements into our onboarding to help out players.

By setting a timer on each puzzle and having a popup appear, or NPC have a unique dialogue line that occurs to help the player out whenever they are stuck would be incredibly helpful to certain players that might need it. Below is a list of areas that could benefit from context sensitive design:

• Puzzle Time
• Amount of times a puzzle has reset
• Not having enough Nodes for a specific puzzle
• Player trying to access Golems not within the puzzle
• Every element in the game (When data holes are introduced, multi-golem editing etc)

This vide primarily consolidated and reinforces all of the information from the previous two videos above.

The one key difference is the point about the reward. The tutorial will naturally be the dip in the interest curve directly after the hook, and thats okay. But then the player must be greatly rewarded for making it through. The two types of rewards are detailed below.

Point of Advice	Takeaways	Uses in our Game	Requirements
Type of Hook 1: Mechanical	Gripping the player with something they do mechanically within your game, in our case editing the world	We could try to elicit this by creating a unique event that can occur in the tutorial if the player figures it out	A unique puzzle to accomplish in the tutorial that is more than just a teaching requirement
Type of Hook 2: Narrative	Gripping the player with a unique narrative element or through the story	This isn't really what we should focus on within our time frame. But going forward we can have an interesting set piece at the beginning that sets up why the character is travelling through the woods to find their sister	A unique set piece to develop at the very start, before or after the tutorial
Type of Hook 3: Visual	Gripping the player with a beautiful or memorable visual set piece (similar to the beginning of Kinoko)	This is more within our frame of reference and scope. We could start the game with a beautiful/cute vista or image such as our main character waking up lazily in the forest	A small, highly polished scripted sequenced to kick-off our game
Reward - First Part: Short Term Reward	Players should be rewarded for making it through the tutorial. This immediate reward can be something small like a level up or new tool	We could grant the player a bunch of the new nodes they have just learned to use as well as some efficiency points towards the first door, but make a big deal out of it.	A hyper focus on polish and rewarding the player. This will require VFX and possibly even teaching the player what the resources are
Reward - Second Part: Long Term Reward	Reinforces why the player should want to keep playing	We should try to hint to more or a further use of the mechanic that the player can do later (Or even hint towards other ways we can use it after the vertical slice)	A small dialogue snippet for lower scope. At a risk of increasing scope, we could have a small set piece of Golems all acting on advanced behaviour to show what the player can get them to do later

This consolidated and reinforces all the information but presented differently than in the previous video.

Tips	Takeaways	Uses in our Game	Requirements
Blend tutorial into the game	Don't think about the tutorial as an isolated experience but rather baked so seemlessly into the experience the player cannot tell	Context Sensitive tutorials might help to achieve this, especially when paired with a tutorial built into the woods area	A lot of iteration and context sensitive design
Better to have the player do than read	Doing the action instead of being told it is fun and memorable, whereas text is information dense and while easy to create, difficult to parse	Don't rely on the dialogue system for tutorialisation	Discipline
Spread out the teaching of game mechanics	Do not front load your design but teach mechanics only when necassary	Chunk the tutorial into seperate section and only teach things when necessary	Weaving disperate elements of the tutorial with certain areas of the level
Just get the player to do it once	While it may be good to have a step based objective tutorial, the player shouldnt do the same actions multiple times to ensure they have learned it	Only have an objective requirement of 1 for each action in a tutorial	Objectives to complete in tutorials limitted to 1
Use fewer words	There should be a maximum of eight words on the screen at any given moment	Create initial tutorial text for testing then cut, cut, cut.	Regular reviews and testing of the tutorial
Use onobtrusive messaging	This is essentially a refocus from direct communication to passive communication. Instead of stealing the players attention away and emanding they do certain actions, rather make them optional until the player chooses to do them	This can espetially be useful with context sensitive tutorials, in that the player can opt out by just not activating the tutorial or performing the action on screen. We can also use this by making the solution suggested by the tutorial character optional	A tremendous amount of trust in the player and a lot of work in the design proces to think around all the scenarios players can get stuck
Don't create noise	Do not pollute your communication channels for tutorialising with world building and backstory. This includes the types of channels you use, eg using the simple dialogue system to communicate something of radically different importance	We should use an entirely different system for tutorialisation, seperate from the dialogue system.	Tutorial Dialogue/Hint/Objective System
Use visuals to teach	You should able to look at game objects and quickly establish what function they have in the game	This falls down to art direction, communicating affordance and utility in the assets we use in puzzles	Strong Art Direction and regular testing of gameplay elements
Leverage what people already know	You can rely on players extra-ludic knowledge to fill in the blanks - Zombies/Golems are slow and dimwitted	Communicate Golems need for reprogramming through slow animations and hulking character model. We can also rely on some of the players previous gaming knowledge a bit, especially if they have played rabbids coding	A strong trust in the player and specific tutorialisation of certain areas
Use Adaptive Messaging	This refers to avoiding explicit direction as much as possible and relying on hints more	This would tie in with context sensitive design and not be as obtrusive to the player. Could use hints in certain areas.	An adaptive hint system

• There is psychology at work here: Miller’s Law: The Magical Number Seven, Plus or Minus Two. Having clear and concise text that you can read at a glance prevents slowing down gameplay.
• Rules are easiest to remember when they are simple.
• The longer the text is the less likely people are to read it.
• It is a better experience to leave the player breadcrumbs and have them feel smart when they connect the dots, as opposed to over explaining and risk patronizing players.