Since "Rover Rescue" get cut, I turn to the "Vinyl" game team.
Vinyl is a music game which it give you audio feedback (or reward) about your game play performance. It is a third person view game, you are looking at the vinyl pin and control it like a skate board. And the pin is traveling inside a vinyl track. We already have a video of the prototype:
http://www.youtube.com/watch?feature=player_embedded&v=IQGS7w8ybnA
Right now I am adding physical simulation to the pin movement. It should look like skate boarding. I am using a 2D space to calculate the position, and then project it back to the actual 3D space. The reason I do in this way is I want the pin constraint on the track surface. So the pin movement is actually in a 2D space. I think this idea maybe similar to a subject in Machine Learning - Kernel Space projection.
Wednesday, April 10, 2013
"Rover Rescue" Get Cut and Now it Turned to be a "Zombie" Project
Rover Rescue get cut in about one month ago. Sorry for updating it so late.
It was very tough for us to face the truth that our lovely Rover get cut at that time. Every thing seemed very good at that time but suddenly, 4 thesis games cut down to 2 games and Rover was one of them that fail.
However, some of the Rover team member still wanted to make this game. We decide to go on and make Rover as a "Zombie" project. So far our Rover team has 5 people: Zeph, Chongze Yang, Ziyao Chen (new member!), Alice and me. We went over the suggestion from the Gate 1 presentation, and discussed about how to re-design the game. Some features kept and we are going to make another prototype first on CryEngine.
As a programmer, I don't like those GUI game engine such as Unity, CryEngine, UDK. That's because I don't have 100% freedom to build my own thing. However, consider that we don't have many people, and probably don't have much time to work together. Also, if we going to build our own engine first, it would take a long time before we begin to build the game. So I think we can build the game on CryEngine first, build the mechanics, to see if it is great. Then, we can decide whether to build our own engine for the game and redo everything. The idea of this is sometimes maybe CryEngine implement the game in the way not we want, or it may do thing stupid though it still make things work. So we can rebuild the game in our own engine, and make our engine to the right thing.
Of cause, we may not be able to build every thing of the engine if we decide to make it. I'd like to build the engine base on some 3rd party open-source library such as OGRE and Bullet-Physics. Those C++ library doesn't have a GUI environment, but has enough manipulation to build a costume engine as well as some basic support such as rendering and physics simulation.
It was very tough for us to face the truth that our lovely Rover get cut at that time. Every thing seemed very good at that time but suddenly, 4 thesis games cut down to 2 games and Rover was one of them that fail.
However, some of the Rover team member still wanted to make this game. We decide to go on and make Rover as a "Zombie" project. So far our Rover team has 5 people: Zeph, Chongze Yang, Ziyao Chen (new member!), Alice and me. We went over the suggestion from the Gate 1 presentation, and discussed about how to re-design the game. Some features kept and we are going to make another prototype first on CryEngine.
As a programmer, I don't like those GUI game engine such as Unity, CryEngine, UDK. That's because I don't have 100% freedom to build my own thing. However, consider that we don't have many people, and probably don't have much time to work together. Also, if we going to build our own engine first, it would take a long time before we begin to build the game. So I think we can build the game on CryEngine first, build the mechanics, to see if it is great. Then, we can decide whether to build our own engine for the game and redo everything. The idea of this is sometimes maybe CryEngine implement the game in the way not we want, or it may do thing stupid though it still make things work. So we can rebuild the game in our own engine, and make our engine to the right thing.
Of cause, we may not be able to build every thing of the engine if we decide to make it. I'd like to build the engine base on some 3rd party open-source library such as OGRE and Bullet-Physics. Those C++ library doesn't have a GUI environment, but has enough manipulation to build a costume engine as well as some basic support such as rendering and physics simulation.
Be careful when dealing with C++ floating point.
Look at this piece of code:
Vector3 colPlaneNor;
float dx = abs(aabb1->getPosition().x() - aabb2->getPosition().x());
float dy = abs(aabb1->getPosition().y() - aabb2->getPosition().y());
if(dx < (aabb1->_width + obb2->_width)/2.0f)
colPlaneNor = Vector3::UNIT_Y;
else if(dy < (aabb1->_height + aabb2->_height)/2.0f)
colPlaneNor = Vector3::UNIT_X;
The idea of these lines of code is to determine the collision plane normal when two AABB boxes collided. The problem here is, floating point calculation is not 100% accurate. Even if the true is
dx == (aabb1->_width + obb2->_width)/2.0f,
and
dy < (aabb1->_height + aabb2->_height)/2.0f
But in C++, the floating point number dx may slightly less than
(aabb1->_width + obb2->_width ) / 2.0f
That will cause the code pass the if()test first and set the collision plane normal to a wrong vector.
My solution here is to make the threshold a little bit lower:
if(dx < (aabb1->_width + aabb2->_width)*.99f/2.0f)
colPlaneNor = Vector3::UNIT_Y;
else if(dy < (aabb1->_height + aabb2->_height)*.99f/2.0f)
colPlaneNor = Vector3::UNIT_X;
Instead of compare the actual sum, I multiply the sum by 0.99. So even if dx is slightly lower than the actual result, it won't pass the if() test and jump into the else if(). If the collision plane normal should be normal Y, dy should still smaller (aabb1->_height + aabb2->_height)*.99f/2.0f.
If both dx and dy are actually equal to the sums, that means the two AABB is colliding on the coner, or maybe very closed to the corner. In this case I can make a default vector for the collision plane normal, such as normal X.
Vector3 colPlaneNor;
float dx = abs(aabb1->getPosition().x() - aabb2->getPosition().x());
float dy = abs(aabb1->getPosition().y() - aabb2->getPosition().y());
if(dx < (aabb1->_width + obb2->_width)/2.0f)
colPlaneNor = Vector3::UNIT_Y;
else if(dy < (aabb1->_height + aabb2->_height)/2.0f)
colPlaneNor = Vector3::UNIT_X;
The idea of these lines of code is to determine the collision plane normal when two AABB boxes collided. The problem here is, floating point calculation is not 100% accurate. Even if the true is
dx == (aabb1->_width + obb2->_width)/2.0f,
and
dy < (aabb1->_height + aabb2->_height)/2.0f
But in C++, the floating point number dx may slightly less than
(aabb1->_width + obb2->_width ) / 2.0f
That will cause the code pass the if()test first and set the collision plane normal to a wrong vector.
My solution here is to make the threshold a little bit lower:
if(dx < (aabb1->_width + aabb2->_width)*.99f/2.0f)
colPlaneNor = Vector3::UNIT_Y;
else if(dy < (aabb1->_height + aabb2->_height)*.99f/2.0f)
colPlaneNor = Vector3::UNIT_X;
Instead of compare the actual sum, I multiply the sum by 0.99. So even if dx is slightly lower than the actual result, it won't pass the if() test and jump into the else if(). If the collision plane normal should be normal Y, dy should still smaller (aabb1->_height + aabb2->_height)*.99f/2.0f.
If both dx and dy are actually equal to the sums, that means the two AABB is colliding on the coner, or maybe very closed to the corner. In this case I can make a default vector for the collision plane normal, such as normal X.
Subscribe to:
Posts (Atom)