gamedevlists-design

[GD-Design] gesturing

[Brett B. <res...@ga...>]

Hello,
We are making something of an FPS-style game for consoles and the =
conversation about speed is something that we have been wrestling with =
in our own game because it is targeted at a wide range of people.  =
Basically the "problem" we would like to solve is aiming, and we want to =
solve it by removing it as much as possible. I put problem in quotes =
because we have had heated arguments that PFS games are pretty much =
about aiming, and once you take that out of the equation it is no longer =
an FPS.  So, I'm not looking for people to convince me aiming can be =
done in such and such way, instead I would like alternative game design =
advice that doesn't factor in aiming at all.

Our current proposed solution is to move the "game" from aiming to =
firing of the weapon.  We hope to do this with gestures.  This has been =
done to some extent on the PC in games like Black and White, and also =
there was a demo at the experimental game workshop at GDC.

What I envision is a system where the firing of the weapon is done with =
the analog stick such that the more accurately you reproduce the =
gesture, the better your "shot" is.  For example, let's say we want to =
snipe somebody with a rifle. I see my target in my scope and the =
crosshairs are moving about just like a normal FPS.  Instead of using =
the analog stick to aim the crosshair at my target, I perfom a "fire" =
gesture, say a simple clockwise spiral inward.  If I do it 90% or better =
correctly I get a headshot, 60-90% I get a body shot and 40-60% I get a =
legshot, less than 40% misses (but I still see some sort of shot fired). =
 While I complete the gesture the scope locks onto (stops moving) the =
part of the body I hit so I can see my result.  The advantage is that =
you can perform the action as slowly or quickly as you want, and we =
reward the hardcore people who will take the time to learn the gestures =
well, while not punishing the casual gamer.  The amount of time to do a =
gesture would be tweaked such that it will be on par with the time to =
aim (assuming average console gamer) so the other mechanics should be =
able to be balanced normally.

What do people think of this idea?
Flaws?  Suggestions?
Should the player be able to train the game with the motion they want =
for a given gesture or should they be required to replicate one of our =
choosing?
Are there any console game using gestures?
Are there other game mechanics that can be used in place of aiming =
besides gesturing?

Thanks,
Brett

Re: [GD-Design] gesturing

[Mike W. <mi...@ge...>]

i like the concept of gestures, one simple way to make the concept of=20
firing weapons more realistic is simply to remove the 'crosshair' that=20
every game uses.

operation flashpoint used the idea of the aiming reticle and iron=20
crosshairs that a soldier is provided with, this can be integrated with=20
a skill-based system (either actual statistics or something like=20
gestures as you have mentioned) and provide a much more realistic design.

realism as a design goal isn't a panacea of course, but this at least=20
forces players to get away from traditional game skills (ie moving a dot=20
onto a target and clicking the mouse, something a 4 year old can learn)=20
instead forcing them to recognize properties inherent in a specific=20
weapon for example (ak-47 tends to pull up and to the right) and adjust=20
skills accordingly.

counter-strike does this to a certain extend, players that learn a=20
weapons' spray pattern can adjust for it as they are firing, much like a=20
  weapons expert can.

certain weapons are inherently simpler to fire (mp5 for example) but=20
don't do as much damage, balancing things out for an inexperienced gamer.

just an idea.  i'd love to hear about your experimentation with gestures=20
- i just started teaching game design at a local college and am looking=20
for examples like this for new approaches to common genre's (fps for=20
example).

cheers
mike w
www.gekidodesigns.com



Brett Bibby wrote:
> Hello,
> We are making something of an FPS-style game for consoles and the conve=
rsation about speed is something that we have been wrestling with in our =
own game because it is targeted at a wide range of people.  Basically the=
 "problem" we would like to solve is aiming, and we want to solve it by r=
emoving it as much as possible. I put problem in quotes because we have h=
ad heated arguments that PFS games are pretty much about aiming, and once=
 you take that out of the equation it is no longer an FPS.  So, I'm not l=
ooking for people to convince me aiming can be done in such and such way,=
 instead I would like alternative game design advice that doesn't factor =
in aiming at all.
>=20
> Our current proposed solution is to move the "game" from aiming to firi=
ng of the weapon.  We hope to do this with gestures.  This has been done =
to some extent on the PC in games like Black and White, and also there wa=
s a demo at the experimental game workshop at GDC.
>=20
> What I envision is a system where the firing of the weapon is done with=
 the analog stick such that the more accurately you reproduce the gesture=
, the better your "shot" is.  For example, let's say we want to snipe som=
ebody with a rifle. I see my target in my scope and the crosshairs are mo=
ving about just like a normal FPS.  Instead of using the analog stick to =
aim the crosshair at my target, I perfom a "fire" gesture, say a simple c=
lockwise spiral inward.  If I do it 90% or better correctly I get a heads=
hot, 60-90% I get a body shot and 40-60% I get a legshot, less than 40% m=
isses (but I still see some sort of shot fired).  While I complete the ge=
sture the scope locks onto (stops moving) the part of the body I hit so I=
 can see my result.  The advantage is that you can perform the action as =
slowly or quickly as you want, and we reward the hardcore people who will=
 take the time to learn the gestures well, while not punishing the casual=
 gamer.  The amount of time to do a gest
ure would be tweaked such that it will be on par with the time to aim (as=
suming average console gamer) so the other mechanics should be able to be=
 balanced normally.
>=20
> What do people think of this idea?
> Flaws?  Suggestions?
> Should the player be able to train the game with the motion they want f=
or a given gesture or should they be required to replicate one of our cho=
osing?
> Are there any console game using gestures?
> Are there other game mechanics that can be used in place of aiming besi=
des gesturing?
>=20
> Thanks,
> Brett
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM=
's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admi=
n.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=CCk
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU6
>=20
>=20

Re: [GD-Design] gesturing

[Tom H. <to...@ve...>]

At 06:23 PM 1/5/2004, you wrote:
>Our current proposed solution is to move the "game" from aiming to firing 
>of the weapon.  We hope to do this with gestures.  This has been done to 
>some extent on the PC in games like Black and White, and also there was a 
>demo at the experimental game workshop at GDC.

Quite simply, I think that while looking for a new control mechanism for 
FPS is a very worthy goal, and trying to put the casual and hardcore gamers 
on more equal footing is probably worth as well, what you're proposing is 
very bad design. I'll try to explain my reasons below.

>What I envision is a system where the firing of the weapon is done with 
>the analog stick such that the more accurately you reproduce the gesture, 
>the better your "shot" is.

So .. you want to exchange hand-eye coordination for manual dexterity and 
pattern replication.

The downside to this is that you take an interface that many people are 
familiar with, and that translates directly with the action the player is 
attempting, and replace it with something very arbitrary and totally 
unrelated to the action at hand. In a very general sense, this is a 
fundamentally bad idea. It's always good design to make the actions on the 
controller mimic the actions taken in the game where possible. Creative 
interfaces for things like casting spells (or whatever the thing was called 
in Black and White) are reasonable because there isn't a direct translation 
and there wasn't a direct interaction with the world.

In other words, it's very clear to a user that when you push a button it 
means, "Shoot what I'm looking at". It's not so clear that making a gesture 
means "Aim for me and shoot".

>   For example, let's say we want to snipe somebody with a rifle. I see my 
> target in my scope and the crosshairs are moving about just like a normal 
> FPS.  Instead of using the analog stick to aim the crosshair at my 
> target, I perfom a "fire" gesture, say a simple clockwise spiral 
> inward.  If I do it 90% or better correctly I get a headshot, 60-90% I 
> get a body shot and 40-60% I get a legshot, less than 40% misses (but I 
> still see some sort of shot fired).  While I complete the gesture the 
> scope locks onto (stops moving) the part of the body I hit so I can see 
> my result.

I see you having many issues with target selection while trying to attack 
moving targets as well as while the player is moving. Not to mention that 
in order for this to work you're going to need to position a view / motion 
with one hand, while performing gestures with another. This means you're 
doing precise motions with two hands at the same time, and this is 
EXTREMELY hard for most people. Normal FPS use a hand to run / move and 
another to aim / fire .. as these are actions we normally do automatically 
in our daily life and are tightly coupled to each other this works 
reasonably well. However, now you're asking people to develop completely 
new skills in an ambidextrous manner ... not a good idea in my book.

>   The advantage is that you can perform the action as slowly or quickly 
> as you want, and we reward the hardcore people who will take the time to 
> learn the gestures well, while not punishing the casual gamer.

How does aiming punish the casual gamer more than your approach? Just like 
your technique, aiming is a skill that gets easier with practice and 
hardcore players will always be better than casual games. The only 
punishment happens when you have hardcore players fighting against casual 
gamers .. and in both scenarios, the casual gamers are going to get spanked.

There's zero advantage here ... you've just make the system much more 
complicated, and if anything, increased the gap between casual and hardcore 
gamers because of the magnitude of the learning curve.

>   The amount of time to do a gesture would be tweaked such that it will 
> be on par with the time to aim (assuming average console gamer) so the 
> other mechanics should be able to be balanced normally.

Part of aiming includes target selection ... I don't see how you plan to 
handle that here. Especially when you have multiple targets on the screen 
and are running around.

>Are there other game mechanics that can be used in place of aiming besides 
>gesturing?

When the game is a shooter ... where in the game you need to shoot things 
... using something other than aiming seems questionable at best.

Tom

Re: [GD-Design] gesturing

[Jeremy V. <ma...@ma...>]

Hi, I'm new to this list and found this topic pretty interesting.

I'd have to agree completely with Tom Hubina, who touched on a lot of
really good points. You say you don't like the whole "aiming" thing but
want to replace it with something that appeals to both casual and hard
core gamers.

Instead of a gesture how about something akin to a bubble level. Once a
target is selected and 'locked on to' a bubble level could appear and be
a measure of steadiness or accuracy. Perhaps a two axis bubble level for
both steadiness and accuracy. The difference being that the player doesn't
have to keep a dot on a moving target, but concentrate on balancing the
fixed position bubble level and let the in game character do the aiming.

A casual gamer can just fire off a shot, but a hardcore gamer can learn to
position the bubble on the level to ensure a good head shot etc. The
bubble would be hard to position while moving just due to its nature, and
perhaps the bubble of different weapons would be more or less sluggish or
not move the same way. You can try to handle recoil by having a shot throw
the bubble off its current mark a little, etc.

Anyhow, you said you are looking for ideas, so maybe this will help you
explore other avenues.

-Jeremy
http://madox.ca

Re: [GD-Design] gesturing

[Tom H. <to...@ve...>]

At 10:16 PM 1/5/2004, you wrote:
>Instead of a gesture how about something akin to a bubble level. Once a
>target is selected and 'locked on to' a bubble level could appear and be
>a measure of steadiness or accuracy. Perhaps a two axis bubble level for
>both steadiness and accuracy. The difference being that the player doesn't
>have to keep a dot on a moving target, but concentrate on balancing the
>fixed position bubble level and let the in game character do the aiming.

How about this as a variation:

1. The player runs and looks around like a normal FPS style game.
2. As the player's view changes, a box shows up around the enemy nearest 
the center of the screen to indicate target selection.
3. The player hits the Fire button once, and the sliders show up around the 
edge of the box with a target point somewhere in the box. The sliders are 
bouncing up/down and left/right.
4. Next press stops the up/down
5. Next press stops the left/right.
6. Shot is fired at the place where the lines intersect, and the distance 
to the target (from 3) determines the quality of the hit.

The shot still must take place in a reasonable amount of time, and the 
player must continue moving to keep a moving target in the sights.

All this does is make crude aiming much easier, and then change the aiming 
process into more of a timing challenge than an accuracy challenge.

I certainly don't think the twitch players would be into this kind of a 
thing, but it could be interesting for slower paced games.

It occurs to me that something like this would be a useful interface for 
something like a football game where you really play as the quarterback.

Tom

Re: [GD-Design] gesturing

[Mike W. <mi...@ge...>]

sounds reasonable, and this is a technique similar to those used in golf 
games for example to indicate how well or poor a shot is.

the legitimacy of comparing fps games to golf games is up for argument 
of course ;]
mike w
www.gekidodesigns.com

Tom Hubina wrote:

> At 10:16 PM 1/5/2004, you wrote:
> 
>> Instead of a gesture how about something akin to a bubble level. Once a
>> target is selected and 'locked on to' a bubble level could appear and be
>> a measure of steadiness or accuracy. Perhaps a two axis bubble level for
>> both steadiness and accuracy. The difference being that the player 
>> doesn't
>> have to keep a dot on a moving target, but concentrate on balancing the
>> fixed position bubble level and let the in game character do the aiming.
> 
> 
> How about this as a variation:
> 
> 1. The player runs and looks around like a normal FPS style game.
> 2. As the player's view changes, a box shows up around the enemy nearest 
> the center of the screen to indicate target selection.
> 3. The player hits the Fire button once, and the sliders show up around 
> the edge of the box with a target point somewhere in the box. The 
> sliders are bouncing up/down and left/right.
> 4. Next press stops the up/down
> 5. Next press stops the left/right.
> 6. Shot is fired at the place where the lines intersect, and the 
> distance to the target (from 3) determines the quality of the hit.
> 
> The shot still must take place in a reasonable amount of time, and the 
> player must continue moving to keep a moving target in the sights.
> 
> All this does is make crude aiming much easier, and then change the 
> aiming process into more of a timing challenge than an accuracy challenge.
> 
> I certainly don't think the twitch players would be into this kind of a 
> thing, but it could be interesting for slower paced games.
> 
> It occurs to me that something like this would be a useful interface for 
> something like a football game where you really play as the quarterback.
> 
> Tom
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=556
> 
> 

Re: [GD-Design] gesturing

[Brett B. <res...@ga...>]

> So .. you want to exchange hand-eye coordination for manual dexterity =
and=20
> pattern replication.

Good point! I hadn't realized the switch we were making. So if I want to =
stick with hand-eye coordination I need to make the gesture compatible =
with the weapon.  In the end it may be impossible to find something =
compelling, but the point of the discussion is to spawn new ideas, not =
simply follow what is done before.

> In other words, it's very clear to a user that when you push a button =
it=20
> means, "Shoot what I'm looking at". It's not so clear that making a =
gesture=20
> means "Aim for me and shoot".

So ideally I would come up with something that then allows to push a =
button to shoot if it is a triggered weapon. That gives the feeling of =
"triggering" an action which is understandable for conventional guns. Or =
I could change the weaponry to not use a trigger.  For example, a hira =
shuriken (those little ninja throwing star-thingos) could be "fired" by =
making a vertical "up" motion on the analog stick. The faster I make the =
motion, the hard the shuriken gets thrown and the more perfectly up I =
move could be used to decide the head/body/leg/miss decision. Does this =
make sense?=20


> Part of aiming includes target selection ... I don't see how you plan =
to=20
> handle that here. Especially when you have multiple targets on the =
screen=20
> and are running around.

Target selection is a big part of what we want to do, and I should have =
devoted more time to emphasizing that. If we eliminate aiming, we =
obviously need target selection somehow so there would be some sort of =
lock-on system.  Our prototype uses a a simple lock-on system and the =
die hard console FPS players felt it worked well, so I didn't dwell on =
that part of the system.  In our prototype we didn't use aiming, but =
instead weapon selection as the end-game.  It worked well enough, but it =
was tricky to balance to prevent button mashing.  We did it by making =
the damage inflicted relative to the distance and added a reload delay =
so that the closer you were the more damage you inflicted so people had =
to decide who was going to shoot when. I wouldn't classify our game as =
twitch, it's somewhere between a Black and White or MMORPG where you =
choose commands rather than directly attacking (e.g. Star Wars Galaxies) =
but in first-person view.

The bubble idea proposed by Jeremy, if I understood it, might have =
merit.

I find it helps to state the problem another way. FPS games on a PC is =
essentially someone using a mouse (reticle) to click on a moving icon =
(head). A mouse is a great device to do that because we use computers =
every day, a joystick is not. I need a hand-eye coordination activity =
that is more natural with a joystick than a mouse such that even the PC =
version people would want to play with a joystick instead.

The mouse works well because the ratio of real mouse movement on your =
table to the movement of the cursor on the desktop is lower than a =
joystick. Also, the table provides friction to your arm which helps the =
hand smooth the motion and keep it steady. A thumb moving a few =
millimeters does not provide the same stability. Mouse movement is =
exact, joystick movement is spongy at best, jumpy at worst. I find it =
interesting that my mouse can be moved with almost no force at all let =
alone with all the muscles in my hand and fingers to control it, but my =
PS2 thumbstick requires significantly higher force and I only have my =
thumb muscles to do it.

That means I also need something with imprecise control: it can (and =
should?) be fast and the distance to move is small compared to a mouse.  =
So imprecise, fast movment.

Tom, I like the idea you proposed about the bars because you got it back =
to hand-eye coordination, but as you say FPS players may not like it. =
Perhaps it can be packaged in a different way. As Chris Crawford (it was =
him wasn't it?) pointed out in his design book that the basic golf =
interface hasn't changed in years, certainly there's something better =
that can be done.

Brett

Re: [GD-Design] gesturing

[Evan R. <ev...@en...>]

At 11:10 PM 2004.01.05, Brett Bibby wrote:
>Tom, I like the idea you proposed about the bars because you got it back 
>to hand-eye coordination, but as you say FPS players may not like it. 
>Perhaps it can be packaged in a different way. As Chris Crawford (it was 
>him wasn't it?) pointed out in his design book that the basic golf 
>interface hasn't changed in years, certainly there's something better that 
>can be done.

There's a reason that golf interface hasn't change in years -- because it's 
good :-)  When we developed World Tour Golf for EA in ... 1985?, none of 
the three of us had any golf experience.  So we took lessons, and the basic 
mechanic was actually described by our golf pro at the course in 
Novato.  He pointed out that the basics of the golf swing are very simple: 
alignment (which determines the basic direction of club head travel at the 
moment of impact), backswing (and percentage of backswing relates to power 
-- to hit half a wedge you backswing less than your normal full swing), 
pause, downswing, turn the hands over (the timing of turning your hands 
over is critical to hitting a straight shot, slicing or hooking the ball), 
and follow through.  Paul Reiche parsed that into a pre-shot alignment 
(deciding your initial direction of shot), a click to start the backswing, 
a click to end the backswing and start the downswing (and set power), and a 
click to represent turning the hands over.  Paul was the first designer 
that I know of to put this system onto a circular track that mirrored the 
actual clubhead travel.

Is this interface "realistic"?  Not particularly, in that it does not give 
you nearly the level of control over the clubhead travel and therefore the 
shot that a golfer has in real life.  In particular, it completely ignores 
the factor of "in-to-out" or "out-to-in" clubhead travel (which allows a 
golfer to start the ball traveling either to the right or left of the 
alignment track, allowing for deliberate curving around obstacles).  Does 
it relate directly to the motion of a golfer?  Not really.  In particular, 
Paul chose to put the "hands turning over" click essentially at the point 
of impact (it actually starts considerably further back in the downswing) 
because it aligned nicely and gave better feedback to the user for a hook, 
slice, or straight hit.  Does it feel "realistic"?  Damn Skippy, it 
does.  If you provided a speed control that varied the clubhead travel (and 
thus the amount of time the player had to make decisions, effectively 
increasing player precision at low speed and decreasing it at high speed), 
you'd have a huge play balance variation, without changing the mechanic or 
the complexity of the system at all.

If you compare Paul's design to that of previous golf games -- in 
particular Henry's design in ... was it Pebble Beach Championship Golf? A 
game produce with Brian Fargo, IIRC -- Henry's design was very "sim-like" 
in that it gave a huge degree of control through various keystrokes and 
settings, and used a model of Ben Hogan for animation, and it didn't feel 
nearly as much like swinging a golf club.  Activision's game (Links?) used 
a very similar system to Pauls, but it was modelled on a straight line 
(like a progress bar) instead of the clubhead-travel circle.  IIRC, the 
original Nintendo golf game on the 8 bit console was similar.

I'm not trying to say that Paul's design was or is perfect, but I am saying 
that it was at conception and remains an excellent design, and the fact 
that no one has come up with a better one (at least according to Brett's 
recollection of Chris Crawford's comment) suggests that there's more to it 
than just simplicity -- there's also elegance.  Which is hard to beat.

         Evan

Re: [GD-Design] gesturing

[Kimmo V. <kim...@op...>]

>Target selection is a big part of what we want to do, and I should have 
>devoted more time to emphasizing that. If we eliminate aiming, we 
>obviously need target selection somehow so there would be some sort of 
>lock-on system.  Our prototype uses a a simple lock-on system and the die 
>hard console FPS players felt it worked well, so I didn't dwell on that 
>part of the system.  In our prototype we didn't use aiming, but instead 
>weapon selection as the end-game.  It worked well enough, but it was 
>tricky to balance to prevent button mashing.  We did it by making the 
>damage inflicted relative to the distance and added a reload delay so that 
>the closer you were the more damage you inflicted so people had to decide 
>who was going to shoot when. I wouldn't classify our game as twitch, it's 
>somewhere between a Black and White or MMORPG where you choose commands 
>rather than directly attacking (e.g. Star Wars Galaxies) but in 
>first-person view.

I would take the concept of target selection further by basing the game 
more around the idea
of timing and stealth. The player doesn't stay alive by having the best 
eye-hand
coordination in the hood, but by being well aware of the current situation 
and being
nerveless enough not to leap out too soon or too late. Take your favourite 
target
selection system, mix it with auto-aiming controlled by how much time you 
let your
character spend to aiming, and make taking cover a factor, so that there's 
no room for
the potential auto-aim Rambos. Aiming also needs to take longer if you've 
just run
across the room and have otherwise performed acrobatics. I won't go into 
details with the
controller, because each platform needs to be considered separately, but 
the high-level
concept applies to all platforms, including PC.

For instance, Raven Shield on PC was a very pleasant surprise to me as it 
had many of
these features I described above, and I really hoped to see them in Rainbow 
Six 3 for
the Xbox, but unfortunately they were only partially implemented. Yes, the 
game was now
tougher to beat than it would've been otherwise, but that's mainly because 
they didn't make
timing, cover and stealth a big enough factor.

Kimmo 

Re: [GD-Design] gesturing

[Brett B. <res...@ga...>]

Interesting post, and I certainly agree that the interface is elegant =
and nice for some platforms. But given my context is consoles, isn't the =
analog stick a perfect medium to use for a swing in golf on a PS2 or =
other console? IIRC, Tiger Woods Golf PS2 does this now albeit it a =
rubbery way.  It certainly is more intuitive and interactive and rewards =
players with control.  However on a PC I wouldn't want to slide a mouse =
back and then forward to swing; while more interactive and realistic =
that isn't a natural motion and a digital interface would work better.  =
I don't think I would even want to use a joystick (e.g. flightstick) =
either as that is awkward too.  But the thumbstick is perfect.

The point is that just because something works doesn't mean it's the =
best. Instead it means the interface has converged on a solution in its =
local problem space such that all similar solutions are inferior, when =
off in the distance is another space or paradigm with even higher peaked =
(or valleys is you perefer :) solutions.  Digital buttons beget analog =
gauges and it seems silly to use a digital button to do what could be =
directly controlled with tactile hand-eye coordination..

Brett

----- Original Message -----=20
From: "Evan Robinson" <ev...@en...>
To: <gam...@li...>; =
<gam...@li...>
Sent: Tuesday, January 06, 2004 4:27 PM
Subject: Re: [GD-Design] gesturing


> At 11:10 PM 2004.01.05, Brett Bibby wrote:
> >Tom, I like the idea you proposed about the bars because you got it =
back=20
> >to hand-eye coordination, but as you say FPS players may not like it. =

> >Perhaps it can be packaged in a different way. As Chris Crawford (it =
was=20
> >him wasn't it?) pointed out in his design book that the basic golf=20
> >interface hasn't changed in years, certainly there's something better =
that=20
> >can be done.
>=20
> There's a reason that golf interface hasn't change in years -- because =
it's=20
> good :-)  When we developed World Tour Golf for EA in ... 1985?, none =
of=20
> the three of us had any golf experience.  So we took lessons, and the =
basic=20
> mechanic was actually described by our golf pro at the course in=20
> Novato.  He pointed out that the basics of the golf swing are very =
simple:=20
> alignment (which determines the basic direction of club head travel at =
the=20
> moment of impact), backswing (and percentage of backswing relates to =
power=20
> -- to hit half a wedge you backswing less than your normal full =
swing),=20
> pause, downswing, turn the hands over (the timing of turning your =
hands=20
> over is critical to hitting a straight shot, slicing or hooking the =
ball),=20
> and follow through.  Paul Reiche parsed that into a pre-shot alignment =

> (deciding your initial direction of shot), a click to start the =
backswing,=20
> a click to end the backswing and start the downswing (and set power), =
and a=20
> click to represent turning the hands over.  Paul was the first =
designer=20
> that I know of to put this system onto a circular track that mirrored =
the=20
> actual clubhead travel.
>=20
> Is this interface "realistic"?  Not particularly, in that it does not =
give=20
> you nearly the level of control over the clubhead travel and therefore =
the=20
> shot that a golfer has in real life.  In particular, it completely =
ignores=20
> the factor of "in-to-out" or "out-to-in" clubhead travel (which allows =
a=20
> golfer to start the ball traveling either to the right or left of the=20
> alignment track, allowing for deliberate curving around obstacles).  =
Does=20
> it relate directly to the motion of a golfer?  Not really.  In =
particular,=20
> Paul chose to put the "hands turning over" click essentially at the =
point=20
> of impact (it actually starts considerably further back in the =
downswing)=20
> because it aligned nicely and gave better feedback to the user for a =
hook,=20
> slice, or straight hit.  Does it feel "realistic"?  Damn Skippy, it=20
> does.  If you provided a speed control that varied the clubhead travel =
(and=20
> thus the amount of time the player had to make decisions, effectively=20
> increasing player precision at low speed and decreasing it at high =
speed),=20
> you'd have a huge play balance variation, without changing the =
mechanic or=20
> the complexity of the system at all.
>=20
> If you compare Paul's design to that of previous golf games -- in=20
> particular Henry's design in ... was it Pebble Beach Championship =
Golf? A=20
> game produce with Brian Fargo, IIRC -- Henry's design was very =
"sim-like"=20
> in that it gave a huge degree of control through various keystrokes =
and=20
> settings, and used a model of Ben Hogan for animation, and it didn't =
feel=20
> nearly as much like swinging a golf club.  Activision's game (Links?) =
used=20
> a very similar system to Pauls, but it was modelled on a straight line =

> (like a progress bar) instead of the clubhead-travel circle.  IIRC, =
the=20
> original Nintendo golf game on the 8 bit console was similar.
>=20
> I'm not trying to say that Paul's design was or is perfect, but I am =
saying=20
> that it was at conception and remains an excellent design, and the =
fact=20
> that no one has come up with a better one (at least according to =
Brett's=20
> recollection of Chris Crawford's comment) suggests that there's more =
to it=20
> than just simplicity -- there's also elegance.  Which is hard to beat.
>=20
>          Evan
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
> Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D556

Re: [GD-Design] gesturing

[Evan R. <ev...@en...>]

At 01:06 AM 2004.01.06, Brett Bibby wrote:
>Interesting post, and I certainly agree that the interface is elegant and 
>nice for some platforms. But given my context is consoles, isn't the 
>analog stick a perfect medium to use for a swing in golf on a PS2 or other 
>console? IIRC, Tiger Woods Golf PS2 does this now albeit it a rubbery 
>way.  It certainly is more intuitive and interactive and rewards players 
>with control.  However on a PC I wouldn't want to slide a mouse back and 
>then forward to swing; while more interactive and realistic that isn't a 
>natural motion and a digital interface would work better.  I don't think I 
>would even want to use a joystick (e.g. flightstick) either as that is 
>awkward too.  But the thumbstick is perfect.

I see your reasoning, but I have my doubts.  I'm not sure that transferring 
gross muscle movement into identical but micro muscle movement (converting 
the whole body golf swing into a thumb motion with the same path) is a good 
idea.

Obviously we don't want to require users to have some sort of golf-club 
controller that would require them to do a full golf swing.  Not only would 
that require a lot of room (especially overhead), it would limit good 
players to those who play golf well in the "real world", which would remove 
much of the fantasy element of gaming.

Given a good model of a golf shot, it seems to me that we require: aiming 
(which does not have to be in the swing control so we can ignore it); 
strength rating (analogous to the backswing click but having a lot to do 
with clubhead speed at impact); a clubface angle at impact indicator; a 
clubhead travel direction indicator (in-to-out or out-to-in or straight); 
and some edge conditions (topping the ball, hitting the turf before the 
ball, etc.).

Using the thumb to do a three-quarters circle clockwise followed by a 
one-and-a-half circle counter clockwise for a golf swing would have some 
real advantages (now that I think of a model): you get not only backswing 
distance as a judge of strength but also thumbspeed (analogous to club 
speed) at point of impact (6 on an analog clock of which a centered 
joystick is the center); you also could get clubhead direction by using 
some portion of the joystick positioning coming up to impact.  What I don't 
see a way to get is the clubhead angle (analogous to the hands turning over 
click in the conventional interface)...and in many ways that's the most 
"interesting" factor in the swing.

I'm certainly willing to admit that you might have something here.  As I 
said, Paul's interface was not and is not perfect.

My biggest concern with doing a thumbstick swing is balance.  You couldn't 
have a good swing be at the outer edge of travel because that would make it 
too easy and it would be impossible to miss the swing on both 
sides.  Putting the perfect swing somewhere inside the outer edge of travel 
would make it very hard to hit without a really good visual interface.

Hmmmm......How about this?

The visual interface puts a circle in the conventional swing plane 
(clubhead and shoulders define the plane) overlaying the player, with a 
circular indicator in the plane of a perfect swing.  The thumbstick is 
pushed down toward 6 and a dot representing the clubhead moves down until 
it (ideally) overlaps the clubhead.  Then a circular backswing motion is 
initiated, with the dot traveling as the stick moves.  The perfect circle 
matches a path in the overlay and can be missed either inside or 
outside.  Downswing happens the same way.  You get clubhead speed and 
direction of travel from the joystick positioning information.  Assume that 
an out-to-in swing means a closed clubface, and an in-to-out-swing means an 
open clubface (that's generically true, although a good golfer will alter 
the clubface at impact).

That leaves out altering the clubface angle at impact.  You could make the 
initial clubface angle part of the aiming (which is what golfers actually 
do) and use that delta as a delta on the assumed clubface angle at impact 
based upon direction of travel.

I think that does the basics.  And it has a number of advantages that you 
are absolutely right about, not the least of which is that the user can 
sacrifice clubhead speed for swing precision which almost exactly mirrors 
real life golf.

OK, you've sold me.  Code it up and let's see how it works :-)

I have concerns about balance, as I said, but upon further examination 
(much of it happening as I wrote this email), I think you're right.  Thanks 
for the mental kick in the pants.


>The point is that just because something works doesn't mean it's the best. 
>Instead it means the interface has converged on a solution in its local 
>problem space such that all similar solutions are inferior, when off in 
>the distance is another space or paradigm with even higher peaked (or 
>valleys is you perefer :) solutions.  Digital buttons beget analog gauges 
>and it seems silly to use a digital button to do what could be directly 
>controlled with tactile hand-eye coordination..
>
>Brett
>
>----- Original Message -----
>From: "Evan Robinson" <ev...@en...>
>To: <gam...@li...>; 
><gam...@li...>
>Sent: Tuesday, January 06, 2004 4:27 PM
>Subject: Re: [GD-Design] gesturing
>
>
> > At 11:10 PM 2004.01.05, Brett Bibby wrote:
> > >Tom, I like the idea you proposed about the bars because you got it back
> > >to hand-eye coordination, but as you say FPS players may not like it.
> > >Perhaps it can be packaged in a different way. As Chris Crawford (it was
> > >him wasn't it?) pointed out in his design book that the basic golf
> > >interface hasn't changed in years, certainly there's something better 
> that
> > >can be done.
> >
> > There's a reason that golf interface hasn't change in years -- because 
> it's
> > good :-)  When we developed World Tour Golf for EA in ... 1985?, none of
> > the three of us had any golf experience.  So we took lessons, and the 
> basic
> > mechanic was actually described by our golf pro at the course in
> > Novato.  He pointed out that the basics of the golf swing are very simple:
> > alignment (which determines the basic direction of club head travel at the
> > moment of impact), backswing (and percentage of backswing relates to power
> > -- to hit half a wedge you backswing less than your normal full swing),
> > pause, downswing, turn the hands over (the timing of turning your hands
> > over is critical to hitting a straight shot, slicing or hooking the ball),
> > and follow through.  Paul Reiche parsed that into a pre-shot alignment
> > (deciding your initial direction of shot), a click to start the backswing,
> > a click to end the backswing and start the downswing (and set power), 
> and a
> > click to represent turning the hands over.  Paul was the first designer
> > that I know of to put this system onto a circular track that mirrored the
> > actual clubhead travel.
> >
> > Is this interface "realistic"?  Not particularly, in that it does not give
> > you nearly the level of control over the clubhead travel and therefore the
> > shot that a golfer has in real life.  In particular, it completely ignores
> > the factor of "in-to-out" or "out-to-in" clubhead travel (which allows a
> > golfer to start the ball traveling either to the right or left of the
> > alignment track, allowing for deliberate curving around obstacles).  Does
> > it relate directly to the motion of a golfer?  Not really.  In particular,
> > Paul chose to put the "hands turning over" click essentially at the point
> > of impact (it actually starts considerably further back in the downswing)
> > because it aligned nicely and gave better feedback to the user for a hook,
> > slice, or straight hit.  Does it feel "realistic"?  Damn Skippy, it
> > does.  If you provided a speed control that varied the clubhead travel 
> (and
> > thus the amount of time the player had to make decisions, effectively
> > increasing player precision at low speed and decreasing it at high speed),
> > you'd have a huge play balance variation, without changing the mechanic or
> > the complexity of the system at all.
> >
> > If you compare Paul's design to that of previous golf games -- in
> > particular Henry's design in ... was it Pebble Beach Championship Golf? A
> > game produce with Brian Fargo, IIRC -- Henry's design was very "sim-like"
> > in that it gave a huge degree of control through various keystrokes and
> > settings, and used a model of Ben Hogan for animation, and it didn't feel
> > nearly as much like swinging a golf club.  Activision's game (Links?) used
> > a very similar system to Pauls, but it was modelled on a straight line
> > (like a progress bar) instead of the clubhead-travel circle.  IIRC, the
> > original Nintendo golf game on the 8 bit console was similar.
> >
> > I'm not trying to say that Paul's design was or is perfect, but I am 
> saying
> > that it was at conception and remains an excellent design, and the fact
> > that no one has come up with a better one (at least according to Brett's
> > recollection of Chris Crawford's comment) suggests that there's more to it
> > than just simplicity -- there's also elegance.  Which is hard to beat.
> >
> >          Evan
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Gamedevlists-design mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=556
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IBM Linux Tutorials.
>Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
>Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
>Click now! http://ads.osdn.com/?ad_id78&alloc_id371&opick
>_______________________________________________
>Gamedevlists-design mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_idU6

Necessity is the plea for every infringement of human freedom.
It is the argument of tyrants; it is the creed of slaves.
   -- William Pitt, speech to the House of Commons, [Nov. 18, 1783]

Evan Robinson            <http://www.enginesofmischief.com/makers/evan/>
Mischievous Ramblings  <http://www.enginesofmischief.com/blogs/ramblings>
Gallery                        <http://www.enginesofmischief.com/gallery>
Travelblog            <http://www.enginesofmischief.com/blogs/travelblog>