gamedevlists-design Mailing List for gamedev (Page 2)
Brought to you by:
vexxed72
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(1) |
Nov
(37) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(15) |
Jul
(38) |
Aug
|
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
2003 |
Jan
(6) |
Feb
(60) |
Mar
|
Apr
(41) |
May
|
Jun
(3) |
Jul
(19) |
Aug
(15) |
Sep
|
Oct
(11) |
Nov
|
Dec
(12) |
2004 |
Jan
(15) |
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
(9) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
|
2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Brian H. <ho...@py...> - 2004-03-29 04:43:15
|
A brief write up on online economies, specifically the role of currency. = I'm doing a series of articles on these, primarily so I can gather my= thoughts on a lot of issues. These are intended to be "survey" type= articles instead of "how to" articles -- the latter is kind of hard to do= since no one has built a fully functional and stable online economy =3D) http://www.bookofhook.com/Article/GameDesign/TheDesignofOnlineEconomie-3.htm= l Brian |
From: Brian H. <ho...@py...> - 2004-03-19 22:15:48
|
I did a brief write up on save systems, others here may be interested in it: http://www.bookofhook.com/Article/GameDesign/TheZenofSavePoints.html |
From: Evan R. <ev...@en...> - 2004-01-07 17:29:50
|
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> |
From: Kimmo V. <kim...@op...> - 2004-01-07 08:43:53
|
>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 |
From: Brett B. <res...@ga...> - 2004-01-06 09:05:38
|
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 |
From: Evan R. <ev...@en...> - 2004-01-06 08:27:57
|
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 |
From: Brett B. <res...@ga...> - 2004-01-06 07:09:17
|
> 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 |
From: Mike W. <mi...@ge...> - 2004-01-06 06:40:21
|
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 > > |
From: Tom H. <to...@ve...> - 2004-01-06 06:30:46
|
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 |
From: Jeremy V. <ma...@ma...> - 2004-01-06 06:17:50
|
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 |
From: Tom H. <to...@ve...> - 2004-01-06 04:40:57
|
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 |
From: Mike W. <mi...@ge...> - 2004-01-06 04:13:11
|
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 |
From: Brett B. <res...@ga...> - 2004-01-06 02:22:10
|
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 |
From: Brian H. <ho...@py...> - 2004-01-05 15:44:39
|
> One thing that might be of relevance is for military training > simulations researchers discovered that is was better to train > pilots on faster than real time simulations i.e. +20% time speed > up. That's a really good analogy, similar to when a batter is practicing with weights/multiple bats to make his bat feel lighter when he's at the plate. Your Mario Kart example is also dead on for what I'm talking about -- you're used to seeing things at relatively fast speed, so when it slows down it feels very, very slow. But for a new player, it's often still hectic (although I think in MK:DD's case, the difference between 50 and 150cc probably isn't enough). Brian |
From: Jacob T. \(C. D. Ltd\) <Ja...@Co...> - 2004-01-05 09:13:54
|
One thing that might be of relevance is for military training = simulations researchers discovered that is was better to train pilots on = faster than real time simulations i.e. +20% time speed up. Then when = the pilots came to do the same thing in real time in the real world they = found it so much easier because everything seemed so slow. But also of = interest I think the researchers discovered that the super speed = training had to be repeated more often because the brain adjusted to the = slower real time events quickly. I had just had the same experience with Mario Kart. After doing a lot = 150cc racing, I then went back to 50cc racing and it just seemed so = slow. I would guess about half the perceived speed but it isn't half = the speed in reality ! Jake -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Brian Hook Sent: 24 December 2003 22:06 To: gam...@li... Subject: [GD-Design] Speed kills After talking to some friends about different games and their=20 respective designs, I realized something that is obvious in hindsight=20 -- game speed controls difficulty almost exclusively, at least in=20 action games. This means fighting games, shooters, platformers, you=20 name it. The slower the game is, the easier it is. In fact, this is so obvious that several games have used slow-mo as a=20 power up -- Max Payne 1/2, PoP, and Viewtiful Joe. And yet games today still insist on using the most idiotic variables=20 to control difficulty. From the immensely stupid "number of saves" of=20 Hitman 2, to the standard fare like "enemy damage", "hitpoints",=20 "health and ammo availability", they never just adjust the speed of=20 the game to match the response/reaction capabilities of a typical=20 player. And that's really what separates great action players from mediocre=20 ones, their recognition, decision making and response. The one game that could be improved the most with this is Madden 2004.=20 Instead of just affecting the speed of the game by, say, -40%, -25%=20 and 0%, and keeping everything else constant, they tweak a bunch of=20 variables that make it tough for a Rookie player to advance to=20 All-Pro, because the crutches they had on Rookie disappear. In fact, in the NFL it's even an adage that the difference between an=20 experienced player and a rookie is that "the game slows down" for the=20 experienced player. This is also true of full contact sparring --=20 experienced fighters "see" the fight at a much slower rate than=20 someone who isn't used to fighting. Would Soul Calibur be more approachable if there was a novice setting=20 that simply moved 25% slower? I would argue "hell yes". Obviously there are "fun factor" issues to consider, like obviously=20 don't make it slow ALL the time, but the general notion is there. -Hook ------------------------------------------------------- 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_id371&op=3Dick _______________________________________________ Gamedevlists-design mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-design Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU6 |
From: Cruise <cr...@ca...> - 2004-01-02 00:56:23
|
I agree with the general principle, but, "all generalisations are false", and there are certainly a few exceptions. Beat-em-ups spring to mind straight off - while, yes, Soul Caliber would be easier if the game was slowed down, the gameplay does change with a slower game. Compare the first few Tekken games to one of the many Hyper-super-duper streetfighters...because of the sheer speed of the latter, any real planned strategy becomes impossible. Basic responses (opponenet in air, use high attack, etc.) are fine, but not the tactical waiting game Tekken was, with specific counter-(and counter-counter-)attacks. While not all of this is due to the speed, a large proportion of it is. Some gameplay choices and tactics do become impractical with differing speeds. I guess it just boils down to moderation - changing anything enough will have an effect on the gameplay. Conversely, most variables can probably be changed without having an affect on the gameplay if changed subtley. So yeah, I agree that speed is an often, and very useful, method of adjusting difficulty. But so are lots of other things if used /correctly/. -- "quantam sufficit" [ cruise / casual-tempest.net / transference.org ] |
From: Cruise <cr...@ca...> - 2004-01-01 23:48:42
|
Neil Stewart wrote: > It is conceivable that you can devise the implants such that an expert can > get better results by doing everything manually if he is skilled enough to > do so. The example of automatic gear changing is a good one; racing games > generally make the automatic changes slightly less optimal than well-timed > manual ones, so experts can achieve slightly better acceleration. If you > manage to make all your implants have this property, then you could have > novices and experts playing together without any problems. The experts would > probably still win, but the game would be more competitive. Agreed - this method can be extended to lots of things. Auto-aiming, for example, can be made somewhat innaccurate (always aims for the torso, perhaps), so that a good player with manual aiming still has an advantage. Auto-blocking in a beat-em-up, but that doesn't fully prevent the damage (or, better, prevent more damage the better the timing of the block - sliding scales rather than on-offs are always better). Generally, having a choice of easy-but-not-so-effective or hard-but-more-successful abilities is an excellent way to level the playng field. > I'm sure a lot of people will argue that the simplest way to solve > difficulty in multiplayer games is to keep people of wildly differing > abilities apart, which seems to work well on Xbox Live. The trouble with that is players who go up a level suddenly go from "being amongst the best" to "being one of the worst", which can be a nasty and unpleasant jump. > In single player games, no-one is being "cheated" (unless you are comparing > scores, which makes it a kind of poor man's multiplayer game), so you can > adopt whatever method you think will give the novice the better experience. > > - Neil. > > > > > ------------------------------------------------------- > 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 > -- "quantam sufficit" [ cruise / casual-tempest.net / transference.org ] |
From: George W. <ge...@ap...> - 2003-12-29 05:38:13
|
Hey Brian, I agree 100% with what you're saying. Personally, I'd love a speed slider in almost all the games I (try to) play. I've long fell off the 17 to 35 demographic and just can't play the twitch games like I used to. Of course this won't help with multi-player (net) games where each player most likely has different response times. (I'm just screwed there. ;-) But for single player games it would be great. ;-) This reminds me of two hardware hacks we did way back when. Tweaking the speed (and paddle sizes) in the original PONG and the "slow-motion" NES controllers that would hit the start button twice at a variable rate to slow down game play. ;-) -- Enjoy, George Warner, Schizophrenia Optimization Scientist Apple Developer Technical Support (DTS) |
From: Neil S. <ne...@r0...> - 2003-12-28 16:34:41
|
> Most MMOG's hover almost at a on most aspects, so that your > enjoyment is tightly bound to how long you spend playing the > MMOG (and hence how much subscription revenue the owner > extracts from you). I think multiplayer games (RPG or otherwise) have a much more difficult decision to make in this area because, if you allow novices to compete with experts by using "implants" (to continue the cyborg analogy), the experts will want some kind of retribution; for example, a handicap on the final score for those using implants, based on the level of implants used. So you've bought yourself the ability to level the playing field, but you're paying for it in terms of a more complex scoring system. This might not be all that bad, but it's worth keeping in mind when adopting something like this. It is conceivable that you can devise the implants such that an expert can get better results by doing everything manually if he is skilled enough to do so. The example of automatic gear changing is a good one; racing games generally make the automatic changes slightly less optimal than well-timed manual ones, so experts can achieve slightly better acceleration. If you manage to make all your implants have this property, then you could have novices and experts playing together without any problems. The experts would probably still win, but the game would be more competitive. I'm sure a lot of people will argue that the simplest way to solve difficulty in multiplayer games is to keep people of wildly differing abilities apart, which seems to work well on Xbox Live. In single player games, no-one is being "cheated" (unless you are comparing scores, which makes it a kind of poor man's multiplayer game), so you can adopt whatever method you think will give the novice the better experience. - Neil. |
From: <ham...@tm...> - 2003-12-28 14:50:35
|
> From: "Neil Stewart" <ne...@r0...> > Subject: RE: [GD-Design] Speed kills > helpers. By selecting the right number of helpers, novices can give > themselves just the right number of things to deal with, so that they can > drive a good lap, at full game speed, without becoming overloaded and > confused. > > You might argue at this point that this is no different to changing the > number of hits it takes to kill a monster or similar game rule changes, but > I think it is. Rather than changing the physics of the world or giving the > player more ammo/health, we leave the game world alone and simply help the > player overcome his limit on the number of things he can deal with at once. > In this sense, it is more similar to the global speed change than it is to > arbitrary game rule changes. > ... > You also don't have to limit yourself to "input helpers" like the Formula 1 > game. Anything which removes conscious thinking from the player will help > him deal with more things at once so, for example, Quake could have a "map > helper" that shows the player where he is and gives him advance warning of > armour/weapons that are about to spawn, both things that would take up quite > a lot of his "conscious runtime" if he were to do them himself. > The "Cyborg" approach to game difficulty :)...amake use of the human-player / in-game avatar interface to artificially enhance (or degrade) the abilities of the "player" (as observed by other players in the game - i.e. the composition of human and avatar). For followups, people might want to check out MUD / MMOG / RPG discussion lists, where the issue often comes up; e.g. should player abilities in an MMORPG be a) 100% due to levelling treadmill b) somewhere in between c) 100% due to human skill (obviously each aspect of the player is usualluy discussed separately, e.g. "vision" (should we let this playe see through walls / have infra-vision / etc), "speed", "tactical reasoning" (difficult to provide programmatically, but not impossible), etc. Most MMOG's hover almost at a on most aspects, so that your enjoyment is tightly bound to how long you spend playing the MMOG (and hence how much subscription revenue the owner extracts from you). Adam M |
From: Brian H. <ho...@py...> - 2003-12-28 05:00:42
|
> What I'm not so sure about is the idea of just using a global time > slider, because I think there are more fundamental reasons why the > player's perception of of the game is affected by the game's speed > than the speed itself, and I wonder if there are ways to exploit > them to better effect. I'm not sure if I'll be able to articulate > what I mean by this, but I'll give it a go. ;) You could think of this as a balance of time vs. number of actions required to perform in that period of time. If you have a cost function that returns the amount of time a player needs to successfully hand a situation S, cost(S) then: if t < cost(S) player.overwhelmed =3D 1; So you can balance this by reducing the cost function, which usually means lowering the complexity. In the NFL, a rookie quarterback usually has the game plan simplified immensely so that he doesn't have to process as much information. Instead of trying to read 5 receivers, he's given two receivers. As he becomes more comfortable (and the game slows down) he adds more receivers to his responsibilities. > If you reduce the speed of the game enough, the novice's > timeslicing should become nearly as effective as an expert's > subconscious, simultaneous approach, making the gulf between the > two much smaller. Right, that's the central point of my thesis. > Of course, this assumes that the expert cannot > also take advantage of the drop in speed to exploit higher-level > tactics or whatever. Sure, but that's a tangential thing. > So, although reducing speed will help the novice greatly, so would > reducing the amount of stuff he has to timeslice through. Exactly, you're talking about reducing the cost function. This ties into something I call the Law of Incremental Complexity, which I stumbled upon while playing yet another game with an incredibly bad tutorial/learning system. When teaching people something, there is a set pattern that makes them comfortable. Language (human) researchers know this. Ironically enough, I stumbled upon this in the 20th Anniversary Mythical Man-Month: "We need research to appropriate for the software reuse problem the large body of knowledge as to how people acquire language. Some of the lessons are immediately obvious: * People learn in sentence contexts. * People do not memorize anything but spelling. They learn syntax and semantics incrementally, in context, by use * People group word composition rules by syntactic classes not by compatible subsets of objects" This also applies to learning software, math or anything else with a large vocabulary. Games have a vocabulary as well, in terms of the things that can be done (such as input) and the various interactions with subsystems in the game. Educating a user about this vocabulary is tricky, and nearly every single game today I've played gets it completely wrong. They start with an out-of-context tutorial, at which point they expect the player to know all the subtleties and nuances of the game before they've started their first real mission. The few games that have got this right are No One Lives Forever 2, Advance Wars (GBA) and Fire Emblem. Games that have got this aggressively wrong are any with an explicit tutorial THEN the game. Okay, come back from tangent, sorry =3D) > I think we have seen a very simple example of this in action in > racing games, where you can usually select an automatic gearbox, > removing one thing the player has to think about: changing gears at > the right time. Exactly. But this is managing complexity, not managing difficulty. I am all for incrementally increasing the complexity of a game to match the user's expected skill and experience. That's fine, that's great. I am fine with changing first-order features, such as the gearbox, to manage complexity and, by extension, difficulty. > You might argue at this point that this is no different to changing > the number of hits it takes to kill a monster or similar game rule > changes, but I think it is. I agree, it is rather different and completely acceptable. I agree it's a fine line, and quantifying the difference between an automatic gearbox and, say, more enemies is an interesting exercise. Brian |
From: Hakan Y. <hak...@3t...> - 2003-12-27 23:55:08
|
"But you didn't address my fundamental point, which is that when reflexes do matter, controlling the game's overall speed can have a drastic effect on difficulty." Speed may be used in some games to make it easier or harder. But I dont think its a key factor and it shouldnt be used as a key factor. It doesnt add much to the game. It may make the game difficult or meaningless to play furter, not challenging. Increasing the speed of some events of reflex based games may make the game challenging, but there is a very limited usage and limited effect. I think it doesnt have a drastic effect as you say. .............(your examples) Of course it will be harder to react in shorter times but it will be boring to play. Because theres nothing new. You just became faster. "Obviously these situations are not the ONLY factors, but speed is a fundamental control on the difficulty of play in games, and yet it's widely ignored except as the occasional powerup." I disagree that "speed is a fundamental control on the difficulty", because other aspects are much more important than the speed(they are much more meaninful). But I agree that its not used widely. Some action games may use speed parameter. ---------------------------------------------------------------------------- Hakan Yuksel (There is a problem with my mail server.So I send this mail again. I am sory if you receive again) ----- Original Message ----- From: "Brian Hook" <ho...@py...> To: <gam...@li...> Sent: Saturday, December 27, 2003 6:34 PM Subject: Re: [GD-Design] Speed kills Hakan, > My result is changing the speed will not make a game harder or > easier most of the time(Maybe in a few games it can make). But that's not what your post was really saying. You're arguing that games can be improved in other areas to make them more challenging, which I agree with. You also assert that even action games have strategic elements to them which matter as much as reflexes, which I also agree with. But you didn't address my fundamental point, which is that when reflexes do matter, controlling the game's overall speed can have a drastic effect on difficulty. If you have five seconds to aim and fire, you will almost always be more successful than if you have 0.2 seconds. If you can run towards the edge of a platform but it feels like you're walking, the odds of missing that jump are greatly reduced. If you can see that barrier on the race track with 3 seconds to react instead of 0.3, you will almost definitely avoid it. If an enemy's punch takes 3 seconds to land instead of 0.1 seconds, you should definitely block or dodge it. Obviously these situations are not the ONLY factors, but speed is a fundamental control on the difficulty of play in games, and yet it's widely ignored except as the occasional powerup. Brian ------------------------------------------------------- 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&op=ick _______________________________________________ Gamedevlists-design mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-design Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU6 |
From: Hakan Y. <hak...@3t...> - 2003-12-27 19:14:29
|
"But you didn't address my fundamental point, which is that when reflexes do matter, controlling the game's overall speed can have a drastic effect on difficulty." Speed may be used in some games to make it easier or harder. But I dont think its a key factor and it shouldnt be used as a key factor. It doesnt add much to the game. It may make the game difficult or meaningless to play furter, not challenging. Increasing the speed of some events of reflex based games may make the game challenging, but there is a very limited usage and limited effect. I think it doesnt have a drastic effect as you say. .............(your examples) Of course it will be harder to react in shorter times but it will be boring to play. Because theres nothing new. You just became faster. "Obviously these situations are not the ONLY factors, but speed is a fundamental control on the difficulty of play in games, and yet it's widely ignored except as the occasional powerup." I disagree that "speed is a fundamental control on the difficulty", because other aspects are much more important than the speed(they are much more meaninful). But I agree that its not used widely. Some action games may use speed parameter. ---------------------------------------------------------------------------- -- Hakan Yuksel ----- Original Message ----- From: "Brian Hook" <ho...@py...> To: <gam...@li...> Sent: Saturday, December 27, 2003 6:34 PM Subject: Re: [GD-Design] Speed kills Hakan, > My result is changing the speed will not make a game harder or > easier most of the time(Maybe in a few games it can make). But that's not what your post was really saying. You're arguing that games can be improved in other areas to make them more challenging, which I agree with. You also assert that even action games have strategic elements to them which matter as much as reflexes, which I also agree with. But you didn't address my fundamental point, which is that when reflexes do matter, controlling the game's overall speed can have a drastic effect on difficulty. If you have five seconds to aim and fire, you will almost always be more successful than if you have 0.2 seconds. If you can run towards the edge of a platform but it feels like you're walking, the odds of missing that jump are greatly reduced. If you can see that barrier on the race track with 3 seconds to react instead of 0.3, you will almost definitely avoid it. If an enemy's punch takes 3 seconds to land instead of 0.1 seconds, you should definitely block or dodge it. Obviously these situations are not the ONLY factors, but speed is a fundamental control on the difficulty of play in games, and yet it's widely ignored except as the occasional powerup. Brian ------------------------------------------------------- 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&op=ick _______________________________________________ Gamedevlists-design mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-design Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU6 |
From: Neil S. <ne...@r0...> - 2003-12-27 18:02:51
|
> I just did a slightly more cohesive write up on this, in case > anyone is interested: > > http://bookofhook.com/Article/GameDesign/SpeedKills.html Hi Brian, I think the overall idea of how fast the player perceives things to be happening is pretty spot on, and it certainly applies to a much wider range of games than people might think. Any game where time is a factor will be affected by this, although obviously to varying extents. What I'm not so sure about is the idea of just using a global time slider, because I think there are more fundamental reasons why the player's perception of of the game is affected by the game's speed than the speed itself, and I wonder if there are ways to exploit them to better effect. I'm not sure if I'll be able to articulate what I mean by this, but I'll give it a go. ;) If you imagine a game where there are, say, 10 things the player has to be doing at the one time, e.g. moving, shooting, outsmarting his opponent, timing moving platforms and powerups, etc., not only does he have to be able to do all these things, but he has to be able to do several of them simultaneously. When you're doing something that has become second-nature (either through practice or natural skill), dealing with 10 different aspects of it at the same time also becomes natural. If you have to think about any of these aspects at a conscious level, your ability to multitask is far more limited. Now, if we assume that a novice player is doing almost everything consciously, he would have to 'timeslice' through them if he were to do them all, which will be very difficult and much slower than if he were doing them subconsciously and simultaneously. In games where he can simply not do some of them (e.g. positional tactics in Quake), he will generally take this option just to give him a chance of performing the essential tasks with any skill. In simpler games where none (or few) of the tasks are optional, he will feel overloaded and find it difficult to do even the most basic things a lot of the time. If you reduce the speed of the game enough, the novice's timeslicing should become nearly as effective as an expert's subconscious, simultaneous approach, making the gulf between the two much smaller. Of course, this assumes that the expert cannot also take advantage of the drop in speed to exploit higher-level tactics or whatever. So, although reducing speed will help the novice greatly, so would reducing the amount of stuff he has to timeslice through. I think we have seen a very simple example of this in action in racing games, where you can usually select an automatic gearbox, removing one thing the player has to think about: changing gears at the right time. Formula 1 games take this a bit further by providing automatic braking and other such helpers. By selecting the right number of helpers, novices can give themselves just the right number of things to deal with, so that they can drive a good lap, at full game speed, without becoming overloaded and confused. You might argue at this point that this is no different to changing the number of hits it takes to kill a monster or similar game rule changes, but I think it is. Rather than changing the physics of the world or giving the player more ammo/health, we leave the game world alone and simply help the player overcome his limit on the number of things he can deal with at once. In this sense, it is more similar to the global speed change than it is to arbitrary game rule changes. The advantages this has over a global speed change are that it is compatible with multiplayer games and doesn't suffer from the sluggish feel that a global speed change might introduce. Having said that, the global speed change can be very effective and is simple to implement, so I do think it has its place, and it may be that it combines very well with helpers so that you can get a nice tradeoff between the game speed and the level of help you need to give the player. You also don't have to limit yourself to "input helpers" like the Formula 1 game. Anything which removes conscious thinking from the player will help him deal with more things at once so, for example, Quake could have a "map helper" that shows the player where he is and gives him advance warning of armour/weapons that are about to spawn, both things that would take up quite a lot of his "conscious runtime" if he were to do them himself. There are probably lots of examples of this type of thing actually working in games already. All I'm really suggesting is a more specific approach to coming up with these things, while avoiding things that can fundamentally change the gameplay. Hope that made some sense... ;) Cheers, - Neil. |
From: Brian H. <ho...@py...> - 2003-12-27 16:35:32
|
Hakan, > My result is changing the speed will not make a game harder or > easier most of the time(Maybe in a few games it can make). But that's not what your post was really saying. You're arguing that games can be improved in other areas to make them more challenging, which I agree with. You also assert that even action games have strategic elements to them which matter as much as reflexes, which I also agree with. But you didn't address my fundamental point, which is that when reflexes do matter, controlling the game's overall speed can have a drastic effect on difficulty. If you have five seconds to aim and fire, you will almost always be more successful than if you have 0.2 seconds. If you can run towards the edge of a platform but it feels like you're walking, the odds of missing that jump are greatly reduced. If you can see that barrier on the race track with 3 seconds to react instead of 0.3, you will almost definitely avoid it. If an enemy's punch takes 3 seconds to land instead of 0.1 seconds, you should definitely block or dodge it. Obviously these situations are not the ONLY factors, but speed is a fundamental control on the difficulty of play in games, and yet it's widely ignored except as the occasional powerup. Brian |