TRAVIO'S PROFILE

I make and play games - playing games I use as a reward for reaching specific milestones within my various development projects. I've played a wide variety of games, having started at the tender age of three and worked my way up over the years so that, at one point, I was actually going out of my way to find the original games (cartridges, CDs, whatever) to play.

All games I elect to review must be 'Complete' status (though games still in the process of clearing out bugs are fine and will be noted in the review itself). These games must have a download on RMN (as I pass them to my Dropbox queue) and need to be self contained - everything I need to play should be in the download, without needing to install anything (including RTPs; we aren't living in the days of slow connections anymore, people). You should also have any fixes in the download, not something I have to look through the comments for - I'm going to be avoiding them like the plague until I've finished the review.

When I review a game, I try to play as much of it as I can possibly stand before posting the review - I make notes/write part of the review as I'm playing, so a lot of what goes into the review is first impressions of sections. I'm also not a stickler - things don't have to be perfect - but I've seen many examples of things not done perfectly but, at the same time, not done horribly. I rate five categories on a scale from 1 to 10: Story, Graphics, Sound, Gameplay & Pacing, and Mapping & Design. 5 is average to me, so it's not necessarily saying that category is bad - it's saying it's middle of the road. Games within the same editor are compared to one another, not games across editors (I'm not going to hold an RM2k game to the same standards as a VX Ace game due to system limitations, but I won't let it hold back the RM2k game's rating) - unless the game is part of a series across multiple editors.
Legion Saga X - Episode ...
A fan updated version of the RPG Maker 2000 classic

Search

Filter

What's in a Name?

The way I'm doing it with LSX is to picture the world more as the real world - people pick names not necessarily from the culture and it sometimes looks a bit jarring side by side, but hey, the world's mixing together. That, added to the fact that there aren't actually these places in the game world (there's no Asia, no Far East, etc. etc.) gives a bit of wiggle room as well - the naming conventions are inspired by real world cultures, but they're not identical. (There's also bits and pieces of the custom languages of the world that fold into names, like Jugodin and such).

There's a number of towns and locations, just in Garalas and Meluvet, that have conflicting cultural names - Yamota Village sits next to the Murphey Forest, while Norita Hold lies just to the northeast of Bargon City. The reason these names mix together is because the world's mixed together - the cultures aren't necessarily separated and they've begun to mix in some places (especially the Midlands, which history in the game is indicating has been invaded and settled multiple times over the course of history). At the same time, I've got some segments where the region is clearly resisting any intruding names - for example, the new country of D'Alessio, where all the names are based in French and Italian stylings, and the indications of a small culture in the Mantis Wastelands (again, something new I'm adding).

It comes down to more whether the names make sense in the context of the game world cultures as opposed to whether they make sense in the context of the real world cultures. If it's commonplace for people to mix cultural styles in their names in the game, then it really shouldn't matter if they're mixed. But if there's one character, particularly a main character, named that way while no one else in his culture has that style of name mix, then you have a problem with the way the world is built - you either need to change the character's name to fit his culture or fold that naming convention into their culture as a whole.

Tutorials, learning and hand-holding

FF7 might have been a bad example, yes, but it's the first one that came to mind as I'd recently read some articles talking about it's implementation of an introduction.

Honestly, I understand what you're saying, but in a game using menus, short of hand-holding by greying out all the other options or making an impassable barrier without the use of a mechanic, you have to understand there's an inevitability that someone can defeat the tutorial encounter in another manner. The version of the example in FF4 and FF6 are much better done in this case - they're an impassable barrier, and I consider the Whelk the better of the two examples (if only because I can't recall the Mist Dragon encounter exactly off the top of my head). The game doesn't stop you from attacking the Whelk when it's in its shell, and it doesn't kill you outright if you fail to understand the mechanic (which, as Jude points out, is a good thing due to the wonkiness of that particular encounter).

Anyways, we've got kind of far from my original point - I was just trying to get across that a battle where a player is intended to use a particular mechanic to defeat it, and to learn how to use that mechanic in the meantime, doesn't have to be as simple as greying out everything else, especially if there's a more difficult way to fight the battle without it (and I know there's some players who would prefer that alternate, more difficult battle). And I'd prefer a battle where I was expected to use a mechanic/ability (ie the free choice battle method) as a tutorial over one where I was forced to use that mechanic to proceed (ie the greying out method).

Tutorials, learning and hand-holding

author=LockeZ
author=Travio
author=doomed2die
When you say something like "put the player in a position where he inevitably will use the newly acquired mechanic," how different is that really from "gray out all buttons except the desired one"? They ultimately serve the same purpose which is to essentially force the player to take the desired action.
I think the best way to do this is to put the player in a situation where that ability is useful but not necessary. For example - you just learned a shield against magic attacks. The next boss/whatever uses a lot of magic attacks - you can defeat the boss with some thought and work without using the shield, but the shield will make your life far easier. You don't have to use the shield to win, but it's useful in the situation as it keeps you from having to heal as often so you can focus on offense and shorten the battle.
I disagree. I have to really question the effectiveness of a tutorial that can be beaten without learning any of what you are supposed to learn.

I think the better way is probably what Crystalgate sort of suggested: make sure they learn how to do what you want them to learn how to do, but make sure there are also other things they have to do besides that. Learning how to stun enemies as they're charging up is all well and good, but it shouldn't be the only thing you are doing. You should still have to do all the same things you were doing before.

Also, just the simple fact that the game gives you a choice is important - even if there's a right choice and a wrong choice, having choices is the difference between cut scenes and gameplay. Plus, leading the player to understand why he picked the choice he did is the important thing, it's what you're trying to teach. And graying out everything else on the menu doesn't accomplish that. Making it really obvious that it's the right choice actually does accomplish it.


Short of being extremely punishing to the player, though, most, if not all, tutorials in an RPG have to be able to be beaten without learning the actual mechanic behind it. Otherwise you're not going to be able to teach them without frustrating them - let's use your charging up example.

The enemy charges up their attack - if you don't stun them, do they kill your party? Do they kill a member? When you're early enough in the game that you're still learning mechanics, either of those is both frustrating and possibly enough to make me put the game up (what if I happened to miss that little message that the enemy is charging this turn because it wasn't on the screen long enough or wasn't clear enough?). So the attack has to be survivable and, by that measure, you could potentially complete that battle without ever learning the mechanic and some players might just do that - and you should be ready, as a designer, for that as well. I'm not saying to make the resulting tutorial battle easy without the ability, but it's pretty much a necessity to make the tutorial able to be completed without learning the attached mechanic (in the sense of menu driven combat) unless you're greying out all the abilities except the one you want the player to use.

Using an actual example from a game, Final Fantasy VII - the first boss teaches you that hey, some guys will go into a mode and counterattack. You can still complete the boss even if you attack while they're in counterattack mode, it's just much more difficult - you don't have to ever technically learn that particular combat mechanic. The game doesn't go, "I won't let you attack because the guy will counterattack," it goes, "do what you want, but there's an easy way to do this." And that easy way is to learn the mechanic and complete the tutorial as designed.

Tutorials, learning and hand-holding

author=doomed2die
When you say something like "put the player in a position where he inevitably will use the newly acquired mechanic," how different is that really from "gray out all buttons except the desired one"? They ultimately serve the same purpose which is to essentially force the player to take the desired action.


I think the best way to do this is to put the player in a situation where that ability is useful but not necessary. For example - you just learned a shield against magic attacks. The next boss/whatever uses a lot of magic attacks - you can defeat the boss with some thought and work without using the shield, but the shield will make your life far easier. You don't have to use the shield to win, but it's useful in the situation as it keeps you from having to heal as often so you can focus on offense and shorten the battle.

Whatchu Workin' On? Tell us!

Working rather intently on redoing RMXP's default battle system and menus ~ I'm trying to get around a number of the default limitations to do what I want to do. This is all being doing while I'm waiting to hear back from some individuals about permission to use certain resources. And then, once I hear back about the permissions, I'll be able to roll out a game page for the current project.