Gamestates for Lag Compensation?

I’m reading through your code, and it seems like KX_PythonLogicLoop is the magic bullet I need to implement rollbacks in my program. Where is the class defined? I’ve only found something for within the root’s conf.py, and that’s a fake import.

Is KX_PythonLogicLoop a part of PyAuthServer?
How can I download/build a version of Blender with it included?

My current short-term plan is to build a simple program that would test the class, to see if and how it can do what I need. The program would locally execute inputs “in the past” with the present state changing accordingly: if that’s smooth, in a local single-player environment, then the real deal will be no major ordeal.

Most of this stuff is defined in c++, but you can find an example implementation in gameloop.py in pyauthserver somewhere ;). Building blender would require trunk, although my current git repo won’t compile, so I need to fix that :slight_smile: there is a link *somewhere * for an existing windows build :slight_smile:

I’ve found your implementation of it within gameloop.py, but that’s not enough. In Blender 2.71, KX_PythonLogicLoop does not exist within bge.types, according to dir() printouts. Do you develop on a version of Blender with KX_PythonLogicLoop available? Which version is it? Where did you get it? Which branch ought I be looking for?

I can compile my own copy of Blender, if need be. I just need the C++ files with KX_PythonLogicLoop defined.

As I’ve said, it’s a custom build of blender, this functionality is not in trunk at present

Sent from my Nexus 7 using Tapatalk

I got that much. The source code for that custom build is not available anywhere? Do you know who developed the class in question?

Do you have a build with this functionality, yourself?

I think I also wrote this, but that source code is available and you need it in order to build blender to support the functionality. You might be confused in that it uses a c++ API to define python types, which is what the rest of the game engine does.

It is hosted on my git hub. Currently I have to build without cycles, though of course my patch doesn’t touch the area.

Wow, I’m dumb. I’ve found it. Thanks~!

KX_KetsiEngine.NextFrame() seems to be missing from your GitHub code. Do you have it written? Can you post it here right quick?

Is KX_KetsiEngine’s NextFrame() a copy of bge.logic.NextFrame()? Is there any advice you can give me to build the function for myself? What explicitly is it meant to handle?

I had replied to this, but it hasn’t posted. I’m sorry for the delay.

All the code for the BGE has been changing a bit recently. The best thing for now is to use my prebuilt 2.69 for Blender, which I linked somewhere. (I think it’s this link), because I’ve noticed 2.7 crashes. I need to spend time getting it to work again.

NextFrame is a higher level function, which basically advances the game by one tick. For me, this wasn’t useful enough; sometimes I wished to update Bullet and not the render pipeline. If I was really thinking about things, i’d have worked on a better gameloop for varying render rates. But, I digress.

My system gives you the ability in Python to define a main() function (can’t remember what I actually called it), and you are responsible for updating the game systems. You can write a while loop inside that function, and as long as you update the relevant systems, nothing will freeze. My GameLoop class in the multiplayer system does this, amongst a number of other things. It’s more complex than you might need, but it shows what you can do.

I just needed the NextFrame() code to get everything to compile, since it being undefined was the last error I was getting, but HEY a prebuild works too~!

If I can make an entire main-loop with your build, creating a “side loop” and replacing the real main should be possible as well, right? I’d prefer not to take full control of the engine outside of isolated moments. My idea is to take an log snapshots of each logic frame with one brick-script, and have another brick-script utilize them as needed; overriding the autonomous main loop as needed. If this isn’t possible, that’s okay, but I’d like to stay within my style as much as possible.

I’m not sure quite what you’re asking :slight_smile:

2 logic bricks; both running each frame:

  • One brick takes a snapshot of the whole game, and sets it aside.
  • One brick accesses those snapshots, updates them invisibly until they catch up to the current frame, and then replaces the real frame with the one it just manipulated.

I’d like to instantiate a KX_PythonLogicLoop object, instead of basing a class off from it, in both of these bricks.

from bge import types

loop = types.KX_PythonLogicLoop()

...

Something like that, basically. Is that possible?

It sounds like you’re trying to create replay.

There isn’t much sense in creating multiple logic loops, if it were possible. It’s like giving a human two separate spinal cords, or skeletons.

The benefit of using this logic loop is that you don’t need to use logic bricks. You still need to update them, at least for now, due to a number of oversights in the BGE code that are a little more involved to change. But you can still run your entire game without creating logic bricks.

You could probably allow logic bricks to access a Python logic loop, but I suspect it wouldn’t be safe. You’d have to store a reference somewhere like globalDict.

Instead, doing this inside the logic loop means that you know you’re not interrupting any other state.

Replays are essentially what I’m going for. Creating a second loop in the background is pretty much the only way for the rollback-style of netcode to function exactly as needed, though you’re right in that there isn’t a whole lot of places where it’d make sense: this is just one of those few times.

Here’s an excerpt from Skullgirls, GGPO… and You that gives an example of my end goal, explained in a hypothetical match between Alex and Bob:

Alex may see his attack hit on frame 12, but the game doesn’t yet know if Bob was blocking. So when Bob’s frame 12 input arrives on frame 17, the game may possibly have to travel back in time to revise itself and instead show that Bob had blocked the attack on frame 12, thus on frame 17 he’s now in block stun rather than hitstun.

It’s a weird technique, but it’s a godsend for fighting games (which I’m trying to make). Doing this technique within Blender doesn’t require that have multiple loops running concurrently at all times, but that I can create side-loops whenever scenarios like the one above pop up.

As for logic bricks… I like using logic bricks~! They keep things easy for me to parse and process. If I have to have one brick that runs the game loop entirely, and it has to take its own snapshots and do its own rollbacks, that’s okay: I just fear not being able to build the rest of the game as I’m accustomed. What I’m trying to do may well be truly beyond what a brick-centered object can accomplish, and I’m cool with re-learning a style of Blender coding I have largely ignored to date. Are there any tutorials you know off-hand about this style of scripting? Do you know if it has a name I can just punch into Google?

It doesn’t make much sense to have multiple loops. Mainly because:

  1. There’s only one game state in action.
  2. There’s only one piece of code running at any given time (that can modify this state safely).

You’re better off simply handling things carefully. One means of avoiding latency is to play animations that build up to an attack, and send an intent message to the server when that animation is started. Provided that the animation length is roughly equal to or greater than the latency, you can hide it as the response will arrive in time to display).

I recommend visiting the relevant forum on GameDev.net.

That method has been tried, and has been pretty much rejected by the fighting game community. The rollback method introduced by GGPO is the current standard for online multiplayer, and is pretty much adored by everyone. It may not make sense, but it has been proven in numerous high-profile games in the fighting genre.

It will harm the feeling of input responsiveness, but not as acutely as simply waiting for the result.

If you are happy to deal with visual discrepancies, then simply correcting the state as it comes in is fine.

The visual choppiness is considered well worth the responsiveness~

Besides, this method allows for lag to be set by the user as they prefer, smoothing everything out.

So, I guess now it’s time for me to to start experimenting. I’ll keep jumping in with questions as I’ve been doing, but they’ll be more brass-tacks. Thanks for the prebuild, yo! If this works how I want, you’ll have effectively saved me $5000 for GGPO’s license~!

I’m gonna throw this question into the forum while I’m doing my own studying: how do I implement my own game loop with KX_PythonLogicLoop? I’m having some difficulty grasping the style of scripting required in this task.

Extending the class is easy enough, but I don’t know the proper way to instantiate it and run it’s main().