"Roguelike of the Month" with Gamer_2k4
Gamer_2k4
We've got promises of BasinRL, roguelikes for mobile devices, and
probably 20 7DRLs. With that in mind, it's time to introduce my
roguelike of the month: One Handed Roguelike, or 1HRL. The idea is
that the user interface can be simplified far enough that the game can
be played using only the number pad. Obviously this concept is
required for games on cell phones and handheld game players, but since
I haven't played any of those, I'm going to assume that they lack both
features and content.
You may remember that I introduced an innovative means of selecting in
the thread "Roguelike Interface":
http://groups.google.com/group/rec.games.roguelike.development/tree/browse_frm/thread/e37eff57031d18df/5110a354ecc2b893?rnum=31&_done=%2Fgroup%2Frec.games.roguelike.development%2Fbrowse_frm%2Fthread%2Fe37eff57031d18df%2F%3F#doc_5110a354ecc2b893
This feature will be used extensively to prevent tedious scrolling
through long lists of options. To that end, every list will have to be
able to be divided into a small amount of small, specific groups. I
know what you're thinking: "Small amounts of small groups? Doesn't
that translate into a small amount of total options?" Yes, it does.
But I'm going to test this concept in a 7DRL this upcoming March, and I
don't need a lot of options right now. Anyway, here are some lists and
how they'll be broken down. Remember, there can only be 64 total
options for each list (which is still larger than a Nethack or Angband
inventory).
Inventory:
-Head
-Body
-Legs
-Shield
-Weapon
-Potion
-Wand
-Amulet
Inventory Actions:
-Wear
-Remove
-Drop
-Use
Magic:
-Heat
-Cold
-Light
-Dark
-Mind
-Body
-Earth
-Air
Action:
-Open
-Close
-Get Item
The Action menu will be brought up by pressing Num0. Other commands:
/: Display equipped items
*: Cast spell
-: Use skill
+:Display inventory
.: Look at a monster
Num5: Rest
Other numbers: move or select
Num0 will exit any menu that is currently up.
Combat will be simple: attacks deal damage to the player, and more
damage will be altered based on hit location.
Head: 10% hit chance, 200% damage
Body: 50% hit chance, 100% damage
Legs: 40% hit chance, 80% damage
Armor reduces damage by a certain percent and a shield has a chance of
negating an attack entirely. Weapons do a certain amount of damage
(almost static, 8-10 for example) and have a certain chance of hitting.
Potions affect the player; wands affect the environment. Food is not
required.
I think that's basically everything. Any questions?
Gamer_2k4
Pointless
Can you make it compatible with the regular number keys and the vi
keys, also? Since it's a 1HRL, there's no reason not to implement it
for other systems, right?
the reason I ask is that I've noticed that the number keys on my laptop
don't work in your games. I play roguelikes on my laptop, and I have
mastered the use of both the vi keyset and using the numbers to move
(yes, that row of number above the alphabetical keys). To play your
games, I have to hold down a different key called the 'Fn' key and
fumble around on the keyboard using secondary keys that are marked with
very dark letters and are hard to find.
The benefit of your ingenuity would be undercut dramatically if it cut
out an audience of players based on their machines.
Good luck on your game.
Gamer_2k4
> don't work in your games. I play roguelikes on my laptop, and I have
> mastered the use of both the vi keyset and using the numbers to move
> (yes, that row of number above the alphabetical keys). To play your
> games, I have to hold down a different key called the 'Fn' key and
> fumble around on the keyboard using secondary keys that are marked with
> very dark letters and are hard to find.
I have a similar problem on my laptop too. Oddly enough, the keys
don't work when you hold Fn and the number, but they do if you turn on
numlock (near the print screen key on my laptop). But yes, I can make
0-9 do the same thing. The other commands (/, *, etc.) won't be as
intuitive though, since this is designed around the number pad and its
specific arrangement.
Gamer_2k4
R. Dan Henry
>With that in mind, it's time to introduce my
>roguelike of the month: One Handed Roguelike, or 1HRL.
I appreciate your idea, but really, this name needs to be saved for an
"adult" roguelike.
--
R. Dan Henry = danh...@inreach.com
If you wish to put anything I post on your website,
please be polite enough to ask first.
Radomir 'The Sheep' Dopieralski
R Dan Henry wrote:
> On 5 Jan 2007 14:53:15 -0800, "Gamer_2k4" <game...@gmail.com> wrote:
>>With that in mind, it's time to introduce my
>>roguelike of the month: One Handed Roguelike, or 1HRL.
> I appreciate your idea, but really, this name needs to be saved for an
> "adult" roguelike.
I have an idea for one! Listen to this, maybe it gets implemented as
a 7drl or even something bigger. Warning, disturbing imagery ahead.
You are a teenage girl on a summer camp. One night you saw some UFO
landed in the forest nearby, and short after that all the people around
you have been turned into several kinds of sex-crazied monsters. They
attack you rying to rip your clothes from you and impregnate with the
alien seed, which would turn you into a mnster too. You need to run away.
You have no weapons and no experience in fighting. Actually, you'd be
totally defensless if not one small fact about the monsters -- what keeps
them in their monster form is their amplified lust -- they are actually
so excited, that some amount of additional, hm..., stimulus will make
them simply get a nose bleed and faint -- turning into normal, albeit
uncoscious, humans.
So all you have is the clothes you have on you and various garments and
other objects scattered by the people who got transformed. And of course
your body.
Depending on what your wear and carry at the moment, you can perform
special "attacks", like sending a kiss, flipping your skirt, flashing
your breasts, shaking your butt, or even, for monsters with specific
monstrous tastes, kicking, stepping or whipping.
There are no hit points -- instead monsters will tear your clothes as
they attack you. Once they get you naked -- you're as good as dead. Of
course destroying of particular parts of your clothes can have an effect
similar to your special attacks on the monsters -- but usually weaker.
Now, the different kinds of monsters have different kinds of attacks and
movement patterns. They also have different tastes -- some prefer
underwear, others get turned on by naked body, some will prefer some
additional kink, and some of them even like pain. Your attacks also have
different stregths in all of those "flavors", depending on what you're
wearing at the moment.
Yeah, I know, this is silly. But it's supposed to have tentacle
monsters... :]~~
--
Radomir `The Sheep' Dopieralski
Besides a mathematical inclination, an exceptionally good mastery of one's
native tongue is the most vital asset of a competent programmer. [Dijkstra]
Gamer_2k4
> >roguelike of the month: One Handed Roguelike, or 1HRL.
>
> I appreciate your idea, but really, this name needs to be saved for an
> "adult" roguelike.
*sigh*
EVERY single person who I've mentioned this to said the EXACT SAME
THING. Everyone. It's supposed to be about effective UIs, not, shall
we say, "multi-tasking". Maybe I'll rename this NumPadRL or
InterfaceRL or something, but you have to admit, 1HRL is a really good
acronym.
Gamer_2k4
Kornel Kisielewicz
> Yeah, I know, this is silly. But it's supposed to have tentacle
> monsters... :]~~
HentaiRL? ^_^
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"Girls are good teachers, even though they don't know a thing
about roguelikes" - Igor Savin
Icey
> 1HRL is a really good acronym.
Hmmm. If I saw that, I'd think: "One Hour Roguelike".
Anyway. A one handed roguelike. I think this is interesting. Performing
actions would be quick and it would be easy to learn. Also, the number
pad is in a nice square layout, rather than the unaligned letters.
Why are you limiting the system to 8 or multiples of 8 though? Why not
use Num 5? Is it so the player can always see their character? If so,
that sounds sensible.
I was thinking of the possible problems that might occur with using
this on a roguelike:
1. Characters names.
This requires letters. There could be a randomly generated name given
and the user would simply press Num Enter to accept that. They could
specify a name if they wanted to (using the evil letters) or generate
another random name (using a key on the number pad).
2. Using stairs.
You don't mention a key for that. Maybe Number Pad Enter would work
alright? Could be thought of as "Enter another area".
3. Merchants.
How would they be handled? I can think of two ways:
A. We present a numbered list to the user and they type the number of
the item they want to buy. Double digits are fine. Kinda like selecting
a TV channel.
Good things about this are that we can show the whole list to the
player and the amount of items available is only limited by the amount
of numbers there are.
Bad things are that there might be a slight delay, because when the
user presses 1, we need to make sure they want 1 and aren't going to
press 3 to selected 13 instead.
B. We present a radial menu to the user and maybe show the amount of
items available in each section. So we have Head (2), Arms (4), etc.
The user might selected Number Pad 1 for Head and then be shown a
couple of shiny helmets. They then press the number for the option they
want or they press Number Pad 0 to return to the previous menu.
Good thing about this is that there's no delay.
Bad thing is that it takes longer to go through the menu to see what's
available.
4. Inventory.
Am I right in thinking we want a system where the user presses a key to
bring up the inventory category menu (Weapons, Armour, Shields, etc)
and then presses another key to select an individual item (Lipstick,
Makeup, etc) and then presses another key to select an action (Drop,
Sell, Apply, Examine, etc)? I rather like that system.
This doesn't really limit the inventory to 64 items. It limits it to a
maximum of 8 items in a maximum of 8 categories. For example, it's not
possible to have 12 potions and 4 helmets. However, I think in the
majority of cases (Armour, Shields, etc) this is a good thing, because
no character could carry around more than eight of those.
I think it would be best to keep items in the same location, even when
the number of items in a category changes. For example, let's say the
user picks up four potions:
1. Red Potion
2. Blue Potion
3. Orange Potion
4. Black Potion
They drink potion 3. To keep things consistent and familiar with the
previous layout, I think it would be best if it now looked like this:
1. Red Potion
2. Blue Potion
4. Black Potion
If they come along later and pick up a Pink Potion, we can reuse slot
3. Like so:
1. Red Potion
2. Blue Potion
3. Pink Potion
4. Black Potion
5. Game actions.
Such as quit, start new game, character info etc. There doesn't seem to
be any keys left to bring up a menu with those things. My solution
would be to remove resting and then modify the system slightly:
- :Skills
+ :Display equipped
/ :Game menu
* :Spells
. :Look
Num 5 :Inventory
Num 0 :Cancel menu
Other numbers :Movement / Radial Menus
Enter :Stairs / Confirming
If Skills were used more than Inventory, I'd swap them round, because
Num 5 is very easy to access.
7. Spell targetting
This seems straight forward. Center target on the last creature, or if
there isn't one, center on the nearest target. Use the numbers to move
around. + switches between visible targets. - goes to the nearest
target. Num 5 could center on the player. Enter confirms the square to
target.
(end of numbered paragraphs)
I'll stop rambling now.
Basically, I think this is a great idea. The only major problems I can
see is that (afaik) laptops don't have a number pad. Is there a
solution to that problem? I don't know much about laptop keyboards.
It would also be possible to do a roguelike that's controlled entirely
by the mouse, but I think moving with the mouse would get very annoying
very quickly. So the keyboard is better.
I'll be insulting your February "Roguelike of the Month" idea, so that
you make this idea instead :)
Gamer_2k4
> use Num 5? Is it so the player can always see their character? If so,
> that sounds sensible.
That's the reason. The player will have a 9x17 window to see his
surroundings.
> I was thinking of the possible problems that might occur with using
> this on a roguelike:
>
> 1. Characters names.
>
> This requires letters. There could be a randomly generated name given
> and the user would simply press Num Enter to accept that. They could
> specify a name if they wanted to (using the evil letters) or generate
> another random name (using a key on the number pad).
It would be awkward, to say the least. Numlock could be used, giving
you 22 choices right away (number/direction and ./Del). That leaves 4
keys (/, *. - +) and Enter. Twenty-six choices and a confirming
button. I guess it does work. ;)
> 2. Using stairs.
>
> You don't mention a key for that. Maybe Number Pad Enter would work
> alright? Could be thought of as "Enter another area".
I probably wasn't very specific there. Num0 or Enter would be the
generic action key: If there are stairs, you'll use them; if there's an
item, you'll pick it up; if there's a single adjacent open door, you'll
close it. If you can perform more than one action, the radial menu
will pop up. Obviously actions will have static positions in this
menu. (8 might always be Use Stairs, 2 might always be Get, etc.)
> 3. Merchants.
>
> How would they be handled? I can think of two ways:
>
> A. We present a numbered list to the user and they type the number of
> the item they want to buy. Double digits are fine. Kinda like selecting
> a TV channel.
>
> Good things about this are that we can show the whole list to the
> player and the amount of items available is only limited by the amount
> of numbers there are.
>
> Bad things are that there might be a slight delay, because when the
> user presses 1, we need to make sure they want 1 and aren't going to
> press 3 to selected 13 instead.
>
> B. We present a radial menu to the user and maybe show the amount of
> items available in each section. So we have Head (2), Arms (4), etc.
> The user might selected Number Pad 1 for Head and then be shown a
> couple of shiny helmets. They then press the number for the option they
> want or they press Number Pad 0 to return to the previous menu.
>
> Good thing about this is that there's no delay.
>
> Bad thing is that it takes longer to go through the menu to see what's
> available.
I didn't even consider merchants. One solution would be to have each
merchant only sell a few items, but have several merchants (sort of
like the ratlings in ADOM). The better solution would probably be the
Nethack/ADOM style stores, where you pick up the items you want and pay
for it by talking to the shopkeeper. That's another thing: moving into
friendlies will start a conversation with them. No extra command
required.
> 4. Inventory.
>
> Am I right in thinking we want a system where the user presses a key to
> bring up the inventory category menu (Weapons, Armour, Shields, etc)
> and then presses another key to select an individual item (Lipstick,
> Makeup, etc) and then presses another key to select an action (Drop,
> Sell, Apply, Examine, etc)? I rather like that system.
That's correct.
> This doesn't really limit the inventory to 64 items. It limits it to a
> maximum of 8 items in a maximum of 8 categories. For example, it's not
> possible to have 12 potions and 4 helmets. However, I think in the
> majority of cases (Armour, Shields, etc) this is a good thing, because
> no character could carry around more than eight of those.
That makes more sense than what I was planning (only have 8 possible
body armors, 8 possible helmets, etc.) Also, it forces resource
management, which isn't such a bad thing. After all, what adventurer
could carry 5 different plate mails, or would be able to safely carry
15 potions?
> I think it would be best to keep items in the same location, even when
> the number of items in a category changes. For example, let's say the
> user picks up four potions:
>
> 1. Red Potion
> 2. Blue Potion
> 3. Orange Potion
> 4. Black Potion
>
> They drink potion 3. To keep things consistent and familiar with the
> previous layout, I think it would be best if it now looked like this:
>
> 1. Red Potion
> 2. Blue Potion
> 4. Black Potion
>
> If they come along later and pick up a Pink Potion, we can reuse slot
> 3. Like so:
>
> 1. Red Potion
> 2. Blue Potion
> 3. Pink Potion
> 4. Black Potion
That's what I was planning. That allows the player to habitualize
(probably not a word) or memorize key combinations to perform actions.
If you've ever used the number pad to play the game Little Fighter 2,
you'll know what I'm talking about. If not, I'm sure you know what I
mean anyway. This method also eliminates the need for inventory
sorting. :)
Another option I was considering as a way of expanding options was to
have multiple available menus. For example, the first menu would look
like this:
###
#@#
#v#
Pressing Num2 would bring up a menu like this:
#^#
#@#
###
Pressing Num8 would then return you to the original menu. This would
allow for 14 intial options, but would be slower.
> 5. Game actions.
>
> Such as quit, start new game, character info etc. There doesn't seem to
> be any keys left to bring up a menu with those things. My solution
> would be to remove resting and then modify the system slightly:
>
> - :Skills
> + :Display equipped
> / :Game menu
> * :Spells
> . :Look
> Num 5 :Inventory
> Num 0 :Cancel menu
> Other numbers :Movement / Radial Menus
> Enter :Stairs / Confirming
>
> If Skills were used more than Inventory, I'd swap them round, because
> Num 5 is very easy to access.
I was planning on having 5 be the Rest key, like in many other games.
Also, remember that Num0 can perform commands when a menu is not
available, in addition to canceling menus. I think Num0 will be the
action button and Enter will bring up the game menu. I didn't plan a
separate menu to display equipment, although I suppose it may be
useful. My idea was to have something like this:
###############
# Short Sword #
# 1D6 Slash #
# #
# Equipped #
# #
###############
Here "Equipped" is sort of a property of the item. The item could have
up to 2 properties (for equippable items, 3 for other items). One
property would be a modifier, like "flaming" or "poisoned". Another
would be its status, like "rusted" or "sharp". But having a separate
equipment menu would free up another property for weapons and armor, so
it's not a bad idea.
> 7. Spell targeting
>
> This seems straight forward. Center target on the last creature, or if
> there isn't one, center on the nearest target. Use the numbers to move
> around. + switches between visible targets. - goes to the nearest
> target. Num 5 could center on the player. Enter confirms the square to
> target.
>
> (end of numbered paragraphs)
IIRC, Angband targeting can be controlled exclusively with the number
pad. It's a good model to use.
> I'll stop rambling now.
>
> Basically, I think this is a great idea. The only major problems I can
> see is that (afaik) laptops don't have a number pad. Is there a
> solution to that problem? I don't know much about laptop keyboards.
The best solution would be a USB number pad. Otherwise, laptops
generally have a Function key (like Shift) that sort of allows a number
pad using the basic QWERTY keyboard. It's not as intuitive that way,
so this game is probably out where laptops are concerned.
> It would also be possible to do a roguelike that's controlled entirely
> by the mouse, but I think moving with the mouse would get very annoying
> very quickly. So the keyboard is better.
Two or three buttons, but quite a large range of motion. Interesting
concept, but not one that would work very well, IMO. Mouse gestures
(dragging in certain directions) might be useful, but it remains to be
seen how usable or likable the interface would be.
> I'll be insulting your February "Roguelike of the Month" idea, so that
> you make this idea instead :)
No need. I'm planning to enter this in the upcoming 7DRL challenge
(which I assume will be in February or March like the past years).
Actually, maybe I'll introduce "1HRL: Type II" next month and explore a
roguelike that only uses the mouse.
Anyway, thanks for your input. I'm glad this actually sounds like a
good idea.
Gamer_2k4
Gamer_2k4
> Hmmm. If I saw that, I'd think: "One Hour Roguelike".
I suppose, since HR is short for hour and RL is short for roguelike.
(Yes, this should have been in my other response. I just didn't think
about it until now.)
Gamer_2k4
Bongo Bill
> Why are you limiting the system to 8 or multiples of 8 though? Why not
> use Num 5? Is it so the player can always see their character? If so,
> that sounds sensible.
I was sort of getting the impression that the 5 key would back out of
the current menu. If there's only a numpad, after all, there's unlikely
to be an "Escape" key.
...Or, I suppose, there's the 0 key, but nobody likes that one.
Are we shooting more for a computer numpad, or something like a phone's
keypad?
Gamer_2k4
Bongo Bill wrote:
> Icey wrote:
> > Why are you limiting the system to 8 or multiples of 8 though? Why not
> > use Num 5? Is it so the player can always see their character? If so,
> > that sounds sensible.
>
> I was sort of getting the impression that the 5 key would back out of
> the current menu. If there's only a numpad, after all, there's unlikely
> to be an "Escape" key.
>
> ...Or, I suppose, there's the 0 key, but nobody likes that one.
I was thinking Num0, but I'm flexible.
> Are we shooting more for a computer numpad, or something like a phone's
> keypad?
Computer. IMO, a phone's screen is too small to really be useful.
Gamer_2k4
Jeff Lait
> Gamer_2k4 wrote:
> > 1HRL is a really good acronym.
>
> Hmmm. If I saw that, I'd think: "One Hour Roguelike".
Ditto. Primarily because the common usage of 7DRL causes me to assume
it is some time related acronym.
I'll also point out this isn't actually one handed. You can easily
play any full-keyboard roguelike with only one hand. I can play
Nethack quite sucessfully only using my toes. (And, yes, this includes
typing in wishes if I'm feeling brave)
> Anyway. A one handed roguelike. I think this is interesting. Performing
> actions would be quick and it would be easy to learn. Also, the number
> pad is in a nice square layout, rather than the unaligned letters.
>
> Why are you limiting the system to 8 or multiples of 8 though? Why not
> use Num 5? Is it so the player can always see their character? If so,
> that sounds sensible.
I'd avoid 5 because it breaks the radial symmetry. 5 could be used for
"Go back to previous menu" to make it easier to explore deep rings.
> I was thinking of the possible problems that might occur with using
> this on a roguelike:
>
> 1. Characters names.
>
> This requires letters. There could be a randomly generated name given
> and the user would simply press Num Enter to accept that. They could
> specify a name if they wanted to (using the evil letters) or generate
> another random name (using a key on the number pad).
Or they could type in the name using an on-screen keyboard that they
navigate using the number pad and hit 0 to select each letter.
POWDER has a different approach of actually using directional menus but
basing what the menu is on what other buttons are pressed, resulting in
chording craziness.
> 2. Using stairs.
>
> You don't mention a key for that. Maybe Number Pad Enter would work
> alright? Could be thought of as "Enter another area".
I would suggest instead context specific menus. When you enter a
square with items or stairs, pop up a menu asking if they want to climb
them or pick anything up. POWDER does this by listing all the
available items to pick up in addition to "Climb Stairs". At first, I
was opposed to this sort of pop-up menu, but I must confess it has
become very natural and useful.
> 3. Merchants.
>
> How would they be handled? I can think of two ways:
Odd you don't mention:
C. Nethack style merchants.
Which requires no use of menus.
> Basically, I think this is a great idea.
So do I. My original plans for POWDER was to use four-way (you don't
have 8 directions on a gamepad, unfortunately) nested menus such as
described here. However, in practice I ended up using linear menus
everywhere. Linear menus, I'm afraid, aren't really all that much less
efficient than directional menus. Furthermore, they have the rather
serious benefit in a long term project of being expandable. Using
radial menus means each feature has to be shoehorned in. I think,
thus, it is a good idea to plan it with a 7drl where you can have a
known feature set you stick to.
> The only major problems I can
> see is that (afaik) laptops don't have a number pad. Is there a
> solution to that problem? I don't know much about laptop keyboards.
Not really. They usually have a numpad option, but it shadows other
keys and is also not square so really doesn't feel like a numpad.
> It would also be possible to do a roguelike that's controlled entirely
> by the mouse, but I think moving with the mouse would get very annoying
> very quickly. So the keyboard is better.
I know what you mean. Movement is always the barrier in my mind in
trying to make a mouse driven roguelike. I have the similar problem
when I try to think of the perfect roguelike for the GBA DS which uses
a stylus. (Note styluses are very different from mice!) I'd like to
point out that CalcRogue had some interesting ideas on stylus input:
http://calcrogue.jimrandomh.org/
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Mario Donick
> > solution to that problem? I don't know much about laptop keyboards.
> Not really. They usually have a numpad option, but it shadows other keys and is also not square so really
> doesn't feel like a numpad.
The approach I did in LambdaRogue when I started to develop that game
was to use the keys
789
uio
jkl
as "numpad". These are they keys on which the laptop's numpad option
binds the numbers. So uio are 456 and jkl are 123. Normally you had to
press the Fn key together with these keys, but in LambdaRogue you don't
need to this. As the numpad numbers are printed on these keys, too,
it's not hard to imagine that you're using a real numpad.
Of course then you have to rebind other commonly used keys to other
keys. "o" for "open" wouldn't work, the same for "k" as, e.g., "kick"
or "l" for "look". So LambdaRogue uses "Enter" as multifunctional key
which opens doors, enters portals etc. As the big "Enter"-key is not
easily to reach if you're using the 789/uio/jkl setting, the "n" key
which lies on the lower left of the "j" does the same than enter. So
it's possible to have the right hand on this part of the keyboard and
do the most actions without moving the hands too much. Since I have the
quick inventory option, it's even possible to browse inventory without
using other keys.
Unfortunately nobody here seemed to get my point concerning the use of
this keybinding. Perhaps 'cause they don't have laptops... ;)
Mario
Antoine
Jeff Lait wrote:
> Icey wrote:
> > It would also be possible to do a roguelike that's controlled entirely
> > by the mouse, but I think moving with the mouse would get very annoying
> > very quickly. So the keyboard is better.
>
> I know what you mean. Movement is always the barrier in my mind in
> trying to make a mouse driven roguelike. I have the similar problem
> when I try to think of the perfect roguelike for the GBA DS which uses
> a stylus. (Note styluses are very different from mice!) I'd like to
> point out that CalcRogue had some interesting ideas on stylus input:
> http://calcrogue.jimrandomh.org/
Movement is not a big problem IMO provided you can click once to make
many moves (eg. click where you want to go and your @ trundles across
the screen to it).
If you had to click once per move it'd be a huge PITA.
My current in-dev game is really intended for stylus systems (although
I don't have one, so I'm simulating it as a one-button mouse).
A.
Jeff Lait
Antoine wrote:
> Jeff Lait wrote:
> > Icey wrote:
> > > It would also be possible to do a roguelike that's controlled entirely
> > > by the mouse, but I think moving with the mouse would get very annoying
> > > very quickly. So the keyboard is better.
> >
> > I know what you mean. Movement is always the barrier in my mind in
> > trying to make a mouse driven roguelike. I have the similar problem
> > when I try to think of the perfect roguelike for the GBA DS which uses
> > a stylus. (Note styluses are very different from mice!) I'd like to
> > point out that CalcRogue had some interesting ideas on stylus input:
> > http://calcrogue.jimrandomh.org/
>
> Movement is not a big problem IMO provided you can click once to make
> many moves (eg. click where you want to go and your @ trundles across
> the screen to it).
That doesn't work for unexplored areas. Indeed, being effectively a
travel command, it also has lots of problems like determining when you
should break out of the movement because you encounter a previously
unknown hostile. It would be sad if accidentally hitting the map
causes your @ to run to its death.
> If you had to click once per move it'd be a huge PITA.
Click-and-hold seems a better option where you rotate the stylus around
the @ to chose the direction to move in. I'm thinking of Ultima Online
or Diablo style movement here.
> My current in-dev game is really intended for stylus systems (although
> I don't have one, so I'm simulating it as a one-button mouse).
Keep in mind that stylus are absolute while mice are relative. This
greatly changes how you can use them! I'd recommend getting a stylus
as soon as possible to ensure your development stays on track.
Antoine
Jeff Lait wrote:
> Antoine wrote:
> > Jeff Lait wrote:
> > > Icey wrote:
> > > > It would also be possible to do a roguelike that's controlled entirely
> > > > by the mouse, but I think moving with the mouse would get very annoying
> > > > very quickly. So the keyboard is better.
> > >
> > > I know what you mean. Movement is always the barrier in my mind in
> > > trying to make a mouse driven roguelike. I have the similar problem
> > > when I try to think of the perfect roguelike for the GBA DS which uses
> > > a stylus. (Note styluses are very different from mice!) I'd like to
> > > point out that CalcRogue had some interesting ideas on stylus input:
> > > http://calcrogue.jimrandomh.org/
> >
> > Movement is not a big problem IMO provided you can click once to make
> > many moves (eg. click where you want to go and your @ trundles across
> > the screen to it).
>
> That doesn't work for unexplored areas.
Good point, I have no LOS restrictions so it doesn't apply for me but
would otherwise be a problem.
> Indeed, being effectively a
> travel command, it also has lots of problems like determining when you
> should break out of the movement because you encounter a previously
> unknown hostile. It would be sad if accidentally hitting the map
> causes your @ to run to its death.
Fixable with a bit of work (need both automatic interrupts if you get
hit, and the option to manually interrupt at any time).
> > If you had to click once per move it'd be a huge PITA.
>
> Click-and-hold seems a better option where you rotate the stylus around
> the @ to chose the direction to move in. I'm thinking of Ultima Online
> or Diablo style movement here.
Yes that would work too
> > My current in-dev game is really intended for stylus systems (although
> > I don't have one, so I'm simulating it as a one-button mouse).
>
> Keep in mind that stylus are absolute while mice are relative. This
> greatly changes how you can use them!
Please explain?
> I'd recommend getting a stylus
> as soon as possible to ensure your development stays on track.
Good point.
A.
Andrew Doull
> Jeff Lait wrote:
> > That doesn't work for unexplored areas.
>
> Good point, I have no LOS restrictions so it doesn't apply for me but
> would otherwise be a problem.
Having implemented a click to move algorithm using a mouse, it works fine for
unexplored areas.
You just use the same path finding algorithm, and treat any unknown grid as
passable, until the player actually explores the grid. If its passable,
continue the path, if its not, stop.
For bonus points, implement a follow the wall algorithm (or in my case, the
Angband run algorithm) when the player hits an unpassable grid in a previously
unexplored area.
See the implementation in Unangband or FAangband for details.
Andrew
--
The Roflwtfzomgbbq Quylthulg summons L33t Paladins -more-
http://unangband.berlios.de
Radomir 'The Sheep' Dopieralski
Antoine wrote:
When you move your mouse to the upper right corder of your mouse pad, the
cursor usually only reaches as far as half of the screen. Then you lift
your mouse a little, move it to the lower left corner, and repeat the
motion to get th mouse cursor into the corner. Of course it depends on
your mouse resolution, settings and the size of your mouse pad.
Tablets work more like touchscreens -- if you put your stylus in the upper
right corner of the screen, the cursor is moved to the upper right corner
of the screen. You move it to the lower left one, and the cursor instantly
jumps to the lower left corner.
This has several effects:
* tablets are very fast, about 2-3 times faster than mice
* large tablets are astronomically expensive
* objects at the edges of the screen don't have infinite size anymore
* it's easier to draw a cricle in the middle of the screen than to do it
in the corner
* you can click things without even looking at the screen
David Damerell
>You are a teenage girl on a summer camp. One night you saw some UFO
>landed in the forest nearby, and short after that all the people around
>you have been turned into several kinds of sex-crazied monsters. They
>attack you rying to rip your clothes from you and impregnate with the
>alien seed, which would turn you into a mnster too. You need to run away.
Aha. When you win the game, you get the "payback" bonus game; same setup,
same character, but you start with a 12-gauge and a big box of shells. :-)
--
David Damerell <dame...@chiark.greenend.org.uk> flcl?
Today is First Olethros, January - a weekend.
Jeff Lait
> Jeff Lait wrote:
> > > My current in-dev game is really intended for stylus systems (although
> > > I don't have one, so I'm simulating it as a one-button mouse).
> >
> > Keep in mind that stylus are absolute while mice are relative. This
> > greatly changes how you can use them!
>
> Please explain?
First, let me clarify that small differences in physical interface
result in signficant changes in feel. The Game Boy Advance, for
example, has four buttons: L, R, A and B. However, the four buttons
are not at all equal - the L and R are shoulder buttons while the A and
B are under the right thumb. A game designed for the gameboy advance
should thus not think that it just has "four buttons" - it needs to
realize that it has two sets of different buttons.
So, let's get back to pointing devices. Here is a quick list of
obvious pointing devices that I can think of and know exist.
1) Mice. We should all be familiar with these :>
2) Tablets. The Wacom tablet is a good example.
3) On-screen stylus. The Gameboy DS is the most accessable example.
Most PDAs are also in this category, such as Palm Pilots.
4) Pointers. The Wii's remote is in this category.
5) Dual Knobs. Etcha Sketch.
The biggest difference is Relative vs Absolute.
Relative controls, like a mouse, allow you to scroll forever in a small
amount of space. Games like Quake work with the mouse because you can
keep turning left forever - there is no "edge of the screen" that you
hit that stops your motion. The other advantage of relative controls
is accelleration. There is no need for 1cm of mouse motion to always
translate to the same distance on screen - it is common to artificially
boost the cursor speed if the mouse is moving quickly. This lets you
zip across a 19" monitor and yet then slow down to do fine control.
For example, it requires my full mouse pad to move from the right side
to left side of my monitor if I move my mouse slowly. If I move
quickly, I cover the same screen estate with half of my mouse pad.
Absolute controls, on the other hand, have a direct mapping of
distances. Each position on the tablet corresponds with a position on
the screen. No matter how fast or slowly you move the stylus, you have
to go the same physical distance to reach a point. I have a large
Intuos tablet (9x12, IIRC) and find menus are very frustrating. Going
to a menu with a mouse is fast - with this tablet I have to move my arm
up to 9 inches to reach it. That's the disadvantage, but the advantage
is equally big. I don't have to search for the menu by using hand-eye
coordination. The menu, or any object's, location can be remembered
purely by muscle memory without needing visual feedback. After you
have drawn a line with a tablet, you can never go back to drawing with
a mouse.
Of course, not all absolute systems are the same.
A pointer based system, like the Wii, has the faster indexing than
tablets because you are just using angular changes rather than
translational changes to move the cursor. Of course, as a result,
drawing lines becomes difficult again :>
The two different stylus systems are the blind system, such as the
traditional wacom tablet, and the on-screen style, such as the Cintiq,
PDAs, or the GBA DS. While one could make the argument that the
on-screen style results in your hand obscuring what you are working on,
it is a pretty weak argument. IMHO, the on screen is entirely
superior. The two, however, will have game design differences.
Working with a blind tablet, while not requiring the level of visual
feedback as the mouse, still needs to do a registration process for
your eyes and hand to be in the same spot. The onscreen requires no
such iteration - you click where you want to click. Hmm.. This does
make me think of a disadvantage of the onscreen. Onscreen forces the
tablet size to equal the screen size. Having a blind-tablet like the
Graphire which is small and high resolution can give one fast random
access without forcing the screen to also be small.
What is your desired stylus platform?
Ray Dillinger
> So, let's get back to pointing devices. Here is a quick list of
> obvious pointing devices that I can think of and know exist.
>
> 1) Mice. We should all be familiar with these :>
> 2) Tablets. The Wacom tablet is a good example.
> 3) On-screen stylus. The Gameboy DS is the most accessable example.
> Most PDAs are also in this category, such as Palm Pilots.
> 4) Pointers. The Wii's remote is in this category.
> 5) Dual Knobs. Etcha Sketch.
I recently acquired a "pen mouse" - which is essentially
an optical mouse in the shape of a pen. It's a 3-button
mouse, and what is logically the "main" button (the one
that, on a standard mouse set up for right-handers, is the
left button) has two physical buttons attached to it.
One is a standard button on the pen barrel, and the other
is a tiny nub in the point that detects when you put
writing-or-drawing type pressure on it. So you can move
it around with its point close to the pad, and the pointer
will follow your movements around on the screen. But when
you press down, it's equivalent to pressing the main mouse
button and you can drag, or draw, or whatever the current
application does when you have the main button down.
I have to say that it gives me substantially better
control (line drawing, etc) than a standard rodent, so
that's good. But it still suffers from a "rotation of
frame" problem where, if you turn your wrist while
writing (usually I move my arm every few words, and turn
the wrist to reach correct absolute locations for individual
letters as I write), it doesn't translate the rotated
movement correctly onto the screen. "up" on the screen
is always the direction the top of the pen is pointing on
the pad, and if that direction changes, then your writing
gets distorted. Acceleration also defeats writing-type
control, because with acceleration you move the pen the
same distance, and if you happen to move faster the pointer
goes considerably further.
So in order to use it for writing, etc, I have to turn
accelleration off and practice a writing/drawing style
where the angle of the wrist never changes. It's clumsy
compared to the ease of a standard pen. But it's ten
times better control than a standard mouse, and it actually
will *work* for writing, drawing, etc.
Bear
Martin Read
>Unfortunately nobody here seemed to get my point concerning the use of
>this keybinding. Perhaps 'cause they don't have laptops... ;)
I have a laptop. I also have a deep fondness for rogue's distinctive
movement keymap.
--
Martin Read - my opinions are my own. share them if you wish.
\_\/_/ http://www.chiark.greenend.org.uk/~mpread/dungeonbash/
\ / "the lights shine clear through the sodium haze the night draws near
\/ and the daylight fades" -- Sisters of Mercy, "Lights"
Mario Donick
> >Unfortunately nobody here seemed to get my point concerning the use of
> I also have a deep fondness for rogue's distinctive movement keymap.
I don't remember rogue's keymap, but I fear it's that ugly and
unlogical Vi-thing, isn't it? Well, perhaps I'm no real roguelike-fan,
'cause I want every UI-related stuff as easy as possible...
Mario
David Damerell
>Martin Read:
>>I also have a deep fondness for rogue's distinctive movement keymap.
>I don't remember rogue's keymap, but I fear it's that ugly and
>unlogical Vi-thing, isn't it? Well, perhaps I'm no real roguelike-fan,
>'cause I want every UI-related stuff as easy as possible...
Even if you suppose that four fingertips resting in a row isn't easy, the
fact is that an awful lot of people out there are familiar with the
HJKLYUBN approach; for them it _is_ now easy.
--
David Damerell <dame...@chiark.greenend.org.uk> Distortion Field!
Today is Second Potmos, January.
pol
>>>I also have a deep fondness for rogue's distinctive movement keymap.
>>I don't remember rogue's keymap, but I fear it's that ugly and
>>unlogical Vi-thing, isn't it? Well, perhaps I'm no real roguelike-fan,
>>'cause I want every UI-related stuff as easy as possible...
>
> Even if you suppose that four fingertips resting in a row isn't easy, the
> fact is that an awful lot of dinosaurs out there are familiar with the
> HJKLYUBN approach; for them it _is_ now easy.
> --
> David Damerell <dame...@chiark.greenend.org.uk> Distortion Field!
> Today is Second Potmos, January.
I tried playing some game like that and it is so bizarre. You press this
button, which is in this direction to move your character in some other
direction. Isn't that what a lot of games do to your controls when your
character is confused?
I probably would have done something closer to what Donick did.
R. Dan Henry
>1. Characters names.
>
>This requires letters.
But since character names are unnecessary, the simple solution is just
to drop them. The @ will be referred to as "you" at all times.
Likewise, I think merchants may be best dealt with by not including
them. I at least wouldn't worry about how to do so until I'd reached a
point where I was sure I wanted to have merchants.
>2. Using stairs.
Design the dungeon so stairs are not placed where they block corridors,
then they can be automatic (move on the stairs and you go up/down). This
also requires items can't be dropped on stairs.
Jude H
> I tried playing some game like that and it is so bizarre. You press this
> button, which is in this direction to move your character in some other
> direction.
Oh, that only lasts a few games. :)
I didn't like the vi keys at first. Then I spent a weekend playing Crawl
on a laptop, and now I use those keys for preference because once learnt,
I find them much faster and easier.
I'm not saying other people should convert, only that there is good
logic behind that key layout. It just doesn't resemble the logic of the
numpad. :)
--
--j hungerford.
Another Roguelike In Development:
http://arid.sourceforge.net
David Damerell
[No attribution line]
>>Even if you suppose that four fingertips resting in a row isn't easy, the
>>fact is that an awful lot of dinosaurs out there are familiar with the
I wrote "people". Laugh? I nearly did.
>>HJKLYUBN approach; for them it _is_ now easy.
[quoted .signature]
>I tried playing some game like that and it is so bizarre.
The available evidence suggests you can't cope with it because you're not
very bright.
--
David Damerell <dame...@chiark.greenend.org.uk> Kill the tomato!
Today is Second Olethros, January - a weekend.
Radomir 'The Sheep' Dopieralski
David Damerell wrote:
> Quoting pol <p...@pol.net>:
> [No attribution line]
>>>Even if you suppose that four fingertips resting in a row isn't easy, the
>>>fact is that an awful lot of dinosaurs out there are familiar with the
> I wrote "people". Laugh? I nearly did.
Ugh! That's *low*. When will we start posting malware to "defeat the
opponent"? What was the purpose of this newsgroup again?
pol
>>>Even if you suppose that four fingertips resting in a row isn't easy, the
>>>fact is that an awful lot of dinosaurs out there are familiar with the
> ^^^^^^^^^
>
> I wrote "people". Laugh? I nearly did.
>
>>>HJKLYUBN approach; for them it _is_ now easy.
> [quoted .signature]
>>I tried playing some game like that and it is so bizarre.
>
> The available evidence suggests you can't cope with it because you're not
> very bright.
> --
> David Damerell <dame...@chiark.greenend.org.uk> Kill the tomato!
> Today is Sezcond Olethros, January - a weekend.
Woah, looks like I touched a nerve there. Don't worry! Everyday, everybody
else gets one day older too.
I thought it was pretty funny, so I'm glad that you caught it at least.
heheh
Kornel Kisielewicz
> David Damerell wrote:
>
>> Quoting pol <p...@pol.net>:
>> [No attribution line]
>>>> Even if you suppose that four fingertips resting in a row isn't easy, the
>>>> fact is that an awful lot of dinosaurs out there are familiar with the
>> I wrote "people". Laugh? I nearly did.
>
> Ugh! That's *low*. When will we start posting malware to "defeat the
> opponent"? What was the purpose of this newsgroup again?
That's a good question :)
That's why I usualy* don't wander into such depths (threadwise) of rgrd,
because as they say, only flame dragons and trolls wander around here :]
* I have an exam tommorow, so I'm determinated even to read old
newsposts not to learn the material instead ^^.
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"11 years and no binary. And it's not vapourware" -- Igor Savin
Jeff Lait
> Quoting Mario Donick <mario....@googlemail.com>:
> >Martin Read:
> >>I also have a deep fondness for rogue's distinctive movement keymap.
> >I don't remember rogue's keymap, but I fear it's that ugly and
> >unlogical Vi-thing, isn't it? Well, perhaps I'm no real roguelike-fan,
> >'cause I want every UI-related stuff as easy as possible...
>
> Even if you suppose that four fingertips resting in a row isn't easy, the
> fact is that an awful lot of people out there are familiar with the
> HJKLYUBN approach; for them it _is_ now easy.
I'm no fan of the specifics of HJKLYUBN. For one, the B and N are
typed with opposite hands, resulting in a layout that isn't one handed.
However, I am strongly opposed to any attempt to create a new alpha
layout. Last thing I want is another standard. If you desperately
want a numpad style layout, I suggest you use WASD or a similar. This,
being the opposite side of HJKLYUBN, will not confuse those users, and
also matches the standard promulgated by various FPS.
Martin Read
>David Damerell wrote:
>> Even if you suppose that four fingertips resting in a row isn't easy, the
>> fact is that an awful lot of people out there are familiar with the
>> HJKLYUBN approach; for them it _is_ now easy.
>
>I'm no fan of the specifics of HJKLYUBN. For one, the B and N are
>typed with opposite hands, resulting in a layout that isn't one handed.
When I'm playing roguelikes, they *are* typed with one hand. But then,
my homekeys (the ones my fingers rest on when I pause from typing) are
something like "AERVNIO'" or "ShiftWERBUI;" so I'm clearly a freak :)
--
Martin Read - my opinions are my own. share them if you wish.
\_\/_/ http://www.chiark.greenend.org.uk/~mpread/dungeonbash/
\ / impending, adj. - Fatal to small demons.
\/
stu
Martin Read wrote:
> When I'm playing roguelikes, they *are* typed with one hand. But then,
> my homekeys (the ones my fingers rest on when I pause from typing) are
> something like "AERVNIO'" or "ShiftWERBUI;" so I'm clearly a freak :)
my natural keyboard splits the 'B' off the trad keys so it can be a
real pain
in the buttocks if I am forced to use the old archaic mappings.
-stu
Nick McConnell
> On 2007-01-08 22:46:27, "Antoine" wrote:
>
> > Jeff Lait wrote:
> > > That doesn't work for unexplored areas.
> >
> > Good point, I have no LOS restrictions so it doesn't apply for me but
> > would otherwise be a problem.
>
> Having implemented a click to move algorithm using a mouse, it works fine for
> unexplored areas.
>
> You just use the same path finding algorithm, and treat any unknown grid as
> passable, until the player actually explores the grid. If its passable,
> continue the path, if its not, stop.
>
> For bonus points, implement a follow the wall algorithm (or in my case, the
> Angband run algorithm) when the player hits an unpassable grid in a previously
> unexplored area.
>
> See the implementation in Unangband or FAangband for details.
In fact, the next version of FAangband (out soon!) will be playable completely
with the mouse (apart from a few uncommon tasks like entering your name). This
was motivated by wanting to have a decent WinCE port, which is also nearly
complete.
Nick.
--
Nick McConnell
FA + "Ooog" DN L:42 DL:57 A+ R++ Sp w:Rog
FA*/A/NPP/O/Po/St/Un W/L H- D c-- f- PV+ s- d++ P++ M+
C-- S- I* So+ B+ ac GHB SQ? RQ+ V-/V+@ F:NPP notes, etc.