Similar Content

I'm trying to learn how to make my own model, view, projection setup. I've managed to translate, rotate, and scale my models, but have an issue with my perspective projection matrix.
Even though I'm multiplying halfFOV with my aspect ratio, the image looks squished unless my window is a perfect square like this:

If it's not a perfect square: the wider my window the more stretched my object looks in the Z axis like an egg.

I'm trying to make fixed time-step game loop following this wonderful site, but I suspect I'm not understanding the concept correctly. I'm working with JavaScript and the browser, but I'm sure you'll understand better than I do.
Here are the steps I'm taking:
- I'm using the 60fps update loop (requestAnimationFrame) provided by browsers.
- Using a 30fps step (1.0/30.0) for my fixed update loop.
- I'm currently getting all the necessary time data at the beginning of the frame:

// within update frame loop
while (lag >= fpsLimit) {
lag -= fpsLimit;
game.fixedUpdate();
}
game.update();
game.render();
If you notice, I increment lag in milliseconds, not seconds (divided by 1000). That way, when I get to the while loop, lag decreases exactly 30 times and then moves down to rendering part. So if I log inside the while loop and after it, I get 30 logs from the while loop and 1 after it. Repeat.

But if I do it the way the site recommends, which is to increment lag by seconds (divided by 1000), the number is lower, but the while loop only runs once. I'm guessing because I only increment by the fpsLimit (0.033) and it would take only one iteration to escape the while loop.
I hope I made sense, I'm basically trying to do something similar to Unity. Have a fixed update I know will loop 30 times, and also update every frame. Not sure if I'm understand correctly though. Thanks if your read this far!

We're looking for programmers for our project.
Our project is being made in Unity
Requirements:
-Skills in Unity
-C#
-Javascript
-Node.js
We're looking for programmers who can perform a variety of functions on our project.
Project is a top-down hack-and-slash pvp dungeon-crawler like game. Game is entirely multiplayer based, using randomized dungeons, and a unique combat system with emphasis on gameplay.
We have a GDD to work off of, and a Lead Programmer you would work under.
Assignments may include:
-Creating new scripts of varying degrees specific to the project (mostly server-side, but sometimes client-side)
-Assembling already created monsters/characters with existing or non-existing code.
-Creating VFX
-Assembling already created environment models
If interested, please contact: eldwin11929@yahoo.com
This project is unpaid, but with royalties.

---
Additional Project Info:
Summary:
Bassetune Reapers is a Player-verus-Player, competitive dungeon crawler. This basically takes on aspects of dungeon crawling, but with a more aggressive setting. Players will have the option to play as the "dungeon-crawlers" (called the 'Knights', or "Knight Class", in-game) or as the "dungeon" itself (literally called the 'Bosses', or "Boss Class", in-game). What this means is that players can choose to play as the people invading the dungeon, or as the dungeon-holders themselves.
Key Features:
-Intense, fast-paced combat
-Multiple skills, weapons, and ways to play the game
-Tons of different Bosses, Minibosses, creatures and traps to utilize throughout the dungeon
-Multiple unique environments
-Interesting, detailed lore behind both the game and world
-Intricate RPG system
-Ladder and ranking system
-Lots of customization for both classes s of customization for both classes

I want to make a html5 canvas / javascript game, similar to agar.io. I know a little node.js, and I think I understand the way online multiplayer works, but now that I do understand I realize it's gonna be a ton of work if I want to do it from the ground up with something like socket.io. My question is: are there libraries that can help with the multiplayer aspects of my game (sending game packets, etc.), and if so, is the performance for that library fast enough to run my game? (has a latency at least as low as agar.io)

Recommended Posts

I have implemented client interpolation and it works well. But I don't like my current structure. It looks really ugly and created too many temporary objects, besides that it is really hard to maintain the code.

I am not going to show too many logic here as it is very tightly coupled with other parts of my game. Note that my code is written in javascript but if you show me some direction in generic language or C++ that's OK too because I think the logic should not be too different.

In my game I have hundreds of players and other NPCs, and every network update I get a timestamp. I just bundle them up in a very big state object. Let's call it "currentRenderState", similarly I have "previousRenderState" and "futureRenderState", which means the state I receive in last update and the state I receive in current update. I am going to interpolate from "previousRenderState" to "futureRenderState". The interpolation result will be stored in "currentRenderState". If next update state hasn't arrived and the player state hasn't reached "futureRenderState" I will interpolate from "currentRenderState" to "futureRenderState".

So my state object contains a lot of information.

state ={
timestamp,
allPlayerStates,
allNPCStates
}

Here "allPlayerStates" is a very big object too. It contains all the states of all players and each player contains dozens or even hundreds of properties.

Every time I interpolate I need to clear the object in currentRenderState, also I need to reference allPlayerStates and allNPCStates in "previousRenderState" and "futureRenderState" to get one of the individual state and interpolate it. At the end of the interpolation I create a very big temporary state object and put the interpolation value into this state object and assign to "currentRenderState". Then in the interpolation code I loop through the "allPlayerStates" of "currentRenderState", and assign the value to each player on client side. Also I loop through "allNPCStates" to assign the value to each NPC on client side. This logic works, but I feel tiresome each time I read through my code. Is there a better way to organise my interpolation code, and probably make it more efficient too?

Share this post

Link to post

Share on other sites

Looks like you're storing your state in the inverse way to how I'd store it.

I'd have each object responsible for its own state, and its past states. I can then ask each object "what is your state at time T" and it can produce an interpolated or extrapolated state accordingly.

However, you don't always need to store the current, interpolated state for an object. If I'm just using this system to decide where to render something on screen, I can just ask for that value to be produced when necessary.

It's also usually not necessary to explicitly label states as current/previous/future. States have timestamps, and you have the current time (or at least, the notional time that you intend rendering), and you can interpolate between whichever 2 states are either side of the current time to decide what to render.

Finally, treating NPC states and player states separately is making extra work for yourself, so why bother?

Share this post

Link to post

Share on other sites

Looks like you're storing your state in the inverse way to how I'd store it.

I'd have each object responsible for its own state, and its past states. I can then ask each object "what is your state at time T" and it can produce an interpolated or extrapolated state accordingly.

However, you don't always need to store the current, interpolated state for an object. If I'm just using this system to decide where to render something on screen, I can just ask for that value to be produced when necessary.

It's also usually not necessary to explicitly label states as current/previous/future. States have timestamps, and you have the current time (or at least, the notional time that you intend rendering), and you can interpolate between whichever 2 states are either side of the current time to decide what to render.

Finally, treating NPC states and player states separately is making extra work for yourself, so why bother?

Thank you for your input. I have thought about putting the interpolation logic inside the loop of the player list. But maybe I am just being lazy not to test out if that works better or not because changing my interpolation code is really a headache. It can take up a day or even more. And it usually breaks my game and takes me even more time to debug.

The main reason of separating NPC and player states is that they are different thing. They behave totally diffenrently and NPC has only a few properties versus player which has a lot more properties.

Quote

However, you don't always need to store the current, interpolated state for an object. If I'm just using this system to decide where to render something on screen, I can just ask for that value to be produced when necessary.

In my game, it works like this: (Pseudo code, not in interpolation, but in the code when client receives an update)

Share this post

Link to post

Share on other sites

Ok, your method of interpolation is the simplest one and does require storing the current interpolated state. That's fine. I'd still store it on a per-object basis.

If you want a more concrete example of how to make your code look less "tiresome" then we're going to have to see the code.

I agree with you too storing it on a per-object basis breaks it down into smaller unit so it's easier to debug. Unlike what I am doing now every time I debug or change some data structure it is a nightmare. But I still need to fix my code to adapt to the new structure.

0

Share this post

Link to post

Share on other sites

@Kylotan But I am very curious though. How not to store the current interpolated state? You see, one of the biggest headaches I have when changing my code is that I have to assign my "currentRenderState" to the "previousRenderState" (outside of interpolation). This results in copying a very complicated object into another object, value by value, and I can't copy its reference otherwise weird things would happen and those states will become unstable because changing one state can affect another.

0

Share this post

Link to post

Share on other sites

If you simply store states as they come in, you can interpolate between them as necessary based on the current time. The current state is just a weighted average of a past state and a future state which is usually trivial to calculate once per frame for display purposes and then throw away. I explained this to you in a similar thread back in March. You have chosen a different route where, once you receive a new state update, you start interpolating towards that immediately, which requires that you assume your currently interpolated state is the starting point. (You still don't strictly need to be storing that interpolated state - you only need to 'commit' it to the 'previous' state when you get a new one to replace the 'future' state.) Both routes are valid, having different pros and cons, and I've implemented each.

You might also consider that if state copying is too expensive for you, it might mean you are copying too much state. Many games only ever need to store position and orientation for these purposes. Others might add velocity to that, or maybe the current animation(s) and frame number(s). It's still only a very small amount per entity.

0

Share this post

Link to post

Share on other sites

If you simply store states as they come in, you can interpolate between them as necessary based on the current time. The current state is just a weighted average of a past state and a future state which is usually trivial to calculate once per frame for display purposes and then throw away. I explained this to you in a similar thread back in March. You have chosen a different route where, once you receive a new state update, you start interpolating towards that immediately, which requires that you assume your currently interpolated state is the starting point. (You still don't strictly need to be storing that interpolated state - you only need to 'commit' it to the 'previous' state when you get a new one to replace the 'future' state.) Both routes are valid, having different pros and cons, and I've implemented each.

Sorry I went the other route because I felt that was enough for my game and easier to implement. But what does 'commit' mean?

Quote

You might also consider that if state copying is too expensive for you, it might mean you are copying too much state. Many games only ever need to store position and orientation for these purposes. Others might add velocity to that, or maybe the current animation and frame number. It's still only a very small amount per entity.

Apart from those values I have "alive" to check if player is alive, and "username" because I need to show it on screen, and the player's "score". The player's position is not just x and y. It has many parts moving after it so I need to pass those position values too.

0

Share this post

Link to post

Share on other sites

By 'commit' in this situation, I just meant 'store into previous state'. Because the interpolated value can just be a transient, calculated value, used merely for display. It's only when you receive a new state and need to treat the current state as the beginning of the interpolated range that you would actually need to store it.

It sounds to me like your state is not really all that large, and you're including things that shouldn't be in there anyway. Username is usually completely static, so it doesn't need to be in there. You can't interpolate it anyway. Dead or alive is certainly state, but you can't interpolate that, so again, it doesn't need to be in this specific data structure. I can't comment on position because for most MMOs this is literally one vector or matrix - if you have something more complex, it might well require a lot more state, or, it might just require a more sensible way of storing and deducing it.

0

Share this post

Link to post

Share on other sites

@Kylotan I might have been too lazy to split those properties such as "alive" and "username". But I have this concern: because I am putting every state into a big object, when I query a state from a list of players or NPCs I can quickly get the property and display its status. Otherwise I will have to maintain and query another state list to get these properties. And if this other state list doesn't have the same player IDs with the current state I am in big trouble.

Back to 'commiting' the current state. I think you mean recalculate it when I need to store it to the "previousRenderState"? Would that be doing extra calculation when that situation comes up?