Nice to meet you; a proper introduction.

ID:152168
 
Nov 24 2007, 7:44 am
I've come across a small dilemma during the production of my new game.

Although the basics are rather simple, to fit into roleplay it takes a few dozen words to explain it all to the player. Unfortunately, with my current set up it becomes slightly hard to follow the speech.

Free Image Hosting at www.ImageShack.us

As you can see there is a fair amount of text on the right. And that's not even all of it. It is shown to the player piece by piece, each part starting with "[Name of mob] :" - Also in real-time with the game running that same output box is likely to be filled with Out Of Character Talk.

I find it easy enough to follow, as I'm the author and I know it almost word for word without even looking at it, but I can tell that it is likely to scare off a few potential players.

There are several other ways of giving the instructions to new players, but which do you find most effective?

~Ease~
Nov 24 2007, 7:59 am
You could have a separate output for stuff other than the equipment or communication.
Nov 24 2007, 8:02 am
In response to Kaiochao2536
But the screen is already fairly packed. It might just be because my screen is only 15.4", but I know a few other users also use relatively small laptop screens, so I don't want to discriminate against laptop users.

~Ease~
Nov 24 2007, 8:28 am
Yes, you could have alerted to the player
mob/NPC
 verb/Talk()
  set src in oview(1)
    alert("HELLO")

Or, if they may want this info again make a help verb and have it alert them again
mob/verb/Help()
 alert("HELLO")

It is a good rule of thumb to keep NPC instructions out of the default output box.
Nov 24 2007, 10:04 am
I tend to make the tutorial interactive, so it doesn't overwhelm the player. Follow an index of a help guide that you've written for the game, and have the NPC recite it to the player piece by piece -- perhaps have the player try out the information given in that section as well.


<code> NPC Guide says 'Welcome to [game]! I'm [whoever], and I'm here to show you around! You can let me know whenever you're ready to continue by saying "continue", or leave this tutorial by saying "done"!' Newbie says 'continue' NPC Guide says 'Section 1: Movement' NPC Guide says 'Movement is essential in this game! You move around you just have to [explain the movement system].' Newbie says 'continue' NPC Guide says 'Section 2: Items' NPC Guide says '[insert instruction here]' Newbie says 'done' NPC Guide says 'Are you sure you wish to leave the tutorial area?' Newbie says 'yes' </code>

This will give the player time to try out what they're learning before being bombarded by a ton of text. Too much text at one time is overwhelming, and often is very discouraging to new players.
Nov 24 2007, 10:28 am
In response to Ease
You could make the output be longer horizontally instead of vertically, since they are talking a whole lot. There's a big empty space on the bottom(the light bluish space?) where you can put it, unless that's an input or something.

Also, you could clear the output before you talk to an NPC, so only one NPC's dialogue shows up.

usr<<output(null,"npcoutput")

I think that's how it's done.
Nov 24 2007, 11:05 am
In response to Lt. Pain
Okay, I've brought the majority of it up to 'alert' boxes, and moved some to a browser. Now for help files, faq's, e.t.c I can use the browser as well, so it serves more than one purpose.

Free Image Hosting at www.ImageShack.us

What do you think of the set up? Annoyingly I could get the exact HTML colour code for the browser to match the output.

~Ease~
Nov 24 2007, 11:46 am
Uhg, not alerts. XP Use a heads-up display for NPC output, and as many visual cues as possible. Instead of telling the player in words where to find skills, highlight it graphically when skills are mentioned by the NPC. Leave the text output for non-NPC communitcation.
Nov 24 2007, 2:22 pm
If your game is decent enough, I'll just ignore all the text anyways and just learn as I go. To be honest, I never saw the Dragonball series as a very role playing genre.
Nov 24 2007, 3:53 pm
If you want to make your game look well on the eyes, do not use those type of alert boxes. They look disgusting and take away from the feel of the game. Try downloading one of the many output box demos/libraries that are around the website. With them, you can change the colors of the output box/text so they match the layout of your games interface. It will look so much better.

By the way, I really like your art style.
Nov 25 2007, 2:11 am
In response to Cavern
Oh ok. Yer, I never really liked how the alert boxes looked, but didn't really think about looking for a demo/lib. Will do so now!

Thank you for the comment on my art; I've tried to go for an almost cel-like appearance with moving objects, by using dark outlines and few colours.

Note; The base player was created by Zeburius.

~Ease~
Nov 25 2007, 2:12 am
In response to Xooxer
By Head's Up you mean those little (usually black) boxes that pop up at the bottom and scroll (usually white) words on, word by word? Would that fit in as I already have a HUD in the bottom left? Also, I always got the impression that that kind of output came with a bucket load of lag?

~Ease~
Nov 25 2007, 3:46 am
In response to Ease
If you're sending info to a browser anyway then why make pop-ups at all? Just call Topic() through a link in the browser. It will keep the entire tutorial together.
Nov 25 2007, 4:04 am
In the game I am making I use several output boxes that a player can toggle between. The default box shows all text, chat and happenings. That can be toggled to show only player chat, NPC chat, both of those or actions/game messages (such as "You picked up a [item].")
It is simple enough to do and it works. My method of doing it is probably not the best though. I have 5 output boxes at the same place in an interface, only one is visible at a time. A macro is used to toggle between visible windows. When I output any text I use a function that outputs the text to the appropriate output boxes, which in some cases can mean a single line of text is being output to 3 different things. Which is why I say it is probably not the best method of doing it.
Nov 25 2007, 5:58 am
In response to ACWraith
ACWraith wrote:
If you're sending info to a browser anyway then why make pop-ups at all? Just call Topic() through a link in the browser. It will keep the entire tutorial together.


I was going to tell him that also, but I realized that I hate that as well. For some reason it annoys me, but it can also be good seeing as how you can go back and read up on it again in case you ever forgot anything.
Nov 25 2007, 10:42 am
In response to ACWraith
My thoughts behind the pop-ups were that they wouldn't go away without being clicked on, so it increased the chances that the players read the rules rather than bugging existing players for them.

~Ease~
Nov 26 2007, 12:33 am
In response to Ease
As far as I know, the HUD lag people claim is complete rubbish.

And, just your standard RPG dialog boxes would work. There should be a number of demos and libs for making them. It's basically just a pop-up window with text directly on the map.
Nov 26 2007, 1:07 am
In response to Xooxer
Xooxer wrote:
As far as I know, the HUD lag people claim is complete rubbish.


Not quite, screen objects are known for generating a lot of overhead, especially if they're being updated rapidly. Every time you update one screen object everything in client.screen is resent to the client.
Nov 26 2007, 2:31 pm
In response to Nadrew
I still call BS on it. I've never experienced it, and I know of no one who has convincingly proven it. From what I've seen, it's just a cheap scapegoat for a bad connection, or lack of skill in the game. It's the same with people claiming others hack because they themselves do not possess any skills whatsoever. People also retell it because they really beleieve it's true, because they heard someone else say it. Popularity does not equate reality.

Until there is some definitive evidence that HUD systems cause client lag, I'm calling BS.

~X
Dec 3 2007, 1:47 pm
In response to Xooxer
Nadrew is correct, though; the client does do a full refresh on any HUD update. Lummox JR was looking for a way to solve that. (Dan probably envisioned HUDs as little glitzy things that would rarely if ever update except in constricted, manageable ways.)

With each object on your HUD that you update, you exponentiate the amount of interaction between you and the server, which will certainly produce lag on the client's end (and on the server's end as well).

This is conjecture, but for instance, if you have 1 object on your HUD and you update that object, it transmits the object to the client. If you have 3 objects on your HUD and you update each of those 3 objects, it transmits each of those three objects each of the three times, for a total of 9 updates. If you litter your HUD with tons of useless crud, it's going to pinch very hard any time you update that HUD.

Naturally, of course, I suspect a lot more of the lag is server-side from poor programming habits, and also suspect that you're hitting onto the issue pretty well. I know I heard people complaining out of their back ends about the HUD lagging them up on Lode Wars, and this was usually when their teams were dying a slow, horrible death.