Jump to content
  • Advertisement
Sign in to follow this  
Win32

RFC: Design

This topic is 3638 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

Greetings, I'm in the process of designing an isometric, dungeon-roaming MMORPG (I'm sure this is nothing new here :) primarily as a personal challenge and to broaden my, somewhat lacking in variety, field of interest in programming (Systems). Since I'm relatively new to the field of game programming I would like your input on my design, however critical such may be. (Albeit not game-wise, I've been programming [C++/Asm/Others] for ~8 years) To the point. The world shall be represented as a two-dimensional grid of cells; a cell is precisely 16x16 pixels, measured isometrically in the 2:1 projection scheme. A cell itself is the smallest unit of space that is taken into account for collision detection, and with that said, each object within the world is described initially by a bounding box of cells, and if required, each cell flagged as being a part of the object's footprint or not. Furthermore, in pondering upon how to manage velocity, I figure that I can sacrifice the low byte of each world coordinate (a 32-bit word) to be a sort of 'precision', in that the low byte is used as a fractional measurement of a cell and thus allowing for velocity to be specified in 256th's of a cell (hopefully that makes sense) As far as I can tell, the only actual physics concepts I need implemented is velocity. Although, there is one issue that has been pestering me in regards to collision detection and that is due to my decision to use a constant physics timestep (Graphics shall be free); namely the problem which arises when objects travel faster than 1 cell per sampling which could possibly lead to a missed collision detected. I've thought of things like simply increasing the size of a cell, but I'm convinced that's me avoiding the problem. Maybe someone could shed some light on this for me? Any input you have is appreciated, and I thank you for taking the time to read this.

Share this post


Link to post
Share on other sites
Advertisement
You could do a sweep test to see if an objects trajectory has been intersected by collision objects. If it has been intersected, find out where the first intersection occurred and place your moving object at that position.

Share this post


Link to post
Share on other sites
Quote:
Original post by Win32
Furthermore, in pondering upon how to manage velocity, I figure that I can sacrifice the low byte of each world coordinate (a 32-bit word) to be a sort of 'precision', in that the low byte is used as a fractional measurement of a cell and thus allowing for velocity to be specified in 256th's of a cell (hopefully that makes sense)


This is called fixed-point arithmetic.

Quote:
As far as I can tell, the only actual physics concepts I need implemented is velocity. Although, there is one issue that has been pestering me in regards to collision detection and that is due to my decision to use a constant physics timestep (Graphics shall be free); namely the problem which arises when objects travel faster than 1 cell per sampling which could possibly lead to a missed collision detected. I've thought of things like simply increasing the size of a cell, but I'm convinced that's me avoiding the problem. Maybe someone could shed some light on this for me?


There are many techniques for this. You can either decrease the timestep so that no cells are skipped (and you can do this dynamically so that you don't waste time with timesteps that are too slow), or you can use swept areas by remembering all traversed cells on a given move.

Share this post


Link to post
Share on other sites
Thankyou for your replies.


Quote:

This is called fixed-point arithmetic.

I know :)

Quote:

There are many techniques for this. You can either decrease the timestep so that no cells are skipped (and you can do this dynamically so that you don't waste time with timesteps that are too slow), or you can use swept areas by remembering all traversed cells on a given move.

I do plan to have a configurable timestep, but I don't feel it's practical to rely on it. With these 'swept areas', how would I go about implementing it?

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!