Spent the whole day on this thing. It's not done yet, but it's close. It's about to the point where I'd consider testing it, but I need to put a few other non-tutorial things in the game first before pushing the game onto any playtesters. I want to patch all the holes and test the completed product, not something littered with flaws and potential excuses, if that makes any sense. Feedback is less iffy when you're testing something that's supposed to be holding its own weight. Enter CR-0. He will be your guiding light through the game's mechanics. He also has an attitude. Isn't he charming? In all seriousness, though, it's meant to give the game a little more character, but is also a prod at your average game tutorial's almost-patronizing language. A dose of humor as well. The orange censor is my working title, which I'm not going to spoil just yet. Onto a little tutorial talk, though. My tutorial starts like this: If you read my last post, you might know why it's nearly barren. I introduce things one at a time, and that means hiding them when they're not relevant yet. It reduces complexity and prevents players from getting overwhelmed. When things are introduced, though, they show up and get highlighted so you can't miss them. Pretty much everything that's introduced you experience yourself through interaction, and you are forced to do the basic actions to foolproof the process. No transient information where you learn through text and have to remember it for the end of the tutorial when you finally get control. Here you learn it, do it, and move on. And where the learning isn't foolproof, repetition bolsters.
The tutorial can't cover everything, though, and it would honestly be bad if it did. Dumping all relevant info in the game on the player in the first five minutes is a great way to have your players forget everything you show them. As such, my tutorial teaches only the basics you need to function, and leaves the rest for you to learn at your leisure and comfort. I plan on a sort of almanac or handbook in the menus that gives you all the rest of the information you need to thrive. And for immediate, permanent access to tutorial info for anything that involves a menu, CR-0 will be there to guide you through it. Working on something I thought would be on backlog for a while. I was dreading getting around to it because it's a lot of effort and not a lot of fun, but I think I've found it's a little easier than I made it out to be.
Tutorials are a tough task. The odds are stacked against you, yet they matter the most out of anything. I would even go so far as to say tutorials are as important than the gameplay itself. The vast majority of your players who drop your game will do so in the first few minutes. There's even a tenet in game design that is something along the lines of "the first few minutes/moments are the most important. Not the ending, not the story." First impressions are what defines your game for most people--after a first impression is when your players will judge whether they like it enough to keep playing or don't like it. Tutorials are your first impression. You have to show the player what the game has to offer, but that's not all. You have to teach them how to play, which is a daunting task that even most big names do incorrectly. I'm sure most of you have run into a game where the tutorial just... sucks. It's a common occurrence. And frustration or annoyance from such is a very quick demotivator, and will ruin your first impression in an instant. Learning is the toughest part. How do you teach someone to learn? There are a few core concepts that apply in games, and while games and game tutorials are not a thoroughly studied field, it isn't an impossible task. Here are a few concepts that I will be using in my own tutorials that I have collected from my experience in games academia and elsewhere: Repetition builds memory. This is common knowledge. The more you repeat or use something--a technique, a recipe, a name, a new word, where something is--the more your brain can reencode and reinforce it. People learn best by doing. Tutorials often don't do this enough, but it's been getting better. Our monkey brains learn by actions: the strongest way to make those bonds that form memory is through cause and effect. Monkey see, monkey do. We also learn extremely well through copying others--infants and toddlers do this very often, especially relating to motor function. For games, though, this means stop with the reading. People don't learn well by reading. Give them examples and let them do it themselves, reinforcing the mechanics and controls as they forge that memory bond through their own actions. Repetition and action is what turns working (short-term) memory into long-term memory. The transient information effect. Ever forget something in a tutorial? Ever had to mash keys or search online to find something you forgot? Ever had tutorial text disappear before you had a chance to read it all? This is the transient information effect: information that should be permanently accessible (for learning purposes) not being permanent. Impermanent information must be memorized, which increases the cognitive load on your players. You want their brains to be wholly focused on learning, so extra cognitive load is very bad. And stop assuming your players remember everything after your tutorial is done. That just doesn't happen. Tutorials aren't magic, and neither are your players. Keep that information easily available somewhere. One thing at a time. Our working (short-term) memory can only hold about three or four things. This could be groceries, or a colleague's name, or a control in a game. You need to encode these into long-term memory before you can occupy more short-term memory space with new things, otherwise they won't last. Though, I mentioned cognitive load earlier--minimizing that makes learning easier. This means you want to introduce one concept, control, or otherwise at a time, allow the player to transfer it to long-term memory with action, and then move on. Tutorials sometimes will dump more than one thing on players when trying to explain a system or complex mechanic. While this isn't easy to avoid, there are ways to condense, simplify, or spread information out to keep learning optimized. Some complex systems or mechanics may need to be taught over an extended time and not a moment's tutorial. My own plan for tutorials tries to incorporate these things. Players will learn one thing at a time, always given an opportunity to do the action themselves, and often the next action will require the previous action (which tests and reinforces memory). They will learn core mechanics first--how to enable a mode, how to plant/water, how to combo, and temperature ranges. The rest--weather effects, upgrades, etc.--they are left to learn on their own so they can learn at their own pace, and I plan on adding an almanac of sorts to reference so they can learn new or rare things and relearn/reference learned things. Additionally, everything that has a place in the menus will have tutorial info readily available when you hover over it, avoiding transient information and letting players choose when and what they want to teach themselves. I can't say my approach is perfect, but playtesting and study will improve it. And hopefully, it's enough to make a respectable first impression. I use "Update" when I'm not feeling creative enough to think up a title. Don't tell anyone. On the tail end of the weather improvements, I modified the UI as a little cleaning up post-implementation. The bar that showed weather chances used to show the chances for the weather that day, but since you get that information the same time as the weather it details, it's kind of useless (e.g. it'll tell you "it could rain" only after it's already started raining). I pushed some values around so the UI now shows predictions for tomorrow's weather. I also added a small temperature predicter as well, since weather isn't the only thing that affects your crops. This is not the end of this UI, though, as I have a theory the game might be more fun if you know the exact weather for tomorrow. To put it cheaply, it'd make it less of a guessing game, which may give players some useful and engaging leeway to plan their next move. I expect to hit the game with a fair amount of playtesters before drawing a conclusion on which method to keep, so for now it is an issue postponed. Additionally, a value has been added to the water bar. Nothing much, but it does a great deal to clarify the mechanics of the bar itself. Questions like "how many plots can I water?" and "how fast does my water regenerate?" are no longer shrouded in hidden values and vagueness. I have also rounded out the list of potential crops. It's mostly just a dump of well-known crops, and has come to a length of 109. This includes your average field-grown plants, a handful of berry bushes, and a ton of fruit trees (spoiler!).
|