Jump to content

  • Log In with Google      Sign In   
  • Create Account

Norman Barrows

Member Since 04 Apr 2012
Offline Last Active Yesterday, 06:32 PM

Topics I've Started

Realistic PC movement in 1pv/3pv games

12 June 2014 - 12:38 PM

Realistic PC movement in 1pv/3pv games


its time for me to make some improvements to the basic movement code in Caveman 3.0:





8 directions of movement (forward, back, left, right, and diagonals),


3 movement speeds (walk, run, sprint),


and 2 movement modes (normal and stealth mode),


what combos of the above are realistic?


note:  left means sidestep left, right means sidestep right, back means walk / run / sprint backwards.


the actual speeds of walk, run, and sprint would be modified by things like fatigue, encumbrance, damage, slowing effects, etc.


while you can side step, its not as fast as walking forward. you can side step fast - about as fast as walking forward - but trying to sidestep even faster usually results in tripping. same idea for walking/jogging/running backwards (try it!  but be careful!).



for non-stealth movement, i'm thinking:


* you can walk, run, or sprint forward.

* you can sidestep left and right or walk backwards at 1/2 your forward movement speed, but no sprinting.

* forward diagonal speed should be 3/4 of forward speed, and you can sprint.

* backward diagonal speed is 1/2 of normal speed, and you cant sprint.


i'm thinking that for stealth mode, you should only be able to move at 1/2 speed forward, 3/8 speed forward diagonal, and 1/4 speed in all other directions, no sprinting.  


once all this is determined, then the slope of the ground in the direction of movement would be applied to speed up or slow down the PC some.


I already do this, but based on the slope ahead, not in the direction of movement. 


modeling the players horizontal velocity and applying accel/decel for slope, movement, and drag/inertia would work even better. then you'd need some time to come to a stop when running down a big hill.


right now, i simply apply both left/right and forward/back movements, resulting in unrealistically fast diagonal speeds. fixing that, and speed based on slope in direction of travel, not direction of view, is what prompted me to update the movement code. so i figured that while i'm at it i ought to try to get it a realistic as possible.


so what seems most realistic?










Call for opinions: handling player death in a tutorial

01 May 2014 - 06:03 PM

Call for opinions: handling player death in a tutorial.


gametype: fps/rpg/person sim.


but the question could apply to many types of games: fps, side scroller, arcade, rts, etc.


so, how to handle player death in the tutorial?


autosave points? 


remove badguys and continue where they died?


start tutorial over?







multiple resolutions, multiple monitor aspect ratios, and non-square pixels

25 April 2014 - 12:43 PM

multiple resolutions, multiple monitor aspect ratios, and non-square pixels


i'm adding support for different resolutions to my current project.


this means i've been playing with the parameters for the projection matrix (width, height, fov, aspect ratio).


width and height will depend on the resolution chosen (automatically or by the user).


i played around with fov and aspect ratio, then set them back to the original values of 45 degrees and 16:9.


but how do i deal with monitors whose physical aspect ratio differs from that of the current resolution?


locking the projection aspect ratio at 16:9 vs width/height fixed stretching of the 3d scene when going from 1600x900 to 1024x768


i'm using device independent versions of blit, getmouse, and putmouse. fonts use blit, so they got a free ride.


so everything has ported nicely, in just a day. thank god for global search and replace.


but while playing with the projection matrix, i got back into trying to make it more like human vision. as a result i started experimenting with letterboxing the scene to a 3:1 or 2:1 aspect ratio.


this is when i hit the problem of monitor aspect ratio vs resolution aspect ratio. whent hey're not the same, pixels aren't sqaure. and it makes it hard to letterbox to an aperature that is twice as wide as it is tall. the aspect ratio of the monitor is required.


widescreen monitors are a related issue.


any good way to deal with all this to get the same thing on all monitors at all resolutions?


i've been working at 1600x900 on a monitor with (apparently) square pixels, but am now adding support for other resolutions. 


from searches here, it appears that getting the actual correct monitor aspect ratio is somewhat hit or miss, with a registry inquiry the most likely to succeed (but perhaps still not guaranteed correct?). and "pick a size" on a graphics settings menu is a typical approach. with options like 4:3, 16:9, 5:4, 16:10, etc


once i have both the monitor and resolution aspect ratios, i should be able create a letterbox aperature whose height is half its width on any monitor at any resolution. 



another approach is "why bother?" and i may end up settling for that. but i'm not really interested in such responses, so please don't waste you time.

How far can you see something?

16 April 2014 - 10:52 AM

How far can you see something?


I know it seems like a silly question, but...


i find myself asking this question often, especially when thinking about distance scales to use in a new title.  so whether its a person, a building, an airship, or a planet, how far can you see something?


it seems to me that there should be some pretty straightforward formula or rule of thumb approximation for:


given an object [sphere] of radius R, how far away must it be before it should no longer be drawn?


keep it generic, in d3d units.


so if my sphere is at: range = 1, it appears to be almost 2R wide. at some distance: range = D, it appears to be about 2R/D wide. correct?


so when D gets big enough that 2R/D is so small its not worth it (given screen rez etc), you should no longer draw it, correct?


and you could plug in your horizontal and vertical resolutions and solve for 2R/D=1 pixel (or < 1 pixel), correct?


does this make sense?


how do YOU figure out what is big enough / close enough to be drawn? 






camera relative coordinates and setting the camera

16 April 2014 - 10:37 AM

I'm starting work on the 8th version of SIMSpace, my starship flight sim.


the game world will be a cube, 200 trillion kilometers across.


needless to say, this won't fit in a float for directx.


so i've settled on using an _int64 to store decimeters for world coordinates.


to draw, everything will need to be camera relative.


so this means all i have to do is put the camera at the origin, rotate it, then translate everything else in view relative to the camera (the origin) before drawing, right?


IE its ok to put the camera at the origin, and move everything else relative to that point? after all, its all relative, motion is relative...