Jump to content
  • Advertisement
Sign in to follow this  
Tristan Patrick Richter

Acceptable resolution for character turning?

This topic is 1517 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What is an acceptable resolution for character turning in a 3D RPG?

 

If the resolution were 4, he could face forwards, right, backwards, and left.

If the resolution were 360, he could face any of 360 directions around him.

 

At what resolution do we stop noticing disjointedness or granularity in turning?

Share this post


Link to post
Share on other sites
Advertisement

Acceptable for what purpose and type of game? There are some popular first-person games that you can only rotate in 90 degree increments - Legend of Grimrock (PC) and Etrian Odyssey (3DS), for example.

 

However, note that they don't instantly jump from 0 to 90, but ease between the two over several frames. So even if you want your game to only have 4, or 8, or 16 different directions to face, your displaying of it to the player can be more finished.

 

This is similar to tile-based games showing the character moving between tiles, but always landing snapped to a single tile.

Edited by Servant of the Lord

Share this post


Link to post
Share on other sites

An MMORPG like WoW or GW2.

 

Is it first person, or third person? Overhead, or over-the-shoulder?

Are you asking what's acceptable, gameplay-wise (if so, how will it affect gameplay?), or what's acceptable visually (if so, what's the rest of the visuals of the game like?)?

 

Why are you asking? Are you wanting to use larger increments of turning, like 90 degrees or 45 degrees, for ease-of-programming, and are trying to justify that choice? Or are you wanting to use larger increments for gameplay-related features?

 

What's "acceptable" depends on the game. Do you have apprehensions about a choice you want to make? If so, what choice, and what apprehensions are you having? And what is the motivations that are leading you to want to make that choice?

 

I noticed you put this under 'Game programming', instead of 'Game design' - is there a programming-related reason why you aren't just using a float with increments between 0.000 and 360?

Edited by Servant of the Lord

Share this post


Link to post
Share on other sites

I'm using 2 bytes for orientation of players in my multiplayer game, this gives you a resolution of 1/182 of a degree, which is more than plenty.

Share this post


Link to post
Share on other sites

I could use a 64 bit double to represent rotation but that'd be a waste of space.

64-bit is overkill. It will be converted to 32-bit for graphics processing anyway (rotation matrices passed to the graphics card are 32-bit). The minimum resolution of 32-bit floating points is 1e-7, IIRC (0.0000001), but it depends how you scale it. If you try to add 1e-8 to a 32-bit float, it will not change. If you use values between 0.0 - 1.0 scaled to 0 - 2*PI, you can rotate your object into 10000000 different directions - more than enough, IMO.

Edited by tonemgub

Share this post


Link to post
Share on other sites

if necessary, heading can be compressed from float (or double) to short or even byte before transmission, as stated above. but you only save 2 or 3 bytes.

 

the whole idea is to send the least data possible, and only when necessary, and THEN compress that (if needed), before transmission.

 

so the client should know an object's heading, and an object should send a "turn" (rotate) message to the clients, who then do the math. packets only get sent when they change heading.

 

if a packet already includes entity type info, and that entity type's turn rate is constant, you can send the data in 2 bits: 00= no turn. 01 = turn left. 10 = turn right. 11= undefined.

 

always send the minimum data possible, and only when you must, and let the client do as much work as possible. then the vast majority of packets will be of the form: timestamp, entity_ID, nochange. or, if you only send change packets (as opposed to state packets), timestamp, entity_ID, change type, value.

 

In a NON-DETERMINISTIC networked startship flight sim i was able to get steady state down to 23 bytes of data per turn (for the ENTIRE simulation).

 

in short: its often less data transmitted if you tell the client what to do, when it needs to be done, rather than telling the client the results of doing something every turn.

 

what to do can often take less data to send than sending the result of doing that something. and only sending state changes, as opposed to sending current state every turn reduces the number of packets transmitted when things don't change.

 

what this boils down to is you basically want to send inputs (turn left, move forward etc, perhaps sent as a single byte), rather than results like new x,y,z,xr,yr, and zr (6 floats).

 

for minimal network lag, you should never transmit anything the client can figure out for itself.

 

in the particular case of a 3D RPG, you'd send a new heading only when it changed. you could send the new heading, or the turn amount, whichever is smaller.

 

you'd need to transmit 4 bits per turn for movement (0 thru 9 = no move, or one of the 8 cardinal directions). the client could figure it out from there.

 

for attacks, if the game is determinisitic, you can just send 1 bit for they attacked or not, and let the client resolve it and be guaranteed the server result will be the same. if its non-deterministic, you'll need to send damage and hit location, along with any critical hit type results. 

Edited by Norman Barrows

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!