Capture the Flag

Abstract
Game Title:	Capture the Flag
Development Team Members:	Young Sub Bae, Yoon Ji Nam
Game Genre:	Arcade
Brief Description:	It’s the world of spheres. Control your sphere in the world in order to avoid or attack the enemy spheres and get to the flag.
Overview
Game Story / Objective:	There is no more space on the Earth for people to live, and you are given an objective of finding planets in the space where people can settle. You decide to send a space capsule in a newly found planet, and your object is to check if the planet is human-friendly. Be aware of the aggressive natives; they try to attack your capsule. There is a flag on each planet. If you successfully get to the flag, the planet is determined to be human-friendly, and you get a chance to explore another planet (maybe more hostile). However, if your capsule is destroyed, the planet is decided to be uninhabitable and your exploration is over.
Game Mechanics + Controls:	The black & white sphere in the center of the sphere is the one that you control. You can choose its direction, which is indicated by a little white dot right next to the user sphere, with left/right arrow keys and move it forward / backward with up/down arrow keys. There are two types of enemies that makes it hard for you to get your sphere to the flag. One type consists of yellow & white spheres. Those spheres are stationary, and they shoot bullets. Those spheres have three different offense skills. One skill is to shoot bullets in a fixed direction, another is to rotate and shoot bullets, and the other is to shoot bullets always towards the user sphere. The other type of enemy is a blue & white sphere. It roams around the planet with a random direction. However, if the user ball is within a certain range from this enemy, it will chase the user sphere and try to make consecutive contacts. Each contact causes a decrease of the user’s HP by 15. If the user presses space, the user sphere will spin at the current location and when the key is released, the spinning sphere will be launched toward its direction for a fixed distance, and this is the attacking action of the user sphere. If it hits an enemy while it is in the offense mode, the enemy will be destroyed. Even if it is in the offense mode, it will get hurt if it contacts a bullet. If it’s not in the offense mode, it will get hurt if it contacts a bullet or an enemy. The user sphere initially has 100 HP. If it contacts a bullet, its HP will decrease by 35, and if it contacts an enemy, the HP will decrease by 15. If HP reaches 0, the game is over. There are obstacles (white spheres) on the world. They are also stationary, and if the user sphere contacts an obstacle, the direction of the user sphere will be reflected.
Technology:	Since every object excluding the flag is a sphere, the collision detection is implemented based on the radius and the pos. of each sphere. The flag is inside a spherical bounding volume so that the collision detection between the user sphere and the flag is done in the same way. Every sphere has its center position above the center planet to make them float around the planet while it’s moving. Locating each sphere while it is moving is done by simply adding the sphere’s direction vector to the position, and scaling the magnitude of new position vector to the right distance from the center of the center sphere. Hence even after a sphere moves, it will be located at the same height relative to the center of the center sphere. The camera is set up in such a way that the user sphere is always located at the center of the screen. It’s up vector is always (0, 1, 0) in order to prevent sudden changes in the view in case of a sudden change in the direction of the user sphere.
Aesthetics:	In order to make the game look as if it is taking place in the space, The skybox has a sci-fi like image of the space, and so it fits the background of the game story. Also the center planet is texture-mapped with an image of Pluto, and we changed the alpha value so that the user can see what is on the opposite side of the planet through the planet because otherwise, the user’s view is limited to only one hemisphere. We placed a circular shadow underneath every sphere to emphasize the fact that it is floating above the planet, which corresponds to the enabled basic lighting of XNA. The user sphere is texture mapped with a checker-board image. It allows the user to better notice the increasing angular speed of the sphere when it’s spinning. There are 7 audio effects used in the game. A sound is played when the user sphere starts to spin, when an enemy is destroyed, when the user sphere gets hurt, when it hits an obstacle, when the user clears the stage, when the user clears all the stages or when the user loses.
Media
Screenshots:
(Optional) Download:
Development Summary
CODE:	There is Game class which contains the main loop of the game, where it updates and renders objects and handles the level flow. And there is the Ball class which contains a sphere’s position, radius and model. It provides update and render methods, acting as a superclass of the following classes: Player, NPC, Bullet and Obstacle. The Player class handles the user sphere. The NPC class handles a NPC enemy sphere, and is the superclass of NPCstanding1, NPCstanding2, NPCstanding3 and NPCmoving. NPCstanding1 handles an stationary enemy that shoots bullets in one direction. NPCstanding2 handles a stationary enemy that shoots bullets in a rotating direction. NPCstanding3 handles an enemy that always shoots bullets towards the user sphere. NPCmoving handles a moving enemy that chases after the user sphere. The Bullet class handles a bullet which has a position and a direction of a bullet. The Obstacle class handles a stationary obstacle. There is BallCollections class where most events are handled. It contains a list of all the spheres that are currently used in the game, including the user sphere, the enemies, the bullets, the obstacles, and the spherical bounding volume of the flag. Its update function checks collision detection between every pair of spheres and updates their locations. Also it has 5 lists of initial configurations of the world where each list contains the initial positions of the spheres and the flag in the level. The Camera class provides basic operations (turn left and turn right), and also a function that sets the camera directly above the user sphere with player’s position as the target vector. The Flag class contains the position and the model of the flag. Finally the Input class handles keyboard inputs. XNA was used for making this game. Input handling, and menu part of the code is based on and modified from Raphael’s SatSavior code (Thanks to Raphael!). No external libraries are included.
CONTENT:	All of the game models except the flag are spheres with different texture mappings. The images of a sci-fi space, Pluto and checkerboard were used to texture map the spheres, and the models were created using milkshape. The texture for the center sphere is from planetpixelemporium.com and the image used for the skybox is from mpan3.homeip.net. The checkerboard images are original. The level data which contains the positions of the spheres is also original. The seven sound effects used in the game are from the game Sonic 2.
Reflections
Three Greatest Challenges:	1. After deciding to set the camera always directly above the user sphere, it turned out that the sphere looked as if it was actually on the planet. When it was moving, the movement was awkward because the sphere did not roll. So we decided to place an approximated / fake shadow underneath every sphere to emphasize the floatation. 2. Initially, if the sphere changed the direction, the camera moved as well, i.e. the sphere would always move up relative to the view. However, this was problematic when there were sudden changes in the direction of the sphere due to collisions because the camera view would also instantly change, making it difficult for the player to keep track of the sphere’s direction. The solution we came up with is to set the up vector of the camera to (0,1,0) always, which actually solved the problem. 3. But it caused another problem as well. Before, the player knew the current direction of the sphere easily, which was just towards up, but after the change in the camera implementation, the user did not know about the direction anymore. So we decided to place a little white dot in front of the sphere indicating its direction. Setting the up vector to (0,1,0) still caused the camera view to change instantly when the sphere was at the north or the south pole of the planet. So we placed an obstacle at each place to prevent the user sphere to reach the pole.
Three things that went right:	1. The collision detection turned out to be quite successful. 2. Rendering the spheres around the planet at intended locations was successful so that combination of the collision detection and the movements of the spheres around the planet created good billiards-like sphere movements in a spherical world instead of a planar one. 3. Our implementation of camera and the little dot next to the user sphere allow smooth transitions of the camera view without hampering the information of the sphere’s direction.
Three things that went wrong:	1. We initially intended to create a lot of characters in two teams to make the game contain some aspects of real-time strategy. But balancing the AIs and implementing different tactics were too difficult, and our game ended up having the user control one character and some enemies with simple AIs. 2. Even with fewer characters, it was hard to create or find an animated model for each character. So we decided to use spheres as our characters. This caused the game to look even simpler. 3. Balancing the difficulties among different levels went wrong. In terms of difficulty, the gap between two consecutive levels is too wide.
Other final thoughts:	It was the first game for both of us, and we learned a lot about what is necessary in order to create a complete game. We believe that it would have been better if we prepared a solid blueprint of the game before we actually started coding. We only had a vague idea of what the game would look like. We actually created the game while we were coding, and the game turned out to be something we did not expect. And so it caused us to modify our plan quite frequently. We are very satisfied with the fact that our game does not look like any other game. Maybe this is another reason why we had to keep modifying our game. We are wondering what kind of game we could make if we decided to stick to some popular game genre, such as FPS or racing, and these are surely worth trying.