Hi. Time to start writing about the game design course!
This past week Hampus and I worked on understanding and using the collision in Box2D. Box2D is a physics engine that works with C++, and while only using it for the collision might seem a bit of an overkill Box2D has such a great variety of usage that learning it now can pay off in later projects as well. As far as collision goes here’s a list of the features Box2D has:
- Continuous collision detection
- Contact callbacks: begin, end, pre-solve, post-solve
- Convex polyons and circles.
- Multiple shapes per body
- One-shot contact manifolds
- Dynamic tree broadphase
- Efficient pair management
- Fast broadphase AABB queries
- Collision groups and categories
What makes Box2D so easy to use is the fact that as long as the objects you create are in the same “world”, they will collide with each other. Or rather, in Box2D you make the hitbox for objects and then in SFML (or another library of your choice) you make a the actual object and have it share the same position as the hitbox. Then you just make one of them move (in our case the hitbox) and have the other one follow by always updating the position. The hard part is implementing Box2D in an onworking project as I will come to shortly.
We began reading the documentation that came with Box2D and focusing on the parts about collision, on Tuesday we began trying to include the files into a project and try things out. Including it in an empty project on its own is just as easy as SDL or SFML, but together with something else is where the issues begin. SFML doesn’t particularly like Visual Studio 2013, but Box2D doesn’t particularly like VS 2012. We tried using CMake to build Box for 2012 but that didn’t achieve anything, no matter how much the tutorial tried to convince me.
At Thursday we had a meeting with our mentor from the 3rd year, and he thought it would be easier to just make the collision ourself rather than trying to learn Box2D. Since he’s a 3rd year we took his word for it even though we didn’t really get why it would be easier to do so, and I began working with the collision from a previous project and see if it could work out here as well. Hampus on the other hand felt that we had spent too much time on Box2D to give it up and so he continued tempering with it. We thought that if we split up and tried different things we’d simply use the collision from whoever got things to work first. And that was Hampus. On Friday we had a ball dropping down on an invisible square and colliding with it, and during the weekend Hampus got chains to work as well. Chains is a way to make collision work between objects and walls. You simply set out the coordinates for every point/edge in the wall and the chains will link them to each other automatically.
^click
So as of right now we understand how to create objects and chains, and our next artifact is to implement it in the project.
J.Majlov 
I really enjoyed that you tried to explain what you did in programming in layman’s terms, which I found you did an excellent job with!
You were good at articulating your thoughts and what work you and Hampus accomplished this week, however I would like to have heard a bit more of the actual work because I found it interesting maybe you should write a tutorial as you go? 🙂
/Daniel
Thanks 🙂
I’ll keep that in mind! I’ve got similar critique for a report so practicing on explaining so everyone can understand as well as digging deeper in this blog sounds like a nice idea. I’ll see what I can do for future posts.
Hello!
I believe that you have managed to explain very well what you have done this week. Line collision for walls makes it easier to have not so regular/straight walls which many games don’t have. I think it will be useful for future projects as well.
This is the first time I have heard of Box2D, it sounds like an awesome thing to learn how to use for future projects as you said. It might be a little bit overkill for this project but if you think it’s useful later, it might be worth it.
Some questions I thought of while reading your blog:
– How do you get the positions for the points? I can imagine there are a lot of points for you to set out (depending on the size of your map), so it can’t be that fun to manually writing each one in the code.
– How did you manage to solve the problem with SFML not liking Visual Studios 2013 and Box2D not liking Visual Studios 2012? Or will you try to solve that when you implement it to the game?
– Was Box2D easy to learn? How did you learn about it, and where can I learn more?
/Malin, group 7
Hi there!
– We used vertices to point out where we wanted the texture for our walls, then we made a function for the box2d chains to make a point at the same place. While writing each and every position isn’t much fun (or well, one of our graphical artists did that so I can only imagine!), the payoff is pretty satisfying.
– We used CMake to build box2D for visual studio 2012 with the help of this tutorial http://aneelkkhatri.wordpress.com/2011/06/14/setting-up-box2d-library-in-visual-studio-c/. It looks ridiculously long but a lot of it is just the actual implementation and that’s exactly the same as with SFML.
– I’m not sure about the physics part of it, but the collision is pretty straightforward. As long as you create a “world” and create your objects within it, the collision works completely on its own. So all you need to know is how to create objects, and that is well explained in the documentation on their site (http://box2d.org). The most difficult thing was to implement it in the project together with SFML, but that worked out when we got it to work in 2012.
When we needed to learn more than what the documentation went through we mainly checked out the tutorials on this site: https://www.iforce2d.net/b2dtut/introduction 🙂