Inside Velocity 2X:
1. Lighting
2. Controls
3. Animation System
4. Telepods
5. World Interaction
6. JBraamz
7. Physics
8. Explosions
9. Map
10. Teledash
If at first you don’t succeed…
The physics for Velocity 2X went through at least 3 full iterations, and was a great learning experience for the studio.
First attempt
We started with a physics system that was just based on circle/line collision and response. This meant we had Kai Tana represented by a tiny circle in the physics world and the environment represented by lines. This worked fine until we got to the point where we had to implement teledashing. Representing the teledash cursor in the physics world was easy, but if the environment is made out of lines, then the teledash cursor can be inside an object without a way for us to know that it’s inside. Lines just create hollow shapes:
The fix was easy: we added support for solid primitives such as Rectangles, Triangles etc. Fantastic, problem solved. This solution worked until we came to implementing throwing telepods.
Because of the speed at which telepods are thrown, they started tunneling through the environment.
At this stage, it became quite obvious that the physics engine for our game was not going to be as simple as we had initially hoped.
Second attempt
Always keen to ‘help’, James (not technical) decided to take our coding woes into his own hands and recommended porting his old Flash ActionScript physics engine to C++…
Those interested, his solution to tunneling: increase the size of the telepod object to twice its size for the first few frames while it’s moving extremely fast! Yes, that is what happens when a designer assumes the role of a programmer – and – believe it or not, I accepted that idea and went down that route.
After a few days of banging my head against the Flash code (trust me it was hell), it became obvious that we couldn’t have been more wrong about porting code written by James (sorry James, no coding for you anymore buddy). [Hey, that code worked fine for Velocity and Coconut Dodge! – JM]
Third attempt
Finally we decided to look at middleware options. After shopping around for a week, Box2D became the popular choice. We integrated Box2D into our engine, adding support for representing the environment as ghosted edge shapes, with polygonal shapes representing the internal hulls. By the end of the project we had multiple collision shapes performing different functions for Kai, as shown in the image below:
Lean and mean
The physics for Velocity 2X is actually quite simple in the sense that we don’t use any joints, fluids or chain based shapes. The complexity for the physics system in Velocity 2X comes from the player performing multiple actions in various configurations at high speed!
Open source saviour
We are pleased that we went through different options before finalizing on Box2D; the more we failed, the more we learned from our mistakes. The most important lesson being never to listen to James when it comes to programming =)
Check out our use of Box2D physics in the trailer below:
6 Comments
Kyle Peplow
Come across this problem too, my final solution was to store the previous frames data after generating the new position data. Then checked to see if the colliding objects path collided with the path of my player controlled entity. If a collision event occured I would take the time difference and used that to re-evaluate the players position either based elasticity of the entity or the desired effect of the design team (usually me).
Seems like you guys were very close to having your own implementation.
Hussain @ FuturLab
Hello Kyle. Yes absolutely, we were. The problem is that replicating the exact collision response of Box2D is quite hard to achieve. We wanted enough accuracy for response so player can throw telepod in a direction that will help solve the puzzles. But yes I believe our own implementation would’ve given close enough results too 😀
Dave Robinson (@5ypher)
Interesting! So after all this work, do you think you will be using this engine on your next game?
And at any point during development did you try out something like Unity/Unreal Engine etc?
Hussain @ FuturLab
Yes, if we are to make a 2/2.5D game, there is a good chance we will use our engine. No, the plan was always to use our own engine. We did consider 3rd party engines before we started development. But at that time, there was no certainty that Unity will be supporting Vita. Plus we are quite confident that achieving the level of visual flare ( Particle effects and post-processing) that we have for Velocity2X, would’ve been difficult with Unity for PS Vita. We wanted full low-level control over hardware for Vita.
Kyle Peplow
I don’t suppose we could get a post on Tools Development? Assuming there isn’t any concerns with sharing that publicly.
P.S. Velocity 2X free with PS+?! Hurry up and get those Velocity 2X items up on your store so I can pass the savings back to you guys.
Hussain @ FuturLab
Hi Kyle,
Will try to get a post done on tools too 🙂
There are more posts in the pipeline though .So watch this space for more posts 🙂
Thanks for your support. Yes, Velocity2X items will be on store very soon too and we will update via our mailing list 🙂
Thanks for support again 🙂