Jump to content

  • Log In with Google      Sign In   
  • Create Account


simonlourson

Member Since 27 Mar 2008
Offline Last Active Jul 23 2013 03:13 AM
-----

Posts I've Made

In Topic: How to implement a circular buffer of previous gamestates

17 June 2013 - 01:48 AM

Thank you for the very good advice !


In Topic: Item system without database software

26 August 2010 - 09:51 PM

Why would you not want to use a DB? There are some very good free ones, PostGre, MySQL, and even Oracle has an express version.

You could code something using files, but it would probably end up way slower, and more complicated than using a database.

Also, what language are you using?

In Topic: Best inventory solution

19 August 2010 - 04:54 AM

It seems you did not read my post until the end; quoting myself:

Quote:
Original post by simonlourson
Then you don't have to have a class per different object, of course. Your "Uzi" class would be the same as your "M16" class, with different parameters (a different model, diffrent sprite, different stats (firing rate, damage, and even customized names)


So in your case, you would have about 20 different classes, one for each functionality, but these classes can be have different parameters for each instance, wether it is, in my example, a M16, or a Uzi.

In Topic: Best inventory solution

18 August 2010 - 10:45 PM

Why not use an OO approach?

You could have abstract classes like "fruit", "clothes", "weapon", and then derive the class "apple", "banana", "shirt", "shoes" from these.

With polymorhism, you could have one "UseItem" function, that coud have different code wether it's a weapon or a fruit.

Then you don't have to have a class per different object, of course. Your "Uzi" class would be the same as your "M16" class, with different parameters (a different model, diffrent sprite, different stats (firing rate, damage, and even customized names)

Also, use enums, not directly ints for your IDs.

In Topic: Interpolation vs Client side prediction

15 August 2010 - 10:26 PM

Quote:
Original post by fenghus
Interpolation for proxies, ie. objects not controlled by the player, is fairly straight forward and it sounds like you've got it covered.

Predicting controlled objects is hairier; This is how I do it.

At T6 the client receives state T4 from server. It takes state T4 and applies all input entered during T5 and T6 to arrive at state P6.
This is what's rendered on the screen (unless we use the technique below).

At T7 the client receives state T5 from server. It takes state T5 and applies all input entered during T7 and T7 to arrive at state P7.

Unfortunately, it turns out that on the server, the player collided with a newly spawned object. This was (of course) not part of our prediction, so a visible SNAP will occur between P6 and P7.

To remedy this, the client will at T7 ALSO keep predicting from T4 (the old server state), applying input from T5, T6 and T7 to arrive at P7v2.

Using both P7 and P7v2 we can interpolate for a short period of time between our old prediction and our new (better) prediction, to avoid snapping and instead smoothly going from misprediction to correct prediction.


Very helpful post, I implemented your design and it works very well! Problem solved. :D


PARTNERS