Game Engines - Roboy Phyre Engine 4
On a positive note regarding our progress, this blog is the fourth iteration of our adventures with Phyre and will go over how gameplay is starting to shape up now that we understand the new ideas and concepts required for Phyre, and now that we understand a lot better what is happening at lower level fundamentals of the engine.
At this point we have become extremely familiar with the samples, and handling the project and performing mundane tasks that previously were not known at all how to implement, has become a breeze. Getting a lot more comfortable with the engine means that we can focus on building our prototype and trying to polish some of the dirty code we wrote up to get things working. This blog I will go over how we started to flesh out our game prototype given our accumulated understanding of the Phyre engine as a whole.
Staring off, I would also like to state that getting our assets from Maya and into the game engines also proved a difficult task. We invested a lot of time simply reading through and navigated the XML files that the Collada shader exported for the Phyre engine, as well as sniffing around the Phyre level editor files to understand how the media and components are linked when the Phyre importer creates the level.
We found that a lot of errors were coming from incorrect file paths and dependencies on the media assets we were exporting as .dae through the Collada shader. Even setting the project directory to the correct path and using relative paths did not work sometimes, as adding the Collada shader file to the asset was still using absolute paths. We found the solution to be creating an environment variable and sticking it in the file path after we choose and link the Collada shader to the asset we wanted to export.
Moving on to actual gameplay, going over the samples we were easily able to pick away at the CharacterController component included in Phyre, and were able to mess around with inputs to make the player feel more smooth. Also because of the samples we were able to attach a character camera and move it smoothly with the player input to make the game feel just right, all as mentioned in a previous blog post.
Now moving on, since we have player movement, another main aspect of our game is shooting, so at this point in development we focused on getting ray casting algorithms to work as expected, and with the result show something happening that clearly relates to the inputs to make sure it is working. At this point we weren't worried about shooting enemies, but more getting the shot to register on an object and see the physics feedback.
First of all, we set up 2 separate cameras that will later be implemented as locators, as we can ease one camera between the points. These points both move with the left and right rotation the same way, and as the player holds the aiming button, the camera switches to the closer on and we start rendering cross hairs in the center of the screen. Now this all looks good, but we actually need it to do something, so we took to the samples for a raycast callback.
We found that it was as easy as calling a raycast function in the physics world instance, that took the parameters: to, from, and result. The function returns a bool if there was a collision or not, and result holds very valuable information such as the object it hit, the angle it hit, and the point it hit.
The next step was figuring out how to calculate our to and from. Assuming the player will be always aiming in the center of the screen, since our cross hairs are fixed at the moment, we concluded that:
After that, we looked through the documentation and found that the result that included the object that was hit returns a PBase, which is the most basic class that only includes memory functions. Since we need a rigid body instance to do anything useful with the hit object, it was just a simple static cast to that class. From there we could easily access the functions we needed to, such as setLinearForce, where we easily sent in the normals calculated from the ray cast on the object, inverted, and multiplied by the force of the gun. This simply simulated the object being pushed by a force directly at the point it was shot at.
As a side note, we found a nice trick in one of the samples, the situation was that the enemy squads need to cast a ray to see if the player is visible to them. Instead of wasting a cast on the returned object that was hit, they simply compare the distances between the alien position, and the point of intersection. I thought that was pretty clever, so I'll be ending this blog on setting up the raycast for our game, which turned out nicely. As of now, players can shoot floating ice cream trucks that get pushed around by the shot, as expected.
At this point we have become extremely familiar with the samples, and handling the project and performing mundane tasks that previously were not known at all how to implement, has become a breeze. Getting a lot more comfortable with the engine means that we can focus on building our prototype and trying to polish some of the dirty code we wrote up to get things working. This blog I will go over how we started to flesh out our game prototype given our accumulated understanding of the Phyre engine as a whole.
Staring off, I would also like to state that getting our assets from Maya and into the game engines also proved a difficult task. We invested a lot of time simply reading through and navigated the XML files that the Collada shader exported for the Phyre engine, as well as sniffing around the Phyre level editor files to understand how the media and components are linked when the Phyre importer creates the level.
We found that a lot of errors were coming from incorrect file paths and dependencies on the media assets we were exporting as .dae through the Collada shader. Even setting the project directory to the correct path and using relative paths did not work sometimes, as adding the Collada shader file to the asset was still using absolute paths. We found the solution to be creating an environment variable and sticking it in the file path after we choose and link the Collada shader to the asset we wanted to export.
Moving on to actual gameplay, going over the samples we were easily able to pick away at the CharacterController component included in Phyre, and were able to mess around with inputs to make the player feel more smooth. Also because of the samples we were able to attach a character camera and move it smoothly with the player input to make the game feel just right, all as mentioned in a previous blog post.
Now moving on, since we have player movement, another main aspect of our game is shooting, so at this point in development we focused on getting ray casting algorithms to work as expected, and with the result show something happening that clearly relates to the inputs to make sure it is working. At this point we weren't worried about shooting enemies, but more getting the shot to register on an object and see the physics feedback.
First of all, we set up 2 separate cameras that will later be implemented as locators, as we can ease one camera between the points. These points both move with the left and right rotation the same way, and as the player holds the aiming button, the camera switches to the closer on and we start rendering cross hairs in the center of the screen. Now this all looks good, but we actually need it to do something, so we took to the samples for a raycast callback.
We found that it was as easy as calling a raycast function in the physics world instance, that took the parameters: to, from, and result. The function returns a bool if there was a collision or not, and result holds very valuable information such as the object it hit, the angle it hit, and the point it hit.
The next step was figuring out how to calculate our to and from. Assuming the player will be always aiming in the center of the screen, since our cross hairs are fixed at the moment, we concluded that:
- From = the gun position
- To = a point in any direction a fixed length from the tip of the gun
Now calculating this was fairly easy:
 |
| Simply normalize the camera direction, and move it to the gun position |
After that, we looked through the documentation and found that the result that included the object that was hit returns a PBase, which is the most basic class that only includes memory functions. Since we need a rigid body instance to do anything useful with the hit object, it was just a simple static cast to that class. From there we could easily access the functions we needed to, such as setLinearForce, where we easily sent in the normals calculated from the ray cast on the object, inverted, and multiplied by the force of the gun. This simply simulated the object being pushed by a force directly at the point it was shot at.
As a side note, we found a nice trick in one of the samples, the situation was that the enemy squads need to cast a ray to see if the player is visible to them. Instead of wasting a cast on the returned object that was hit, they simply compare the distances between the alien position, and the point of intersection. I thought that was pretty clever, so I'll be ending this blog on setting up the raycast for our game, which turned out nicely. As of now, players can shoot floating ice cream trucks that get pushed around by the shot, as expected.
Comments
Post a Comment