Game Engines - Roboy Phyre Engine 1
Finally some progress on our actual game. Up to now we have been focusing on getting core fundamentals of the Phyre Engine up and running, such as installing, setting up paths, compiling, and deploying. Everything works now and we got a demo working on the actual PS3 devkit, deployed over the network. Michael has been working hard to configure all the build configurations to work properly and getting all the configurations to work as expected. We now actually have our first repository set up for our game, all cleaned out with a new Phyre Engine blank project!
Before I go into much detail about the mechanics of the Phyre Engine samples and how they will relate to our game, let's go over a quick toverview of out GDW game concept.
Our GDW game this year is a sequel to our first year game, Roboy. For this game we are planning on developing an open world-esque environment with characteristics of "the hood". The premise of the game is that Roboy has become a cop and is assigned to various districts of a city to clean up the crime. As for the mechanics of the game, it is going to be a 3rd person view where the player has full control of the camera, the camera will ease into an over the shoulder view when the player is aiming. The game is going to be a shooting focused mission driven game.
Moving on to the actual PS3 engine, Sony developed a multi-platform free to use game and graphics engine that has capabilities for physics engines to be used in between. Phyre by default uses Bullet physics, and each component is integrated in to each other. We have access to various samples and in depth documentation so we should be able to figure things out.
Based on the samples included with Phyre, the camera and movement is handled deep in the Phyre core and the defaults take a lot of inheritance to change. Since we are working as a team it would not make sense to be changing the source Phyre files, since the repository would have to sync a ridiculous amount of data. Instead we will be overriding a lot of the camera and movement physics and handles. As an aside, the camera in our game in theory does not differ much from the camera implementation present in the third person camera sample included with Phyre. I think with some tweaking to get it perfectly how we need, it shouldn't be too much work to implement the camera for our game with the sample code.
If we do end up needing to rewrite camera code for use in the Phyre engine for our game, it shouldn't be too difficult given the following simple concepts:
This may however provide some problems regarding the Phyre::Physics namespace of the camera. Since the cameras will be parented to the player, and rotations will displace the positions by sometimes large amounts, the camera collision with the world geometry might not work properly without additional configuring. A possible solution may be to convert the rotation inputted from the player that will be applied the character's rotation to a vector representing the direction the camera needs to move in order to mimic the player actually rotating the camera child. We could then implement smoothing and easing with the direction vector and some scales. I think I will go over more on this topic later on if we end up changing the default camera classes and implementations too much.
Similar concepts apply for the phyre engine movement we are going to tweak and implement in our game, the inheriting part not the parenting part. Since locomotion and feel of the input of our game is extremely important to the end product of our game, we will be heavily modifying the examples for the built in physics driven character movements so that our game feels just right and how we intended. This is vital to driving any game mechanic or enforcing certain game elements and missions or challenges. We have a lot of different ideas on how we precisely want the input and locomotion to feel, but for the focus is on understanding the physics driven character locomotion in the samples. Looking on the surface, a lot of the code is again buried deep in the Phyre core, but the values are still modifiable This doesn't make sense to change as stated before, but we discovered the values can easily be modified by lua scripts that you can define to be included and handled in our assets.xml which Phyre will parse and implement. Using this we can tweak values with trial and error to simulate and test some input variations to get the final input to feel just right.
Next I will be going over my findings with the math involved in getting dual analog stick input to move a character as expected in a 3D free camera oriented environment.
 |
| Roboy 2 repo @MikeDaProgramma |
Before I go into much detail about the mechanics of the Phyre Engine samples and how they will relate to our game, let's go over a quick toverview of out GDW game concept.
Our GDW game this year is a sequel to our first year game, Roboy. For this game we are planning on developing an open world-esque environment with characteristics of "the hood". The premise of the game is that Roboy has become a cop and is assigned to various districts of a city to clean up the crime. As for the mechanics of the game, it is going to be a 3rd person view where the player has full control of the camera, the camera will ease into an over the shoulder view when the player is aiming. The game is going to be a shooting focused mission driven game.
 |
| http://research.scee.net/images/source_banner.png |
Moving on to the actual PS3 engine, Sony developed a multi-platform free to use game and graphics engine that has capabilities for physics engines to be used in between. Phyre by default uses Bullet physics, and each component is integrated in to each other. We have access to various samples and in depth documentation so we should be able to figure things out.
Based on the samples included with Phyre, the camera and movement is handled deep in the Phyre core and the defaults take a lot of inheritance to change. Since we are working as a team it would not make sense to be changing the source Phyre files, since the repository would have to sync a ridiculous amount of data. Instead we will be overriding a lot of the camera and movement physics and handles. As an aside, the camera in our game in theory does not differ much from the camera implementation present in the third person camera sample included with Phyre. I think with some tweaking to get it perfectly how we need, it shouldn't be too much work to implement the camera for our game with the sample code.
If we do end up needing to rewrite camera code for use in the Phyre engine for our game, it shouldn't be too difficult given the following simple concepts:
- We parent the camera to the player and position it back and up from the player origin a variable amount
- We ease between 2 defined cameras when the player holds the aiming button
 |
| Parenting and defining 2 cameras to the player |
 |
| Rotations applied the character will keep the camera behind the player |
This may however provide some problems regarding the Phyre::Physics namespace of the camera. Since the cameras will be parented to the player, and rotations will displace the positions by sometimes large amounts, the camera collision with the world geometry might not work properly without additional configuring. A possible solution may be to convert the rotation inputted from the player that will be applied the character's rotation to a vector representing the direction the camera needs to move in order to mimic the player actually rotating the camera child. We could then implement smoothing and easing with the direction vector and some scales. I think I will go over more on this topic later on if we end up changing the default camera classes and implementations too much.
Similar concepts apply for the phyre engine movement we are going to tweak and implement in our game, the inheriting part not the parenting part. Since locomotion and feel of the input of our game is extremely important to the end product of our game, we will be heavily modifying the examples for the built in physics driven character movements so that our game feels just right and how we intended. This is vital to driving any game mechanic or enforcing certain game elements and missions or challenges. We have a lot of different ideas on how we precisely want the input and locomotion to feel, but for the focus is on understanding the physics driven character locomotion in the samples. Looking on the surface, a lot of the code is again buried deep in the Phyre core, but the values are still modifiable This doesn't make sense to change as stated before, but we discovered the values can easily be modified by lua scripts that you can define to be included and handled in our assets.xml which Phyre will parse and implement. Using this we can tweak values with trial and error to simulate and test some input variations to get the final input to feel just right.
Next I will be going over my findings with the math involved in getting dual analog stick input to move a character as expected in a 3D free camera oriented environment.
Comments
Post a Comment