Random thoughts on Tutorials

I was writing a Reddit post and thought "y'know what, this sounds like the kind of thing I should be putting on my blog," so here it is with zero editing, as usual.

As a player slash sometimes-designer, I'm not shocked in the slightest. Games that do tell you what to do are so much easier to pick up and get right into. I want to learn how to move, jump, shoot, interact, one button at a time. I don't want to look up what the buttons do beforehand and hope I remember it all with zero context for my actions. Flash games are an extremely good way to get a lot of intro sequences very quickly, and the good ones very seamlessly get you quickly into the game itself.
But, I do agree that having that optional screen is much better than having nothing at all. And having an optional screen of "advanced tactics" can be helpful. I'd say there's a heirarchy of good-design with respect to tutorials. From best to worst:

• No-text subtle nudges and level design that guarantees players pick up on the mechanics
• Seamless integration of textual instructions that don't take control from the player so advanced players can speed right through
• Obvious, optional tutorials so that people who can figure it out on their own can do so, but people who get stuck can get help
• Mandatory tutorials that explain how to do something and don't let you through without you first showing you understood the mechanic
• Mandatory tutorials that explain how to do something once without letting you try it out and there's no way to get another explanation if you missed it the first time
• Tutorials that explain how everything in the game works all at once in excruciating detail, before you have any real context for how the game plays
• "Eh, they'll figure it out"

Demons' Souls is an interesting case study. It has two tutorial levels, the first of which is the official tutorial level, the second is the "first real level". Level 0 has a bunch of floor messages that explain the controls of the game, but the enemy damage is scaled down to the degree that all it teaches you is the base-level mechanics; how to move, how to use items, etc. The second tutorial is where the game teaches you how to play Demons' Souls for real, it knows at this point that you know the inputs, now it teaches you the flow of the game; cautiously approaching problems, how to effectively kill enemies, that you should be blocking constantly, how to time healing items so you don't get mauled mid-heal, etc. However the difficulty of Level 1 is so severe that it's hard to immediately see what the correct action was for a new player who isn't fluent in the game's philosophy about difficulty. The level is also long enough that iteration is very protracted. There are shortcuts, but the level design doesn't encourage players to find them.
So, Demons' Souls actually has a pretty crappy tutorial. Dark Souls, however, has a brilliant tutorial, all because it has better-tuned difficulty, along with a more-educational structure. It does still have a fairly lethal tutorial, in that you can go from full health to none in a single poorly-understood encounter, which is good because it means players need to wrap their heads around how that fight works before they can succeed at the level as a whole.
So yeah, Dark Souls teaches a very complicated game with a very straightforward and transparent tutorial.

Demons' / Dark Souls

The following is from an email I wrote to the guys at Extra Credits, which is an excellent show that if you aren't already watching, you should watch. I realized I hadn't talked about game design on this blog at all recently, and that this was perfect for it. Enjoy.

I think they're extremely well-designed games. I'm going to refer to Dark Souls specifically, because I've played it more recently. One of the most brilliant things they did with the design, I feel, is the control scheme. More specifically, how "attack" isn't one of the four face buttons. They probably mapped the left and right hands to the shoulder buttons more because of symmetry and the elegance of everything having a primary/secondary use, but this had a secondary effect that was possibly even more beneficial. The four face buttons are the most comfortable buttons to hit quickly and/or repeatedly, which is why games usually assign their most common actions on those buttons. Dark Souls has their attack function, normally used relentlessly in Action-RPGs, on a non-primary button. This emphasizes their focus on carefully choosing when and where you attack, as opposed to running in guns-(or swords-)blazing. It also -physically- reinforces this notion, because the shoulder buttons are somewhat awkward and painful to tap repeatedly. This physical reinforcement of how to succeed in the game is one of the most brilliant pieces of design work I think I've ever seen.

The rest game is filled with similarly brilliant design choices as well. Mobility at the cost of protection makes for an interesting choice (more so in Dark than Demons', because of the increased effectiveness of armor). No music except during boss fights creates an atmosphere of tension and loneliness, and a sharp jarring contrast that puts the player in awe when a boss does show up, and also gives a sense of epicness that serves to highlight what a blast the bosses are to fight. The only thing I feel was a mistake was the Mimics. Yes, you only ever fall for it once, but, c'mon guys. Now you're just being mean. And missing a bonfire is fairly aggravating, but the game has such an exploration/survival bent that I'm willing to accept it.

Personally, I don't play it at night anymore. Not because the monsters ghouls zombies skeletons aberrations what-have-you are particularly scary. To me, the game as a whole isn't terrifying for the most part, despite the numerous enemies that, presented differently, would be much scarier. I can't play the game at night because it's atmospherically spooky, and the gameplay reinforces the terror of exploring somewhere you've never been, where everything is trying to kill you. That sense of the entire game's world being out to get you - because it is, mind - is more lastingly chilling than many things that want to be scary. When I'm done playing Dark Souls, I am, thanks to the gameplay and level design, paranoid and jumpy for at least an hour. I find myself checking all the corners of my house, not completely trusting that there are no traps or monsters around. I want to be aware of whatever dangers are around, because I also know from the game that whatever comes my way, with perseverance and careful tactics, I can defeat it. The game isn't purely tension all the time, even though the player is always extremely vulnerable. If anything, this vulnerability is empowering, because even though the player's avatar is heroic, strong, and has magical powers, the bosses they topple and even the hordes of minions they defeat are all so much more powerful than they are it's amazing that the player even warrants their attention. And yet, with just a little persistence (or, sometimes a lot), they emerge triumphant.

Balance in all Things

Today I'd like to talk about my idea behind Rouge's game balance.

More specifically, how there won't be any.

Oh don't look at me like that. The game will be perfectly playable (you know, when I eventually start releasing the bloody thing), it's just that, beyond the first floor of the first dungeon, any challenge the player faces will be effectively self-imposed.

I'm basically taking the Fable approach to balance.

Philosophy III : Cutscenes and Storytelling

Fuck cutscenes.

Cutscenes are a pointless waste of everybody's time.

Okay, qualifying statements.

Cutscenes aren't completely useless per se, but only in small bits at a time. As in, over five minutes and you've hit time-waster status.

Now, you might need more than that to exposit things at the very beginning/end of the game, and maybe some longer things around the three-quarter mark where stuff starts to get climactic, so I'll go ahead and allow say four longer cutscenes in the whole thing.

Version: 0.1.2

Oh hey look, it's been a week or so.

Shutting up and coding has been rather fruitful.

So, I'm done with version 0.1.2. At least. I'd feel almost comfortable saying it was up to 0.1.5, given that these versionings are pretty much completely arbitrary and I did a good lot of stuff. Rather, did one thing very thoroughly. That said, I'm going to stick with calling it 0.1.2, but might jump up a lot after hitting some key features for 0.2

Things to do for 0.2:

1. One infinitely-deep dungeon
2. Enemies and items that increase in power along with dungeon level
3. Backbone of the Skill system (the "No Useless Mages" clause)
4. Beginning stages of enemy AI (intelligent item equipping, decent pathfinding, skill usage)
5. Acceptably good battle mechanics (2-weapon fighting, holding one weapon in two hands, shield utility, basic combat balance)
6. A main menu
7. Being able to save/load

Philosophy II : On leveling

When it comes to RPGs, a character advancement system is something of a big deal. For some reason, I think there's very little quite as awesome as an interesting, rewarding system of character growth and advancement (then again, I think coding is fun, so feel free to take that with a massive grain of salt...).

So, naturally, it bugs me to no end when game developers screw everything up.

Okay, maybe I threw down that gauntlet a little too hard without qualification. Let me back up a bit.

Philosophy

I've been reviewing my changelog recently (not this devlog; the more mundane day-by-day "what I've been doing"), and I realize I've been spending a LOT of time tweaking the UI lately. Part of that makes me yell at myself a bit (stuff like "you should be doing cooler/more important things instead!"), but for the most part I'm completely fine with that. Thing is, the first, biggest, most major push I had saying "program a roguelike" was one simple thing: I wanted to resize the friggin' window.

Why yes, I have been working on this thing.

Gonna go ahead and say Rouge is up to version 0.1.1

Think I'll release the damn thing when I feel I can do so without having to qualify a bunch of stuff. This is independent of how nice an audience I can find for it; I'm still going to want to say "hey yeah you should ignore these parts they're not very good and this part'll be better later on and I'm planning on doing X in a later version and I really don't have the infrastructure for Y yet but I'm working on it and..." because I have grandiose plans for it and its current shadow of things to come is, frankly, kind of embarrassing.

The Menu for this evening

I've spent a good deal of time re-tweaking the menu systems.

One thing I've never been fond of in roguelikes is looking at a list of choices where half the things make me ask "what the hell is that?" And even if I know what something is, that doesn't mean I know enough to make good decisions about it. I can surmise that a Troll has higher Strength and lower Intelligence, making one a poor choice for a Mage character, but I can't intuit that trolls have slightly better-than-average Willpower scores, making them more resistant to magic, and I'm not certain whether this universe has the "trolls heal quickly" rule in play.

And while I could easily just tell players to RTFM (I mean, it is a roguelike...), there's no reason to assume everyone has prescient knowledge of the design decisions I've made to differentiate my world from the "standard fantasy setting" a.k.a. Tolkien (Our Elves are Better, after all).

So, I added a bit where you can see a description of what you're picking. Right now I've just got the stat plus/minus-es, but in the future that'll come alongside some flavor text for each thing. In order to actually see the description, I've added a cursor, letting you select which thing you want to look at. You can still just strike the key corresponding to the thing desired, for those who know what stuff is and just want to get on with it without having to scroll the bloody thing down. And you can jump the cursor directly to what you want to look at by holding Alt and pressing the corresponding key (which honestly feels a bit awkward. I'll probably change it to Ctrl, which involves changing a single character in the code thanks to my sexy, sexy Input class).

Programmatically, the coolest thing about the menu system is that it's almost completely modular. I used to have each MenuState class handle redundant things like making the list of stuff to show, handling inputs (from the Input class, of course), etc. Now all the generic stuff is put in the Menu class, and each MenuState has a Menu as part of it. Each MenuState now only has code relevant to the different things it does, which is the whole bloody point of classes in the first place.

A Whole New World, Every Single Time

I'd thinking about how to implement a procedurally-generated overworld. Not yet looking at individual organic-looking tile placement, god no, but instead on how to organize a random world into an interesting underlying framework.

On the topic of things being interesting, my original plan was to make an overworld of wide open areas without changing the scale from dungeons or towns, with no way to travel on a world map (see Secret of Mana). Then I realized how terribly tedious and monotonous and repetitive and dull and uninteresting and dreadful and repetitive that would be, and thought instead of having a fast-travel option. I went back and forth between a Dwarf Fortress-style zoomed-out representation to travel quickly or a Diablo2-style waypoint option and select from a list of towns you've visited. It was the former which made me realize that, given the option, most (sane) players would choose the faster zoomed-out traversal, defeating the point of trying to catch their attention with repetitively repetitive repetition in the larger representation. It would also be tricker to randomly generate convincingly, and much more painful to try and save. So I decided to go with just the zoomed-out representation, because it's easier for me and less repetitive for you. Oh don't look at me like that. If this style of overworld is good enough for Final Fantasy, Chrono Trigger, and ADOM, it's more than good enough for me. More importantly, I doubt anyone would honestly want an alternative. Realism is only worth pursuing in videogames if it enhances the experience, and in this case it adds drudgery and repetition, not fun (a premise I'll cover further in an upcoming entry).

One fun Item

More and more I'm thinking about using a more Diablo-style magic item system than your typical roguelike, one in which the term "loot" might get passed around from time to time. This will all require me to implement items in general, but that's a task I'd have to go about doing anyway.

The plan then is to define various item types and base statistics which can then be modified by various adjectives. A semiinteresting consequence is that these adjectives can be magical or mundane, and these all will add up to some rather verbose item names, i.e. a Flaming Vorpal Sharp Iron Longsword of Balance and Pestilence.

On identification, the basic aspects of an item would be available at first glance; taking the above item as an example, on the ground the item would read "metal Longsword". After an Appraisal, something which should take a short but non-negligible amount of time (around a minute), the extent of the item's physical properties would be revealed, so the aforementioned sword would now show up as a "Sharp Iron Longsword". Depending on a character's sensetivity to magic, the item's magical nature can be known as early as seeing the item on the ground, or even from a distance if the item in question was of artifact-level power. At whatever point the item is revealed to be magical, the item's name changes color to whichever tier of power it belongs to. At that point, an Identify spell (available on scrolls, from the players' spellbook, or from some NPCs in town) would need to be cast to reveal the exact nature of the magic item, even though its effects have been benefiting the player from the time they equipped it.

A part of me thinks it could be interesting to have there be no easy identify - no Deckard Cain to tell you what things are for a negligible fee or less - and have the properties of the item revealed as the player's character observes their effects. But then, there would be little benefit to doing so, and the process of rubbing various combinations of weapons and enemies together would be more tedious than imaginitive, even though the process would in most cases be fairly quick (i.e., it's a simple matter of identifying Volcanic weaponry as it tends to set things on fire), and thus would be a good deal of work on my part for very little if any benefit on the player's part.

Have some Class, man

So I've been thinking more recently about game design rather than game implementation, which I suppose is a pretty good direction for things to take.

The next step is to make the combat system, and there's several ways I can start this.

1. Program the "attack" command; add "if enemy in tile you're stepping on, don't move, but attack", program the attack routine. Right now I'm thinking damage should look something like C*(A*ATK-B*DEF)^2 +- 30%, which is obviously not set in stone.
2. Program a "messages" subwindow to display "[Player] hit [Enemy]. [Enemy] missed [Player]" stuffs. Pretty straightforward, the trickiest bit is going to be knowing when to stop scaling the window that displays across the top of the screen. Actually it'd be pretty straightforward with a fixed-width font; when adding characters to a Message string, keep track of the length on the current line, when length > number_of_characters_that_can_fit_on_a_line ((screen_width - status pane width)/pixels_per_character), back up until a space is found, change the space to a newline, keep going until a fixed number of lines, prompt the player for more. The most annoying bit then is going to be handling the "more" input, but I'll just make it loop until the player presses something for now.
   
3. Add enemy "AI". At the moment I'm going to start off with a simple "always move towards the player" method which will generally keep enemies stuck in rooms, but occasionally allow them to come into a room from some adjoining hallway. It's also simpler than "if in sight of player move towards" both in terms of implementation and computational complexity (no need to scan what each enemy can see), so that's pretty cool. Also would need to add an "attack" check to enemies, but that's trivial enough to keep this nondependent on 1.
4. Leveling a character up.

#4 is the sexiest-looking, so I'm wanting to do it first. It also has a bunch to do with one of the real features of the game, the class system. And being able to make characters of multiple classes.

The player will start being able to choose from one of three to five basic classes like Fighter, Mage, Thief, and with each level up, the player chooses which class to put the level in. After meeting certain prerequisites, the player will be able to choose from new, more powerful classes with better stats and/or different skills, i.e. Knight, Ninja, Wizard, Necromancer, Ranger, and so forth. There's three ways I'd like to go about this:

1. New characters start choosing from base classes; unlock new classes as they level up, and may add levels in any class they have unlocked (allowing for Figher3/Thief2/Mage2 characters)
   
2. New characters start choosing from base classes; unlock new classes as they level up; may change into other classes a la Final Fantasy V, keeping levels. Class changes might be allowed in lieu of leveling up, but more likely will be allowed in safe locations. Or in the middle of a nest of spiders, but as it would take several hours it wouldn't be the most tactically-sound idea
3. New characters start choosing from classes unlocked in previous playthroughs, may add levels in anything ever unlocked

Because I'm weak, and can't make up my mind decisively about which'd be best, I'm thinking I'll have three different game modes. #1 will be Normal, #2 Alternate, #3 a sort of PowerMode just-for-fun type thing. Naturally, they'll all have their own high-score list, as converting the difficulty between them would be difficult and probably meaningless, or just straight up wrong.

In order to make things work across modes, I've thought of some (of what I feel are) interesting mechanics.

When you gain a level in one class, you get behind-the-scenes points in several categories. For example, instead of needing to be Fighter5 in order to access the Knight class, you need 5 points in the Warrior sphere, and every time you level Fighter you gain 1 point in it. This allows multi-class upper classes (like a Spellsword, Hunter, or Bard) in Mode2 (where you have no more than one class at a time), and greatly streamlines the unlocking of new classes (why can't a 200th level Fighter be a Paladin when a Fighter5/Knight10 can?).

Gaining new spells is something I'd like to have happen at each level. To this end, something similar to the class progression will be used. When you gain a level in a class, you gain percentage points in one or more skill disciplines, and when those points exceed a certain threshold, you can choose a new skill or two. For example, a Wizard would gain 115 Black Magic and 45 White Magic, where a Priest would recieve 150 White Magic. As you add skills in each discipline, the threshold increases and the number of skills available would increase (so newbie Mages can't pick ApocalypseIV as their level 1 spell, but could after mastering 24 other spells). I like the notion of picking your spells at regular intervals because it relies less on random chance than finding spellbooks. Never finding attack spells for a character would doubtlessly be intensely frustrating to most aspiring Wizards.