Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
WHAT SHOULD GO INTO A MANUAL?
Posts
Pages:
1
Feo_Takahari
View playlists
CloseSome of the things I can think of:
* Game mechanics (must be redundant to things explained in-game)
* Setting and timeline information
* Character bios
* Known bugs
* More detailed credits
What else should go into a manual?
* Game mechanics (must be redundant to things explained in-game)
* Setting and timeline information
* Character bios
* Known bugs
* More detailed credits
What else should go into a manual?
Dyhalto
7536
Concept Art!
Assuming you're going for a genuine manual look, and not simply a txt file.
Assuming you're going for a genuine manual look, and not simply a txt file.
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
Known bugs should be fixed; other things should be in the game instead.
The only thing in your manual should be an error message saying "Error: File Manual.hlp was not found."
The last game I bought that had a manual was over five years ago. It has become generally accepted that when people get a new piece of software, they want to use it, not read about it, and so everything that used to be in game manuals is now in the games themselves instead.
The only thing in your manual should be an error message saying "Error: File Manual.hlp was not found."
The last game I bought that had a manual was over five years ago. It has become generally accepted that when people get a new piece of software, they want to use it, not read about it, and so everything that used to be in game manuals is now in the games themselves instead.
@LockeZ: The manual is your fallback for when you screwed up designing the game. For instance, I've played more than one video game in which the tutorial wouldn't proceed until I inputted a specific command, and the in-game instructions were insufficient to input that command properly. In a case where the manual contains an alternate explanation of the command, I can proceed (or, if all else fails, skip the tutorial and learn everything else from the manual--if the mechanic is that hard to do, I probably won't ever need to use it in actual gameplay.)
In addition, the manual is where you store information so that the player can look it up again if they've forgotten it. Strictly speaking, you should design your games such that no information should go unused long enough to be forgotten, but I've had to look up these things more than once, and I don't like to replay the tutorial from the beginning (or, Heaven forbid, play the entire game from the beginning if it's the sort of game that spaces out its tutorial across the entirety of gameplay.)
In addition, the manual is where you store information that has no purpose in the game. For instance, there's no reason to provide the phonetic pronunciation of names in my game, but some players may find that interesting, so I mention the phonetics in the manual.
In addition, the manual is where I'm putting information on what scripts I'm using in the game. If someone else wants to do the same things I'm doing, they can look at the manual and see exactly what scripts they'll require.
Whatever the manual it is, it is not useless. (And besides, I like owning and reading them, and I'm disappointed whenever a game doesn't have one.)
P.S. And one of the first things I learned in programming classes is that there's no way to fix every bug. Sometimes you can't even reproduce the bug, and you have no idea whether it will show up for anyone else. Nonetheless, it's better to document it than to not document it.
In addition, the manual is where you store information so that the player can look it up again if they've forgotten it. Strictly speaking, you should design your games such that no information should go unused long enough to be forgotten, but I've had to look up these things more than once, and I don't like to replay the tutorial from the beginning (or, Heaven forbid, play the entire game from the beginning if it's the sort of game that spaces out its tutorial across the entirety of gameplay.)
In addition, the manual is where you store information that has no purpose in the game. For instance, there's no reason to provide the phonetic pronunciation of names in my game, but some players may find that interesting, so I mention the phonetics in the manual.
In addition, the manual is where I'm putting information on what scripts I'm using in the game. If someone else wants to do the same things I'm doing, they can look at the manual and see exactly what scripts they'll require.
Whatever the manual it is, it is not useless. (And besides, I like owning and reading them, and I'm disappointed whenever a game doesn't have one.)
P.S. And one of the first things I learned in programming classes is that there's no way to fix every bug. Sometimes you can't even reproduce the bug, and you have no idea whether it will show up for anyone else. Nonetheless, it's better to document it than to not document it.
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
I'm just saying, every single game in the past five years has done perfectly fine without any of that crap. So clearly it's not necessary.
And I think it does more harm than good - if your design decisions depend on people having access to the manual, they're bad decisions, because the overwhelming majority of players will probably quit playing the game rather than open it. I think a lot of people actually resent instruction manuals because they say to the player, "Stop playing this game and go read a book for half an hour and then come back." Which sounds like something my mom would say.
Your first point doesn't even make sense to me. You want to add a manual because you plan on screwing up your game? Maybe try... not screwing it up? It's not hard, since I've in my life even heard of a tutorial that was too complicated to complete without reading the manual. I have a hard time even imagining that it's possible, honestly; I'd think you'd have to go way out of your way to design a tutorial like that on purpose.
OK, never mind, I just remembered Final Fantasy Tactics. Fuck. But that tutorial wasn't even interactive. It was just two solid hours of horribly mistranslated explanations. Holy shit, if you don't remember the tutorial in FFT, turn on the original PSX version and check it out. Not many games back then had a proper tutorial mode at all, and the game is crazy complicated to figure out, so props to Squaresoft for the effort, I guess? But tutorials written in broken english are far worse than dialogue written in broken english.
If you're using the manual as a repository for stupid crap like mythological history of the world and character bios with height and weight, then... I wouldn't really call that a manual, but that's often where it gets crammed so I see where you're coming from. There have been times I wanted to read that stuff, I admit. The typical method of including this stuff in the game is a datalog or encyclopedia that you can access from the main menu (or from some other place in the game). Which is nice because on the off-chance you care about that stuff, you don't have to put the game down to read about it. And you can make the info unlock gradually as the player plays the game; acquire a new character and their info becomes viewable. I actually really like the gradual unlocking - it makes the info a lot less overwhelming to sift through.
And I think it does more harm than good - if your design decisions depend on people having access to the manual, they're bad decisions, because the overwhelming majority of players will probably quit playing the game rather than open it. I think a lot of people actually resent instruction manuals because they say to the player, "Stop playing this game and go read a book for half an hour and then come back." Which sounds like something my mom would say.
Your first point doesn't even make sense to me. You want to add a manual because you plan on screwing up your game? Maybe try... not screwing it up? It's not hard, since I've in my life even heard of a tutorial that was too complicated to complete without reading the manual. I have a hard time even imagining that it's possible, honestly; I'd think you'd have to go way out of your way to design a tutorial like that on purpose.
OK, never mind, I just remembered Final Fantasy Tactics. Fuck. But that tutorial wasn't even interactive. It was just two solid hours of horribly mistranslated explanations. Holy shit, if you don't remember the tutorial in FFT, turn on the original PSX version and check it out. Not many games back then had a proper tutorial mode at all, and the game is crazy complicated to figure out, so props to Squaresoft for the effort, I guess? But tutorials written in broken english are far worse than dialogue written in broken english.
If you're using the manual as a repository for stupid crap like mythological history of the world and character bios with height and weight, then... I wouldn't really call that a manual, but that's often where it gets crammed so I see where you're coming from. There have been times I wanted to read that stuff, I admit. The typical method of including this stuff in the game is a datalog or encyclopedia that you can access from the main menu (or from some other place in the game). Which is nice because on the off-chance you care about that stuff, you don't have to put the game down to read about it. And you can make the info unlock gradually as the player plays the game; acquire a new character and their info becomes viewable. I actually really like the gradual unlocking - it makes the info a lot less overwhelming to sift through.
I love reading manuals, but that might just be me. I get excited when I get a new game and I always open up the manual first to see what I'm getting into. The cover and screens don't really say much but once you open up the manual you get a good idea of what it's really about.
I don't want to derail this too much into whether games need manuals, but two examples of what I'm thinking of are the climbing controls in Second Sight (which I determined through the more detailed instructions in the manual, having been confused by the in-game instructions) and the lockpicking minigame in Thief 3 (which I didn't have a manual for, and which took me half an hour of trial and error to figure out.) Both of those are well-regarded games, and if those devs screwed up that badly, I don't have much hope that all of my in-game documentation will be up to snuff, particularly if I maintain the keep-it-simple-stupid, learn-by-doing style that you're supposed to use for in-game tutorials.
Then again, it sounds like part of what LockeZ is talking about is the idea of having the "manual" available inside the game--for instance, I should have been able to access that information on climbing controls from the main menu. This is a good approach to things, and the only reason I'm not doing it now is that I think I'd need another script to add that to the main menu, and I'm already dealing with way too many scripts at once for my first project.
Then again, it sounds like part of what LockeZ is talking about is the idea of having the "manual" available inside the game--for instance, I should have been able to access that information on climbing controls from the main menu. This is a good approach to things, and the only reason I'm not doing it now is that I think I'd need another script to add that to the main menu, and I'm already dealing with way too many scripts at once for my first project.
eplipswich
2728
author=Allen HunterThis is exactly how a manual should be.
If I were to design a manual for my own game, I'd include the following:
- Instructions on installing/setting up the game
- Brief info on the plot (so the player gets a good grasp of what he's getting into)
- Character bios (again, keeping them brief)
- Locations
- Controls and their functions in both field mode and battle mode
- How to use a "special ability/skill system"
- Contact info
And regarding "known bugs", nobody really wants "known bugs" in a manual, really. Not for me, anyway. To be frank, if I see a title in a manual called "known bugs", it would actually kind of dissuades me from playing a game, because it's a game riddled with bugs. Bugs should be minimized as much as possible. Having a section "known bugs" with many bugs added into the section only dissuades players from playing the game. It's probably acceptable if you put "known bugs" in a manual of a demo, but if it's a full game, that's highly not recommended. Goes to show you're not ready to release the game in full at all.
Manuals should be kept as simple as they are, and what Allen Hunter has stated is good enough of a manual.
author=SorceressKyrsty
I love reading manuals, but that might just be me. I get excited when I get a new game and I always open up the manual first to see what I'm getting into. The cover and screens don't really say much but once you open up the manual you get a good idea of what it's really about.
I loved manuals and the extra shit you'd get with games like maps so much. Way back I'd always read the manual before the game, usually on the way home from renting/buying the game. I can't even really say why; Maybe it was that manuals would build expectations of what is to come or help set the tone of the game or maybe it's just silly nostalgia. I wish they didn't die out except in the occasional overpriced collector's edition.
My suggestion is to do some research on old game manuals. Go to Replacement Docs and go check out some NES or SNES manuals and see what you like and what you don't like. I don't remember, it's been so long... in fact I should read some just for fun...
(edit: I was responding to eplipswich)
^ And that's probably why commercial game publishers don't put "known bugs" in their manuals. It doesn't help things from a marketing standpoint. That doesn't mean it doesn't serve a purpose.
When possible, I think it's better to have an online system for tracking bugs so users can report them, as is done on SourceForge. Pick any random project on SourceForge and you will find a list of known bugs, in some cases a very long list. Bugs are a reality of programming, like the OP said. Any project that doesn't have bugs is either made by godlike programmers, or (more likely) is not all that interesting or complex. As a player, there is a point at which the cost of bug saturation for the tradeoff of complexity becomes worthwhile to me. Skyrim, for instance.
A manual is also a logical place to put troubleshooting stuff like what to do when the user can't get the game to run on their system.
^ And that's probably why commercial game publishers don't put "known bugs" in their manuals. It doesn't help things from a marketing standpoint. That doesn't mean it doesn't serve a purpose.
When possible, I think it's better to have an online system for tracking bugs so users can report them, as is done on SourceForge. Pick any random project on SourceForge and you will find a list of known bugs, in some cases a very long list. Bugs are a reality of programming, like the OP said. Any project that doesn't have bugs is either made by godlike programmers, or (more likely) is not all that interesting or complex. As a player, there is a point at which the cost of bug saturation for the tradeoff of complexity becomes worthwhile to me. Skyrim, for instance.
A manual is also a logical place to put troubleshooting stuff like what to do when the user can't get the game to run on their system.
In the manuals I've made that nobody reads, I have a section called "Bug Check!". It's a change-log, of sorts, as it keeps track of what I've done to the game. However, it also keeps track of what bugs have been squashed. If there is a "known bug" in a game, I'd put a notation of it in the "Bug Check!" section.
Shinan
4314
I guess it kinda depends on the kind of manual it wants to be. If it's an actual paper manual you should cram in loads of fun extras if it's just a PDF or other file on your computer it doesn't really need any of that.
Manuals are best when they're paper really because they should kind of act as reference sheets on one hand. While you're playing you might want to look up something. Though it often should be in some menu somewhere as well it's not bad to have it beside you as well.
The other thing a paper manual should be is basically toilet reading. Designer notes, maybe a a fluffy short story or two to get in the mood of the game. Or... You know... Pancake recipies.
Of course if you can't do a paper manual (you're unlikely to make one really) designer notes and other fluff should probably go on your homepage/blog.
Known bugs/issues should probably be in the patch notes parts.
Manuals are best when they're paper really because they should kind of act as reference sheets on one hand. While you're playing you might want to look up something. Though it often should be in some menu somewhere as well it's not bad to have it beside you as well.
The other thing a paper manual should be is basically toilet reading. Designer notes, maybe a a fluffy short story or two to get in the mood of the game. Or... You know... Pancake recipies.
Of course if you can't do a paper manual (you're unlikely to make one really) designer notes and other fluff should probably go on your homepage/blog.
Known bugs/issues should probably be in the patch notes parts.
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
author=Feo_Takahari
Then again, it sounds like part of what LockeZ is talking about is the idea of having the "manual" available inside the game
Yeah, this is a good way of thinking about it. I guess it's really still a manual, it's just accessed inside the game. The same things should be there whether it's a menu option or a seperate document; if it's a menu option you just have have more control over when the player gets to read them, and can animate the visual examples if you need to.
I agree that known bugs/issues shouldn't be in the manual. If you want to make them availble, put them in a help & support section of your game page on RMN (or on whatever website your game is on). They shouldn't be in a place that the player might see before they play the game, or just as they're starting, because it's an extremely bad first impression.
Darken
3952
just image dump some monster art and give random tips with starting phrases like HERE'S THE TRUE ADVICE FROM THE UNDERWORLD
Darkflamewolf
2178
My manual for Amulet of Fate is ridiculously in-depth. But it is, in no way, required for you to read it. But for those players who REALLY want to get into the game, they will have a field day with my document manual which includes no less than:
- Character Bios
- Sub Menu explanation
- Status Effects and Cures
- Descriptions of the Mercenary, Magic, Weapon, Esper, Augment Card, Money Earning systems, etc.
- Brief Side-quest description section
- Game Tips (from the creator)
- Appendices which include:
* Skill lists
* Sphere magic
* Item/Weapon/Armor Lists
* Shop Lists
* Trophy List and explanation
- Full blown Bestiary document with information like weaknesses/strengths, item drops, attacks, augment card ability, blue magic abilities, alchemy ingredient drops, and stat data for all 3 levels for every monster
I even include a passworded document (to be opened after beating the game once) that has step-by-step explanations on accomplishing all 68 Side quests in the game with the possible reward load-out you'd get by completing each.
So yeah...I have a CRAP TON of information for players if they so choose to delve deep into my game. Do you have to? Absolutely not! But it'll be an amazing boon for players wanting more from the game. I'm more of an exception than the norm however...lol
- Character Bios
- Sub Menu explanation
- Status Effects and Cures
- Descriptions of the Mercenary, Magic, Weapon, Esper, Augment Card, Money Earning systems, etc.
- Brief Side-quest description section
- Game Tips (from the creator)
- Appendices which include:
* Skill lists
* Sphere magic
* Item/Weapon/Armor Lists
* Shop Lists
* Trophy List and explanation
- Full blown Bestiary document with information like weaknesses/strengths, item drops, attacks, augment card ability, blue magic abilities, alchemy ingredient drops, and stat data for all 3 levels for every monster
I even include a passworded document (to be opened after beating the game once) that has step-by-step explanations on accomplishing all 68 Side quests in the game with the possible reward load-out you'd get by completing each.
So yeah...I have a CRAP TON of information for players if they so choose to delve deep into my game. Do you have to? Absolutely not! But it'll be an amazing boon for players wanting more from the game. I'm more of an exception than the norm however...lol
Pages:
1
