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.
Tuesday, February 26, 2013
After Gate 1 Presentation
Yesterday we did our Gate 1 presentation. We got a lot of useful feedback. Yet Yang and me also worry about our game is too simple to do. If we take out the dog and survival feature, it seems there is nothing more for our game. I think, we do need more on our game.
How about the personalization of each dog? So that different dogs have different abilities. How about the Courage System we just talked before? How about the different forms for dog groups?
Worry about we can't make it? Well, I believe we can make it. Here are the reasons.
First, we have totally a year to make the game. Even if the true time is not an entire year, at least we have several month to make it.
Second, we have 4 engineers, I think it is enough to build our game code. We can handle crap even if Moai, so there should be no problem to use other better engine or library such as OGRE or CryEngine to build our game.
Third, I would like to take my experience as an example to compare to our project. 2 years ago I was in a 9-people team to build a 3D Angry Birds. We don't have artist and producer, all of us were programmer, so that some of us turn to artists and project manager. And the actual number of programmers for coding was 4. However we only had 1 month to build the game, and using OGRE, which was completely new to all of us. And yes, only 1 month, we made it, even if there were a lot of bugs in the game, but at least, the game could be played. And yes again, we built our birds and pigs model, built the configuration file system, built the GUI and control system, involved OGRE and Bullet Physics engine, all by ourselves. So you see, even a team of undergrads can built a fully-play game in only 1 month, with entry level engine architecture, why couldn't our GRADUATED students can make a larger scope game in a year?
So, I hope our naive game design can pass Gate 1. Then, I do like to increase the scope so make the game deeper, more interesting.
明主良相上将俱备，何惧安天下？
How about the personalization of each dog? So that different dogs have different abilities. How about the Courage System we just talked before? How about the different forms for dog groups?
Worry about we can't make it? Well, I believe we can make it. Here are the reasons.
First, we have totally a year to make the game. Even if the true time is not an entire year, at least we have several month to make it.
Second, we have 4 engineers, I think it is enough to build our game code. We can handle crap even if Moai, so there should be no problem to use other better engine or library such as OGRE or CryEngine to build our game.
Third, I would like to take my experience as an example to compare to our project. 2 years ago I was in a 9-people team to build a 3D Angry Birds. We don't have artist and producer, all of us were programmer, so that some of us turn to artists and project manager. And the actual number of programmers for coding was 4. However we only had 1 month to build the game, and using OGRE, which was completely new to all of us. And yes, only 1 month, we made it, even if there were a lot of bugs in the game, but at least, the game could be played. And yes again, we built our birds and pigs model, built the configuration file system, built the GUI and control system, involved OGRE and Bullet Physics engine, all by ourselves. So you see, even a team of undergrads can built a fully-play game in only 1 month, with entry level engine architecture, why couldn't our GRADUATED students can make a larger scope game in a year?
So, I hope our naive game design can pass Gate 1. Then, I do like to increase the scope so make the game deeper, more interesting.
明主良相上将俱备，何惧安天下？
Monday, February 11, 2013
Code works first, Optimize it later
This week I implement some features on our prototype. Now in our prototype, the worker can move the Tech Parts back to the base but with low moving speed. And worker can collect oxygen pack as their HP refill (we also have 3D HP bar for workers!), a minimap showing position information of units and base.
Unity is a powerful tool to make prototype work. I don't need to worry too much about run time error. In Unity, even my script have some stupid operation (use null pointer, etc.), the prototype game can still run, then Unity has its log to indicate where goes wrong.
Also, I haven't consider too much details when I coding. I think that should be how things start, even in software engineering. We can always go on detail design, build framework architecture, and code in deep until final product come out. But at first, is this product, idea, or concept worth to implement? Prototype is for answering this question. We don't need to think too much detail in prototype. All we need to worry is the core concept, core mechanic of the game.
As the title said, after rushing some garbage code, we should think about the real game. What game engine should we use? How the architecture should be? I will prefer to use OGRE as our basic engine. There are several reasons. First, it is completely open-source, so we don't need to worry about license like UDK. Second, OGRE also has its wiki, forum, so that we can always go to find someone for help, and the forum is kept updating. Third, OGRE is a C++ engine, and there are several concept similar to what we learn in Game Engineering II, so that it is a good practice for our engineers. OGRE can also be a good reference for our Game Engineering assignments.
OGRE official website: http://www.ogre3d.org/
Thanks for our producer Zeph, we have our own awesome website. Check it out!
Team dawgz: http://www.teamdawgz.com/
Unity is a powerful tool to make prototype work. I don't need to worry too much about run time error. In Unity, even my script have some stupid operation (use null pointer, etc.), the prototype game can still run, then Unity has its log to indicate where goes wrong.
Also, I haven't consider too much details when I coding. I think that should be how things start, even in software engineering. We can always go on detail design, build framework architecture, and code in deep until final product come out. But at first, is this product, idea, or concept worth to implement? Prototype is for answering this question. We don't need to think too much detail in prototype. All we need to worry is the core concept, core mechanic of the game.
As the title said, after rushing some garbage code, we should think about the real game. What game engine should we use? How the architecture should be? I will prefer to use OGRE as our basic engine. There are several reasons. First, it is completely open-source, so we don't need to worry about license like UDK. Second, OGRE also has its wiki, forum, so that we can always go to find someone for help, and the forum is kept updating. Third, OGRE is a C++ engine, and there are several concept similar to what we learn in Game Engineering II, so that it is a good practice for our engineers. OGRE can also be a good reference for our Game Engineering assignments.
OGRE official website: http://www.ogre3d.org/
Thanks for our producer Zeph, we have our own awesome website. Check it out!
Team dawgz: http://www.teamdawgz.com/
Monday, February 4, 2013
Rushing for prototype
This week we had change a game a lot. Instead of typical RTS combat, we made the game more about survival. In the game you can start with 5 penguin, and your mission is to collect enough technique parts to repair your spaceship so that you can go back to earth. For each penguin it has limited oxygen resources, and the oxygen is time-based consuming. There are multiple oxygen packs randomly spread out in the map. These oxygen packs can refill to the penguins a little bit. And when a penguin pick up a technique part to move it back to the base, the penguin would move slower because it is carrying something.
For the prototype, I am working on the collection and moving speed slow down. With Unity, we already found a raw project done by other from the Internet. To build a prototype, I still need more time to figure it out. So, I create a video to show the idea first just in case I can't make the Unity prototype.
For an RTS game, I think the basics features should be select and give command. I am still looking on it.
For the prototype, I am working on the collection and moving speed slow down. With Unity, we already found a raw project done by other from the Internet. To build a prototype, I still need more time to figure it out. So, I create a video to show the idea first just in case I can't make the Unity prototype.
For an RTS game, I think the basics features should be select and give command. I am still looking on it.
Monday, January 28, 2013
RTS Game pitch
Finally we formed another team and decided to build an RTS game.
When we talk about RTS game, it is easily to raise up many typical RTS, such as Warcraft, Starcraft, Age of Empire, Command and Conque, etc. RTS games have many similar feature, and how to make our game unique was our team's No. 1 question. And also because there is 6 members in our team, we can not make a Warcraft scope game like Blizzard. So, we come up with the game idea which is single screen and cute art style game. We also come up with a courage system, which mean the unit ability will affect by its courage value.
For the prototype, we want to make it as simple as possible but also include our core idea. The premise of the game is, you are traveling into the space. Unfortunately, your spaceship crash into Mars, and you need to explore the planet to find parts to repair your spaceship to escape. At the same time, aliens may also attack you, you may need to collect resources to build your defense. For the prototype, you only begin with 5 penguins to collect resources and find parts.
The further work for the game will be: different parts may need different amounts penguins to move it to the base; parts could be alien labs, player can build their own labs base on them and upgrade weapons; it can be 3 kinds of penguin and 3 kinds of alien, they all have their unique ability; penguins could chose to equip different kinds of weapons.
I also have thought about how to apply Kingdom Hierarchy System into the game. The basic thought is, when a group of penguin was defeated, they loose all their weapons, but they still alive with their own level. The penguin could die only if they continue getting attack after they are defeated.
When we talk about RTS game, it is easily to raise up many typical RTS, such as Warcraft, Starcraft, Age of Empire, Command and Conque, etc. RTS games have many similar feature, and how to make our game unique was our team's No. 1 question. And also because there is 6 members in our team, we can not make a Warcraft scope game like Blizzard. So, we come up with the game idea which is single screen and cute art style game. We also come up with a courage system, which mean the unit ability will affect by its courage value.
For the prototype, we want to make it as simple as possible but also include our core idea. The premise of the game is, you are traveling into the space. Unfortunately, your spaceship crash into Mars, and you need to explore the planet to find parts to repair your spaceship to escape. At the same time, aliens may also attack you, you may need to collect resources to build your defense. For the prototype, you only begin with 5 penguins to collect resources and find parts.
The further work for the game will be: different parts may need different amounts penguins to move it to the base; parts could be alien labs, player can build their own labs base on them and upgrade weapons; it can be 3 kinds of penguin and 3 kinds of alien, they all have their unique ability; penguins could chose to equip different kinds of weapons.
I also have thought about how to apply Kingdom Hierarchy System into the game. The basic thought is, when a group of penguin was defeated, they loose all their weapons, but they still alive with their own level. The penguin could die only if they continue getting attack after they are defeated.
Subscribe to:
Posts (Atom)