So begins part 2 of our documentation. Over the past week, we've refined some of the game features and got a lot of stuff working.
Our game concept remains the same - a player vs. player tower defense/strategy type game. Each player will have to defend their own castle against the troops that the other player sends towards them. Each unit will have its own cost, so players must choose wisely whether they want to be on the offense or defense. 4 unit types are available: foot soldiers, tanks, cannons, and walls, each with their own unique attack and defense properties. Cannons, for example, have bonus damage against walls but have low movement speed and attack rates, while foot soldiers attack and move very fast but have very low health, etc.
There is obviously quite a bit of game logic to be programmed, to determine what the units do to one another in the scene, and how they attack or defend.
On the offensive side, a simple collision box detection can be done. Each unit will have its own hit box (a box that determines their attack range, which is shorter on foot soldiers and longer on cannons, for example) in addition to its own object model bounding box, and if its hit box intersects another unit's object model bounding box (which can be done very quickly with planar intersection tests), then that means that unit is within attack range. In order to distinguish whether that unit is an ally or enemy, each unit created in the scene has a unique ID - units created by the Leap Motion player have a positive number for the ID (3, 4, 5, 6, etc.), while units created by the Oculus Rift player have a negative number for the ID (-3, -4, -5, -6, etc.).
On the defensive side, well, there's not really anything special to be checked for. If a unit gets attacked, then it just needs to check if its health is negative - if it is, then it removes itself from the game field.
Network communications are kept as simple as possible to ensure the two clients are as synced as possible. The following data is sent to and from the server:
Our game concept remains the same - a player vs. player tower defense/strategy type game. Each player will have to defend their own castle against the troops that the other player sends towards them. Each unit will have its own cost, so players must choose wisely whether they want to be on the offense or defense. 4 unit types are available: foot soldiers, tanks, cannons, and walls, each with their own unique attack and defense properties. Cannons, for example, have bonus damage against walls but have low movement speed and attack rates, while foot soldiers attack and move very fast but have very low health, etc.
There is obviously quite a bit of game logic to be programmed, to determine what the units do to one another in the scene, and how they attack or defend.
On the offensive side, a simple collision box detection can be done. Each unit will have its own hit box (a box that determines their attack range, which is shorter on foot soldiers and longer on cannons, for example) in addition to its own object model bounding box, and if its hit box intersects another unit's object model bounding box (which can be done very quickly with planar intersection tests), then that means that unit is within attack range. In order to distinguish whether that unit is an ally or enemy, each unit created in the scene has a unique ID - units created by the Leap Motion player have a positive number for the ID (3, 4, 5, 6, etc.), while units created by the Oculus Rift player have a negative number for the ID (-3, -4, -5, -6, etc.).
On the defensive side, well, there's not really anything special to be checked for. If a unit gets attacked, then it just needs to check if its health is negative - if it is, then it removes itself from the game field.
Network communications are kept as simple as possible to ensure the two clients are as synced as possible. The following data is sent to and from the server:
- The positions of the hands of the rift player and the leap motion player
- The positions of the heads of the rift player and the leap motion player
- A notification that a unit was spawned with a specific ID and type
- The unit spawn location can be inferred by using the other player's last known hand position as received from the server
- A notification that a unit was picked up
- Which unit got picked up, again, can be inferred by using the other player's last known hand position
- A notification that the picked up unit was placed down
Below are some screenshots of our current progress on the game:
The Red cube represents the opponents head position (for the Leap Motion this is the camera from which the scene is viewed). The Green Cube represents the position and orientation of the player's own hand, and the Blue Cube represents the opponent's hand.
Here is a screenshot of a game in progress, with the view from Oculus and Leap Motion being at the same time.
The Red cube represents the opponents head position (for the Leap Motion this is the camera from which the scene is viewed). The Green Cube represents the position and orientation of the player's own hand, and the Blue Cube represents the opponent's hand.
Here is a screenshot of a game in progress, with the view from Oculus and Leap Motion being at the same time.
No comments:
Post a Comment