Jump to content
  • Advertisement
  • entries
    37
  • comments
    65
  • views
    48177

Replicating a simulation with Box2d, part 3.

desdemian

944 views

In the last post, I explained how to solve the box2d issue about cloning a world. It's pretty simple, fairly fast and reliable in its results.

I didn't use it. Why? Because there are some cases (like my game) that it doesn't work. And those cases happen when the game has two+ characters and one can go back to change their behaviour but the other one does exactly the same.

Let me put it in pictures.

If you have one character going back in time:

pHedaTZ.png

The mechanic is straight forward. If the character goes back in time and does the same movements, the result will be exactly the same, because the copied world will be the same as before.

If the character goes back in time and does something different, well, the result will be different, but that makes total sense, if you change the past you cannot expect the future to be exactly the same.


But, if you have 2 characters, let's see what happens:

21P13kr.png

Let's say character pink stays still while character blue jumps around. A possible future is generated and the pink character observes it. This is the critical part, somebody that is not causing the events but is able to see the possible future.

Now, when everything is rewound, and the pink character decides to move around, the copies will not be the same as before. Thus, the future of the blue player (that was originally observed) might change, even if the pink player never touches the blue player or its surroundings. This makes no sense in the eyes of the second player.

This is a huge issue! Imagine in Posable Heroes doing some tasks with the blue character, and then coming back to work with the pink character only to realise your blue characters timeline is altered. Since the game requires precision, this is unacceptable.

On the 4th and final post, I'll explain what I did to finally solve this issue (spoiler alert: thank you open source).

 

If you are interested in Posable Heroes, you can wishlist it on steam.



0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By olivermarsh
      Hi,  I was wanting to read the box2d source, but wanted to get a broad overview first.  I'll just say what I understand so far:
      Box2d has discrete & continuous collision detection.  We first integrate our shapes velocity, and using a 'conservative advancement algorithm, we advance the shapes & find toi. 
      It then uses gjk & barycentric coordinates to find the closest point on the shapes.  If  theyre overlapping we use epa or sat (and dont get a contact point? Or run gjk again?)
      It then builds an incremental manifold (i probably have this wrong) adding a point each frame. 
      Then once all collision points have been collected for the frame, they go through the collision solver that takes each collision, & adds an impulse to the shape to bring the relative velocity <= 0.  We go through the list of contacts several times (the iterative rigid body solver), to stabilise the simulation.  
      I'm not sure what it uses for discrete collisions?
      What things I don't understand is
      1. When do we know we don't need a collision point anymore? When the collision points are moving away? 
      2. How do we know a contact point is unique with gjk/barycentric coords? Or do we just add them and wait till they get pulled off the list?
      3. If the toi is less than one & we want to use the rest up, do we run the whole collision routine again for a max say 4 times, to use it up, and where does this fit into the iterative solver? 
      I kind of just want to get an overview of how a physics engine fits together and the parts or algorithms we need.   Its just for a hobby engine, and with understanding as a priority.  Any help would be great, and sorry if the question is a bit over simplified.
       
    • By phenom120
      I am developing a simply 2d physics engine and I' ve read the source code of box2d and matter.js. I found some insteresting thing on finding contact point:
      Box2d use indicent edge, reference edge and clip to determine a contact point. It's very complex method and hard to understand.
      However, matter.js use a very simply method to do the same thing. just find the vertex that contained by opposite polygon with hill-climbing:
      var verticesB = SAT._findSupports(bodyA, bodyB, collision.normal), supports = []; // find the supports from bodyB that are inside bodyA if (Vertices.contains(bodyA.vertices, verticesB[0])) supports.push(verticesB[0]); if (Vertices.contains(bodyA.vertices, verticesB[1])) supports.push(verticesB[1]); // find the supports from bodyA that are inside bodyB if (supports.length < 2) { var verticesA = SAT._findSupports(bodyB, bodyA, Vector.neg(collision.normal)); if (Vertices.contains(bodyB.vertices, verticesA[0])) supports.push(verticesA[0]); if (supports.length < 2 && Vertices.contains(bodyB.vertices, verticesA[1])) supports.push(verticesA[1]); } and it works well in demo.
      My question is: why does box2d use such complex method? It's clear that matter.js's method is better. Or there are some potential shortcomings in matter.js's method?
       
    • By phenom120
      I'm currently implementing a 2D physics engine, then i stuck in collision resolution. So i did a search in google, and i found this passage, It explains how to use impulse to separate two objects.
      But after that, i found another another passage, this article is very complicated, but they seem talking the same thing ——— how to implementing the collision resolution. So now, what i confuse is why are there two completely different approaches of collision resolution? What's the difference between them? Which approaches is right?
      I am not a native english speakers, so i hope you can understand what i wrote.
      Thanks.
    • By Catch_0x16
      Hello folks,
      I am fighting with a really simple problem that has been driving me nuts. I'm usually fairly confident with trigonometry and I'm pretty sure the issue here is not the math but in some behavior behind the scenes.
      A bit of background - basically I'm developing my own little 2D game engine using C++, in my free-time for fun. I work with game technology and simulation products IRL so for the most part this has been plain sailing. I am using Box2D for physics, and SFML for rendering.
      My game at current has a few space ships flying around via keyboard and AI input. These space ships need exhausts! So I'm currently in the process of getting a 'component' system in place, however my problem is that the animated exhaust sprites are not going where I want them to.
      When the base GameObject class runs it's update method, it does the following:
      Queries the physics object for a position Converts the physics position to a pixel position (x10 scale factor) Moves the sprite to the new position Passes new position to all 'component' objects into their 'UpdateComponent' method Components move their sprite to the correct position However the exhaust sprites seem to wander around all over the place, in no way representing where I actually want them to be! This should have been a simple case of:
      newPosition = (sin(rotationRadians) * offsetX, cos(rotationRadians) * offsetY) + oldPosition Here is the current code:
      void Exhaust::UpdateComponent(const Vec2f & position, float rotationDegrees, float deltaTime) { float angleRad = DEGREES_TO_RADIANS(rotationDegrees); float offsetX = sin(angleRad) * mOffset.x; float offsetY = cos(angleRad) * mOffset.y; sf::Vector2f newPos(position.x + offsetX, position.y + offsetY); mSprite->SetRotation(rotationDegrees); mSprite->SetPosition(newPos); mSprite->Update(deltaTime); #ifdef _DEBUG sf::Vector2f p(position.x, position.y); stringstream ss; ss << rotationDegrees; DebugUtils::DrawCross(p, 8, sf::Color::Green, ss.str()); DebugUtils::DrawCross(newPos, 8, sf::Color::Green); DebugUtils::DrawLine(p, newPos, sf::Color::Green); cout << rotationDegrees << endl; DebugUtils::DrawSpriteOutline(*mSprite->GetGraphic(), sf::Color::Green); #endif // _DEBUG }  
      And here is a gif of it all going wrong! (link below)
      Gif of game engine problem
      Any help would be much appreciated, even if it is just a thought of where the problem might be originating from!
      Thanks!
    • By JesseTG
      A Really Useful Box2D Editor
      You're a game developer. Your next project will have Box2D-powered physics, and it'll be awesome. So you wrestle with installers, build systems, possibly with compiling the library itself, and then get a rectangle moving around on-screen. Now what? If your game is non-trivial, you could have dozens of different types of objects. You're not going to have a good time describing them in code, as you'd have to recompile every time your designer (which could be you) blows his/her nose. You could come up with your own loader, but then you'd have to come up with your own file format, too, and that's time not spent actually making your game!
      Enter R.U.B.E., the Really Useful Box2D Editor. R.U.B.E. is a level designer for virtually any game that uses the Box2D physics engine. You can use it to visually create a wide variety of collision shapes, place them on-screen, and edit their properties. R.U.B.E. also boasts a comprehensive scripting system, support for nearly all Box2D constructs, and extensive customizability.
       
       
      The Setup
      I use R.U.B.E. on Ubuntu 14.04 and a reasonably beefy 2011-era Samsung laptop. R.U.B.E. is available for Windows, Mac, and Linux. The Mac version, however, does not officially support 64-bit computers; it might or might not work. Likewise for any Linux distribution other than Ubuntu. When in doubt, see if the trial version works. I'm using R.U.B.E. to develop a top-down shooter written in Java and libGDX.
      The Editor
      The user interface for a program like this should aim to minimize the barrier between the designer's ideas and his/her implementation. Fortunately, R.U.B.E.'s editor does a decent enough job of that. The controls for the editor itself are a bit clunky, relying on keyboard shortcuts to perform basic geometric transformations (e.g. pressing S to scale an object, as opposed to just grabbing a handle like in Unity or Inkscape). A bit annoying, but you'll get used to it. Other features, like the ability to position the menus freely, or the ability to copy objects to other programs as plain text, or even to run the Box2D engine to see how objects move in the world, are very much welcome. I don't think you'll be wrestling with the program too much.
      The Scripting
      My limited experience with RubeScript, the built-in scripting engine derived from AngelScript, was a pleasant one. The language itself is nothing spectacular, preferring simplicity for programmers and non-programmers alike over flashy features. Better documentation for the built-in types (strings, arrays, etc.) and code completion would've been nice, at least.
      What really makes RubeScript stand out is its thorough functionality. Almost all of the built-in editor actions--adding or deleting bodies and joints, smoothing or removing vertices--are actually implemented in RubeScript, and can be viewed in R.U.B.E.'s installation. If the developer himself can write the meat of R.U.B.E. in its own scripting system, I'm sure you can get something out of it, too. Tools like this are why game designers benefit from some programming skills.
      The Competition
      Minimal. Most available alternatives lack some of R.U.B.E.'s most defining features. These other editors are only designed for creating simple game objects (such as PhysicsEditor, which doesn't support joints), or lack adequate import/export facilities (e.g. BoxCAD, whose output requires ActionScript 3.0 to be used). Other more generic solutions such as Tiled or even Inkscape might suit your needs if you can write a loader to convert their output to Box2D worlds. I don't feel that most of these other alternatives fill the need for a 2D physics world editor, though for very small games you may disagree.
      The Surrounding Ecosystem
      I have nothing but good things to say here. The official documentation for R.U.B.E. is excellent. Even if you ignore the built-in manual (which is very detailed and contains plenty of images), there's a wealth of resources available on the official website, including sample projects and video tutorials.
      But perhaps best of all, Chris Campbell (the developer) actually gives a damn about you. He reads the forum and any e-mail he gets. It's easy to report bugs or offer feedback from within R.U.B.E. itself. I can send a hastily-written bug report or feature request through through R.U.B.E. and continue working before my concentration wavers. You'll actually get a response from Chris within a reasonable time frame, and he'll make sure you get the best out of R.U.B.E. you possibly can. He's helped me numerous times with reporting bugs, feature requests, and even general Box2D questions.
      The main problem with R.U.B.E., as I see it, is that your game's technologies will be limited to whatever has a R.U.B.E. loader and a Box2D port available. This issue isn't exclusive to R.U.B.E.--it's inherent in any technology that's not as mainstream as, say, PNGs or WAVs. While R.U.B.E. does have loaders available for many popular game frameworks and programming languages, if none of them suit your needs you'll either have to reconsider your toolkit or write your own loader.
      The Bottom Line
      A designer alone may not have much use for R.U.B.E., because odds are if he/she is using a prefab game engine like Game Maker or Unity he/she'll be using its respective built-in editor. But for programmers or designers working with programmers, R.U.B.E. is a solid investment. R.U.B.E. is flexible enough to play well with any custom game engine, yet simple enough to make entertaining game worlds with ease. I wholeheartedly recommend taking the $30 plunge.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!