Playing video games is fun and hardcore.
(Programming) them is even more (hard + core)
Scroll down for details on my gaming project(s)
Grenade Throw Game
Music Source: http://www.uniquetracks.com/
|
The 3D Grenade throw game is my first and successful attempt at programming a desktop 3D game using
C++ for game logic Bullet Physics for game physics. Core profile openGL for rendering SOURCE available through Github at http://santoshwins.github.io/GrenadeThrowGame/ Currently, 3 Levels with varying difficulty settings are available for the user to choose from making gameplay interesting. Code architecture, collision detection and level design are explained in brief below. *Due credits for game assets goes to various free for download websites |
This Grenade throw game was conceptualized playing and reading about various physics and collision detection games. The idea was materialized by taking various common attributes that exists in all the current games like moving the player in XYZ axis, hitting them against opponents and reaching the final goal. This high level concept was then transformed into a specific 3D game model by identifying the game specific entities.
A Brief about the implementation:
GAME CODE-DESIGN CONSIDERATIONS
Once the most important game entities like the GRENADE (PLAYER), TANKS(OBSTACLES) and AMMUNITION BOX (FINAL GOAL) was finalized, the initial game design was further developed into a model diagram in terms of Class Diagrams. While developing the class diagram, MVC architecture was initially chosen, this on researching further looked heavy for a Game. It was more suited to GUI applications where the rendering would take place only as the models are updated which is less in frequency than a game where each frame is redrawn continuously.
Hence, the class diagram was modeled around the Game entities which acted as the game models participating in the game world. The Render engine was separated out of the models so as to provide the way to extend/replace the renderer to port the game across various platforms. Similarly, the Physics engine has also been separated enabling the game to work independently of any game engine used. Also, the Game controls and the Game logic were separated out to maintain modularity to handle user inputs and control the rules/flow of the game respectively.
Further, STL (maps and vectors) has been used in majority as the data structure to store various game models and other details.
INTEGRATION WITH BULLET PHYSICS ENGINE
Since the game is centrally designed to be a collision based game where the player throws a grenade and tries to avoid obstacles placed in its way, and since the term “throw” in itself reveals that some physical correctness is needed for the game to look real, bullet physics was suggested by my tutor. On research, it was found that bullet was much more powerful than any other open source engine currently available. So bullet engine was integrated into the code after much research about the way it creates the convex collision shapes, and the way it retrieves the contact points through continuous collision detection. Though it took some time to understand how it processed a custom mesh, with the help of some demo programs and personal research, I was successfully able to master bullet physics in the context of my game.
COLLISION DETECTION
GRAVITY and IMPULSE
Applying gravity and impulse to simulate the movement of the grenade added realism to the game and it was much more fun to play with than my own integration implementation.
LEVEL DESIGNS
LEVEL 1: As a start the trucks barely moves allowing the grenade to navigate freely through the 3D world to reach the Ammunition box physically present at the end of the sandbags.
LEVEL 2: To make the game more involved, this time the trucks would randomly move at VARYING SPEEDS in random DIRECTIONS within the playing battle field and hence the player has to think and decide when to throw the grenade to avoid hitting the moving trucks.
LEVEL 3: Yeah,the PRO level now. I decided to throw in some WIND force factor to affect the trajectory of the grande in air in order for the user to tackle both WIND and the MOVING TRUCKS. To assist the player, an ARROW pointing to the direction in which the WIND force is blowing from and the WIND SPEED is displayed intuitively as GIF animations and the most importantly the wind direction and the force is random for every turn of grenade throw. The player has to aim appropriately to compensate for the wind effect and has to successfully avoid the moving trucks as well.
DIFFICULTY SETTINGS
Apart from the various levels described above, there are two difficulty settings available which merely affects the NUMBER of TRUCKS which are going to oppose the player in the battle field. And these difficulty settings works independently across all the levels.
A Brief about the implementation:
GAME CODE-DESIGN CONSIDERATIONS
Once the most important game entities like the GRENADE (PLAYER), TANKS(OBSTACLES) and AMMUNITION BOX (FINAL GOAL) was finalized, the initial game design was further developed into a model diagram in terms of Class Diagrams. While developing the class diagram, MVC architecture was initially chosen, this on researching further looked heavy for a Game. It was more suited to GUI applications where the rendering would take place only as the models are updated which is less in frequency than a game where each frame is redrawn continuously.
Hence, the class diagram was modeled around the Game entities which acted as the game models participating in the game world. The Render engine was separated out of the models so as to provide the way to extend/replace the renderer to port the game across various platforms. Similarly, the Physics engine has also been separated enabling the game to work independently of any game engine used. Also, the Game controls and the Game logic were separated out to maintain modularity to handle user inputs and control the rules/flow of the game respectively.
Further, STL (maps and vectors) has been used in majority as the data structure to store various game models and other details.
INTEGRATION WITH BULLET PHYSICS ENGINE
Since the game is centrally designed to be a collision based game where the player throws a grenade and tries to avoid obstacles placed in its way, and since the term “throw” in itself reveals that some physical correctness is needed for the game to look real, bullet physics was suggested by my tutor. On research, it was found that bullet was much more powerful than any other open source engine currently available. So bullet engine was integrated into the code after much research about the way it creates the convex collision shapes, and the way it retrieves the contact points through continuous collision detection. Though it took some time to understand how it processed a custom mesh, with the help of some demo programs and personal research, I was successfully able to master bullet physics in the context of my game.
COLLISION DETECTION
- Even though there was a collision callback method offered by bullet physics, the constraints method of retrieving the contacts worked very well for this game and so it was used to detect the contact points.
- Once that was done, it was needed to detect WHICH specific pair has collided. This was done by utilizing the functionality of setting an arbitrary pointer inside each of the bodies added to the dynamic world.
- Then, this pointer was compared against each of the pairs to find out what objects have collided.
- Since bullet continuously detects collisions, it was needed to find a way to break out of it and prevent further collisions as, when the player got stuck to the obstacle, the score was rapidly getting reduced as the program assumed the grenade was colliding with the Truck repeatedly. Hence, whenever a collision occurred the btCollisionObject::CF_DISABLE_SPU_CILLISION_PROCESSING was used to disable the collision for a specific time period giving a fair chance for the player.
GRAVITY and IMPULSE
Applying gravity and impulse to simulate the movement of the grenade added realism to the game and it was much more fun to play with than my own integration implementation.
- body->setGravity() and body->applyCentralImpulse() were the preliminary functions used to move the objects around the world in addition to applying mass, friction and other restitution parameters for the world and the objects.
LEVEL DESIGNS
LEVEL 1: As a start the trucks barely moves allowing the grenade to navigate freely through the 3D world to reach the Ammunition box physically present at the end of the sandbags.
LEVEL 2: To make the game more involved, this time the trucks would randomly move at VARYING SPEEDS in random DIRECTIONS within the playing battle field and hence the player has to think and decide when to throw the grenade to avoid hitting the moving trucks.
LEVEL 3: Yeah,the PRO level now. I decided to throw in some WIND force factor to affect the trajectory of the grande in air in order for the user to tackle both WIND and the MOVING TRUCKS. To assist the player, an ARROW pointing to the direction in which the WIND force is blowing from and the WIND SPEED is displayed intuitively as GIF animations and the most importantly the wind direction and the force is random for every turn of grenade throw. The player has to aim appropriately to compensate for the wind effect and has to successfully avoid the moving trucks as well.
DIFFICULTY SETTINGS
Apart from the various levels described above, there are two difficulty settings available which merely affects the NUMBER of TRUCKS which are going to oppose the player in the battle field. And these difficulty settings works independently across all the levels.
iOS Mine Adventure Game (Shaft37 X25) - Group Work
MY ROLE EXPLAINED (presentation)
|
GAME PLAY VIDEO
|
Project WIKI page maintained by me available at https://sites.google.com/site/shaftwiki/ for collaborating and project management, with contributions from other members of the team.
Group Project: A complete iOS Third Person Mine adventure game named 'Shaft 37 - X25'. The group consisted of 9 members and we could come up with this in the midst of all the ongoing lectures and other assignments within a period of 4 weeks. As the Project Lead and Controls programmer, I also designed a complete WIKI page for this project. Link provided above.
Game Engine: UDK (Unreal Development Kit)
Playable in iPhone 4 and Above.
My Responsibilities and Roles in chronological order:
Project Management, Basic and Advanced game controls implementation, Cinematic with controls, Skeletal Mesh Research, Heads up display menu integration within the game
Game Engine: UDK (Unreal Development Kit)
Playable in iPhone 4 and Above.
My Responsibilities and Roles in chronological order:
Project Management, Basic and Advanced game controls implementation, Cinematic with controls, Skeletal Mesh Research, Heads up display menu integration within the game
A brief about the Implementation:
Basic and Advanced Controls through UDK visual programming
Basic and Advanced Controls through UDK visual programming
The basic controls such as moving the player in the desired direction to mimic instances of running was implemented using the swipe controls of the iphone.
Swipe Up Control to Move the player forwards Faster. Illustrated in the image are the UDK kismet nodes for the same.
Swipe Up Control to Move the player forwards Faster. Illustrated in the image are the UDK kismet nodes for the same.
Swipe Down Control to Move the player backwards Faster. Illustrated in the image are the UDK kismet nodes for the same.
A part of kismet nodes for gyro value fetching is illustrated here.
Gyroscope controls to generate rotation values to be applied to the free cam (the free cam was developed by another team member) and my part was to access the hardware to fetch gyro values. The yaw value of the hardware is taken and fed into the rotation of the orbiting free cam. The challenge was to implement mutual exclusion with the other controls as we did not want the gyro to be switched on always as it might put off the players if the view is always shaky. Hence, it was my decision to place a toggle button in the form of a video camera which the player can touch to toggle between the attached shoulder cam and the free cam. Also, in the free cam orbiting camera mode, we did not want the player to access the touch surface inputs as walking when a camera is orbiting around the character did not look good. So as part of game controls, whenever the free cam was used to access the gyro hardware, the touch to move controls were disabled.
Gyroscope controls to generate rotation values to be applied to the free cam (the free cam was developed by another team member) and my part was to access the hardware to fetch gyro values. The yaw value of the hardware is taken and fed into the rotation of the orbiting free cam. The challenge was to implement mutual exclusion with the other controls as we did not want the gyro to be switched on always as it might put off the players if the view is always shaky. Hence, it was my decision to place a toggle button in the form of a video camera which the player can touch to toggle between the attached shoulder cam and the free cam. Also, in the free cam orbiting camera mode, we did not want the player to access the touch surface inputs as walking when a camera is orbiting around the character did not look good. So as part of game controls, whenever the free cam was used to access the gyro hardware, the touch to move controls were disabled.
Pick axe cinematic in game play - The aim of the player is to pick up parts of pick axe so as to obtain a full axe. On touching the second part of the axe while holding the first part in hand, the current weapon held by the player is swapped with a full axe which is originally hidden when the level is loaded. Once the player has the full axe, he would be able to break open the wooden doors on his way. For this, the logic of checking whether the character is indeed possessing a weapon has been implemented as part of the game controls. Once he decides to break the door, a cinematic animation of hitting the door is played using the Matinee nodes in kismet. This matinee implementation of hooking up a pre baked animation of the character in place of the act of breaking the wooden door has been implemented by me as part of game controls.
In the UDK engine, whenever a weapon had to be attached to a character mesh, the weapon had to be a skeletal mesh rather than a static mesh which meant the modellers had to be informed that whatever weapon they had modelled needed one root joint to attach the character’s palms joint onto it. This research was carried out by me and implemented across the game to pick up the items such as lantern and pick axe. Apart from the joint in the skeletal mesh, the weapon also needed a physics asset (UDK term meaning collision boundaries) for the functionality of attachment to work. The physics asset to create the collision box was done using UDK’s PHAT editor as illustrated.