Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Oct 2005
Offline Last Active Oct 19 2016 12:29 PM

#5309985 [Networking] Can't locally predict other players's movements?

Posted by on 08 September 2016 - 12:22 PM

I just perform physics-based dead reckoning, but with players it's different because a player could have released a movement key or started holding down a different one, which should cause a different outcome in their movement. I don't include the time a keypress started or ended in an update, so the accuracy is limited by the resolution of the updates, but it's sufficient for the purposes of my game at 15hz (67 msec).


In my game the local player's input is applied to their entity by the same code that applies the last-known input for all other players to their own entities as received from the server (along with their positions/velocities). The reason for this is because I just use the physics simulation to predict everything, and if the next update received has a new position for an entity that is different than what the physics has simulated locally then the client just interpolates across the error until the next update is expected to arrive.


Velocities are snapped to whatever is received from the server, but the difference between current position and received position is added to the entity's position along with its velocity over the period that elapses between updates being received, unless the difference is a few meters, then it just snaps the position as well. This means that clients are always simulating one update behind the server. EDIT: This is because one update arrives and it takes until the next one arrives before everything has interpolated to the corrected position, at which point the new update arrives and the whole system has to play 'catch-up' again... over and over...


This, ontop of a buffering delay that is used to smooth out network update jitter (updates arriving at irregular intervals), and the latency between client/server leaves clients with a minimum of 50+ msec delay between what's happening on the server and what they're actually seeing.


What that article is talking about is the fact that you can't just magically know which direction a player has chosen to move, or jump, or crouch, etc.. and you just have to wait until that information arrives because players are unpredictable. The best you can do is know what keys they were last holding, and generate the player movement for that particular input state, and hope for the best.

#5309970 How to structure my pure client/server model properly?

Posted by on 08 September 2016 - 10:33 AM

You will make it if you keep at it, I believe that whole-heartedly. That's really what separates the successful from the unsuccessful: the will to keep at it until success is achieved. Where there's a will there's a way!


...and yes, it took me a long time, because I had to deal with a lot of problems/mistakes I made in life when I was younger, and allowed myself to get distracted and lose focus. But, making a game was something I consistently came back to. So, ultimately, I just had to fully commit and tell myself "I am making a game" and that there were no two ways about it.


Even after that I still got distracted with another project (making specular holograms and building a CNC machine to do it) and that took me 6 months to get out of my system before realizing how much I had already accomplished with my game working on it for over a year solidly, and that I shouldn't let all that hard work go to waste, so I dove right back in and picked up right where I left off.

#5309874 How to structure my pure client/server model properly?

Posted by on 07 September 2016 - 03:39 PM

It sounds like you have a lot of work to do concerning how to actually create a game, let alone a multiplayer one. I have had many false-starts since my teenage years insofar as creating a game engine is concerned, and it took me a solid 10 years (with a lot of Real-Life getting in the way over that time) before I finally started figuring it all out. You could say I was super naive from the get-go, I knew how to render some stuff and have an array of entities with positions and velocities, but I had no idea how to actually build something that was manageable without coding myself into a corner that rendered the entire project hopeless and requiring a complete re-write (or some serious surgery that I had no patience for once I realized the horror of my code-design mistakes).


I have started many game engine projects over the years, each time thinking I had it all figured out, until I coded them to the point where it was obvious I still had some learning to do. I am finally *just now* releasing something, after spending 20+ years learning the ins-and-outs of game development, which I've been working on for over 2.5 years (again with Real-Life interfering along the way) and it's something I'm super proud of and excited about, and I couldn't have done it without learning everything that it took me to learn over all this time.


I guess what I'm trying to say is, don't give up, you probably won't get it your first try, but trying is how I learned, so go for it, but it can't hurt to have a realistic perspective of what you're going to be capable of starting with barely enough knowledge to make a single player game. If you won't have to deal with all the problems I did in my life you'll get there a lot quicker than I did.


If you're curious to see what I've managed to do check out my blog: http://deftware.blogspot.com

My game is called Bitphoria, and it's the product of wanting to make a multiplayer FPS game since the 90s when multiplayer shooter games were just in their infancy.

#5307675 Low level serialisation strategies

Posted by on 24 August 2016 - 01:52 PM

I use a simple set of functions that I hand-wrote in C for writing all kinds of things to a buffer called a 'message'.


I have ones for writing 32-bit integers, floats.. Others for writing floats as a single byte, with a min/max range specified for the value. So if I have a float that's expected to be between -1 and 1 it will go ahead and pack it down into one byte, then on the other end a corresponding read function for re-constituting the original -1 to 1 float from the single byte.


I also have read/write functions for quaternions, angle-axis rotation velocities, of different bit counts so that in cases where I want to dispose of some accuracy for smaller amount of data, I can. A quat, for example, can be conveyed as either 24-bits, 32-bits or 64-bits. An angle-axis velocity can be conveyed in 40 bits or 64 bits. etc..


I can also read/write 3D vectors at varying bitdepths, specifying min/max values to map each vector component to all the bits allowed.


I don't think I will ever just read/write full on precision data structures, unless there's a case where that's absolutely necessary.

#5304111 Theory Behind These Uncharted 4 Bullet Trails

Posted by on 04 August 2016 - 09:16 PM

It appears that they are just using a quad strip particle effect and allowing the vertices to drift - this could be achieved by simply generating a single strip to submit to the GPU and then sending a time variable to the vertex shader which then randomly drifts the vertices while fading out the alpha. The goal here is to have the strip facing the camera, which is pretty simple to do, it's virtually the same as having a billboard face the camera. The texture coordinates of the smoke trail could also be allowed to drift lengthwise down the strip at a decelerating speed whilst also spreading out across the width of the strip to create a more vivid dispersal effect.

#5302772 2.5D Movement Problem

Posted by on 27 July 2016 - 11:48 AM

The solution is very simple: divide the rendered X coordinate of the object by it's Z (or depth) coordinate, and offset to the center of the screen.


You may have to add a scaling and add a bias on there but it will work great. That's how 3D perspective is achieved to begin with.

#5235361 Ways to setup true first person viewpoint

Posted by on 17 June 2015 - 06:32 PM

You could just have the camera on the head bone, and dampen it out, so that it's effectively 'chasing' the headbone, instead of solidly fixed to it.

#5233526 Skydome

Posted by on 08 June 2015 - 07:07 AM

I have used skydomes, but I offset/stretch them (when generating them algorithmically at runtime) so that the camera is closer to the top of the dome, and the bottom of the hemisphere at the horizon is lower than the horizon, to better avoid ugly discontinuity artifacts if player is up high above scene geometry.


Also, to eliminate any intersection with scene geometry, I don't even worry about the actual geometry/size of the skydome, I just disable depth writing when I draw it, so that everything that's drawn after the skydome will overlap it by default, even though the skydome is really just almost like a hat the camera is wearing around with a 1-unit radius.


For texturing I would pretty much just use the horizontal coordinate as the texture coordinate, and I would overlap textures and scale them so that there's a certain parallax effect. I would also fade the bottom of the skydome to black so it's not fullbright at the horizon.. This is, of course, also a stylistic choice and other options are available.


You could also incorporate a skybox backdrop, and just use a skydome to add cloud layers. There are a few games that have done this over the years.

#5233523 Expand 2D texture in 3rd dimension to create a model

Posted by on 08 June 2015 - 06:51 AM

I haven't played minecraft more than a few minutes, but I was under the impression that the items/weapons were just regular 3D models, made to look like voxel pixel-art. You could automate this process of generating a model from a texture, and have some other means of specifying the 'thickness' of the resulting model, but it also might be easier to just use regular 3D models.

#5230537 Client side hit detection vs server side with prediction

Posted by on 23 May 2015 - 12:54 AM

It is easier to write, which is sometimes an important trait.
Also, server rewind may still suffer from dropped/delayed packets, where the server comes to a different conclusion than the client.
If you use client-side hit detection, the client will "never" have the feeling of lag (but may, instead, have the feeling of someone else shooting them when they feel they alread dove into cover.)


With server-rewind strategies you can experience the worst of both worlds: where sometimes what the client sees isn't what happens on the server, and also client players taking damage after finding cover from an attacker.


As a gamer, though, I would rather that my attacks register exactly, even if that means I may get hit behind a corner. It is vastly more frustrating to me to be skilled and capable of pulling off really great shots, only to have them not register because of high latency jitter, than it is to get hit after running behind a corner. I feel more cheated when my shots don't "register" than when I get hit behind a corner.

#5228493 generic fancy procedural graphics question

Posted by on 12 May 2015 - 02:47 AM

phrase of the day: "generic-fancy"


If I were to take a stab in the dark, I'd say you want to make something that looks good, that wasn't made by hand. Ultimately, procedural systems must be 'crafted' or 'sculpted' in some fashion to make anything resembling something our brains can recognize and interpret as something, otherwise it's just noise. The trade-off is that the more crafting you work into your procedural content, the less varied and novel it becomes, and it will start being repetitive and all 'look the same'.


To make something more varied with an equal amount of 'crafting' you will end up with more content that is less complex/intricate.

#5228117 Is it efficient to sort a "render-queue" for less texture-switches?

Posted by on 09 May 2015 - 09:08 AM

Another option is to just load all your textures into a single bound texture, whether that be a texture atlas, or a texture-array, or even a 3D texture (where each object gets a Z coordinate based on which texture it needs). For many different sized textures you'll have to manually figure out the optimal way to organize your textures so they all fit together with optimal usage of texture area. Then you will be doing one texture bind for all of your objects.

#5228115 Is it possible to declare single-bit-variables/struct?

Posted by on 09 May 2015 - 09:01 AM

There is only one situation I've encountered so far that necessitate the use of bitflags via bitwise operators, and that is data serialization, for either network transmission of data or compact storage for file formats.




Often there's way more layers too!
e.g. processor fetches 64 byte cache-lines, then fetches 4 byte words, then operates on a byte within a word.


The primary issue is that it simply takes more work to examine and work with individual bits. Processors are designed (AFAIK) to operate on 32-bit values, primarily. Anything else (a bit, byte, word, etc) takes extra cycles. EDIT: thus, it can be useful for situations that call for having compact data (networking) but in performance-sensitive situations (tight inner loops that execute tens of thousands of times per frame) you'll want to avoid working with individual bits and stick to a data type the platform/system can work with as fast as possible. In the case where you have a gigantic set of booleans, maybe it would be better to use bits for the sake of avoiding cache misses, but it is up to the programmer to determine what works best for what they are trying to do.




in c++ you can declare single bit variables, you need to use the bit-fields specifier.
struct CarProperties
uint8_t EngineRunning:1;
uint8_t OutOfFuel:1;
uint8_t Burning:1;
uint8_t WantedByPolice:1;
uint8_t Electric:1;
uint8_t TwoSeater:1;
uint8_t Airbags:1;
uint8_t DrivenByThePope:1;


I totally forgot about this. I've always just used my own #define BIT(x) (1 << x) to perform bitwise operations.

#define BIT(x) (1 << x)
int flags = 0;
flags |= BIT(FLAG_A);
if(flags & BIT(FLAG_A))

The primary reason for doing it like this, as opposed to defining each flag as a power of two, is that it allows me to also use the FLAG_X defines to index any string tables or other tables that each flag needs a unique value for.

#5228021 3D Texture upload fails

Posted by on 08 May 2015 - 04:40 PM

are you data values from 0-65535


 I  am sure the issue lies in your Format and InternalFormat, and then also perhaps how your data is actually stored (just because they are unsigned shorts doesn't mean they are 0-65535, but hopefully they are).


 Read some updated glTexImage docs concerning InternalFormat. It's usually the culprit in situations like this.

#5227426 uniform buffers versus array uniforms

Posted by on 05 May 2015 - 09:31 PM

this should help you http://www.gamedev.net/topic/655969-speed-gluniform-vs-uniform-buffer-objects/