Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Oct 2005
Offline Last Active Today, 10:24 AM

Posts I've Made

In Topic: Reducing Collision Checks

09 September 2016 - 05:46 PM

If the triangles are effectively a uniform grid I don't see why you can directly map XY coordinates to grid diamonds. I guess it depends on how you are actually representing the tiles in memory, if they are being rendered as a grid with every other row offset by half the size of a tile then it should be simple enough to directly determine exactly what tile is there.


You would first determine what row, by dividing by the vertical size of the tiles, and then if it's even/odd you know the X index has 0 or 1 added to it, depending on whether the first or second row is offset first, then just take the X coordinate of the click (divided by X size of a tile) and add it to the row-odd/even offset to get the columnar index of the tile.


EDIT: Actually, you will need to incorporate a manhattan distance check against the center of the tile's index to determine further XY offsets to the indexing since the shape is a diamond.

In Topic: [Networking] Can't locally predict other players's movements?

09 September 2016 - 11:38 AM

Have at it, develop the system. You'll be the first person in the world to do it. I think that alone makes it a worthwhile goal.

In Topic: [Networking] Can't locally predict other players's movements?

08 September 2016 - 05:44 PM

If it can rotate itself 180* in just a flip then yeah, it would be hard to perdict it.


In a first-person-shooter game, players are not limited to facing one direction, nor are they limited to moving in that one direction they are facing. How do you suppose we should predict what forward/left/right/back/jump/crouch buttons they are pressing before they are pressing them, and then showing that result to all other players before the player in question has even pressed them?

In Topic: Looking for feedback on my game engine

08 September 2016 - 02:51 PM

What BFG says is what has worked in my experience, and I've started about a dozen different game engines, each time failing to have the foresight or experience necessary to prevent the inherent issues in each project's design. It wasn't until my last project that I'm working on right now, and have 95% completed, that I was able to see all the pieces in their entirety, and how they all come together, allowing me to actually create a game engine that worked, and that games could be made out of.


It also really depends on what functionality you want which bears the questions: what kind of games do you want your engine to run? do you want multiplayer capabilities? what sort of graphics capabilities do you want it to have? do you want physics? how detailed should the physics be? are you loading models/textures? are you animating models? do you want particles? ad nauseam.


All of the answers to these questions affect a lot of things about an engine, and a generalized basic unassuming core engine design is going to be just that: basic and making no assumptions. It's not going to do anything at all, not until these questions are answered and the engine itself can actually have some meat to it. There are a million ways to write an engine, but it's nothing without the things that will make it capable of actually presenting a game.


Personally, I got stuck in the engine architecture stuff for a while completely second-guessing everything I came up with. Eventually what it came down to was actually writing code, and writing and writing, and then seeing what I did wrong, and doing it over again, usually re-using a lot of code - that had to be written in the first place in order for me to re-use and integrate into a re-write. Each iteration refining bits and pieces of the code I was re-using, and really as BFG says, just refactoring the whole engine. Over time I had something viable.

In Topic: [Networking] Can't locally predict other players's movements?

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.