Simon Gayton

Programmer

Group Projects

Gravitation
	My fourth year project is still currently in development. The game takes place in a futuristic mine, where you are able to change gravity in order to walk on the ceiling and walls. It is a single player, first person shooter game, that focuses on changing the orientation of gravity. Players must defeat all the enemies and find hidden coins to move on to the next level. Players can choose from a simple laser weapon or a bomb that does more damage but may more difficult to aim depending on the current orientation of gravity. I worked as a programmer/tech director on a team with five members for the first half of the project, and just three for the second half of the project. My responsibilities included writing the network code, the graphics engine, and the design of one of the levels. The game was originally designed as a LAN based multiplayer game. I wrote a network module for the game that used the WinSock API and UDP protocol. I coded the network module using a layered design that provided both standard, unreliable UDP and reliable UDP. The game could run well using unreliable UDP, though the game design changed before the unreliable UDP could be finished. At this point, my focus moved to writing the graphics engine. Until this point the graphics engine has been simply drawing a list of meshes using DirectX's fixed function pipeline and basic texturing. My goal was to create improved lighting and visual effects for weapons and gravity based events. All rendering is now done through a set of HLSL shaders. The lighting now uses simple directional lights. The bomb weapon also uses a glow effect to make it look like it is going to blow up. I also wrote a simple particle system manager to create the effect of objects blowing up and also to represent the player changing the orientation of gravity. Copyright 2006 (C) DigiPen (USA) Corporation

Gravitation

My fourth year project is still currently in development. The game takes place in a futuristic mine, where you are able to change gravity in order to walk on the ceiling and walls. It is a single player, first person shooter game, that focuses on changing the orientation of gravity. Players must defeat all the enemies and find hidden coins to move on to the next level. Players can choose from a simple laser weapon or a bomb that does more damage but may more difficult to aim depending on the current orientation of gravity.

I worked as a programmer/tech director on a team with five members for the first half of the project, and just three for the second half of the project. My responsibilities included writing the network code, the graphics engine, and the design of one of the levels. The game was originally designed as a LAN based multiplayer game. I wrote a network module for the game that used the WinSock API and UDP protocol. I coded the network module using a layered design that provided both standard, unreliable UDP and reliable UDP. The game could run well using unreliable UDP, though the game design changed before the unreliable UDP could be finished. At this point, my focus moved to writing the graphics engine. Until this point the graphics engine has been simply drawing a list of meshes using DirectX's fixed function pipeline and basic texturing. My goal was to create improved lighting and visual effects for weapons and gravity based events. All rendering is now done through a set of HLSL shaders. The lighting now uses simple directional lights. The bomb weapon also uses a glow effect to make it look like it is going to blow up. I also wrote a simple particle system manager to create the effect of objects blowing up and also to represent the player changing the orientation of gravity.

Pingo
	In my third year project, you are sphere on a 3D planet. This planet is inhabited by creatures called Pingos. The goal of the game is to try and rescue the Pingos by leading them to your goal flag. You can lead the Pingos by having them follow a trail of colored paint that you leave behind as you roll. There are creatures who like to eat Pingos and in a multiplayer game you are competing with others to rescue more Pingos. I worked as a programmer/producer on a four person team. My responsibilities included writing a 3D physics engine and 3D camera control code. The world in Pingo is a sphere with six height maps applied to it to create rolling hills and lakes. The world is populated only by sphere shaped objects from the physics engine's point of view. This was one of my first experiences working with the problems of stacking objects. The player can jump on top of a group of enemies or charge through them like pool balls. In the first version of my physics engine, I treated object overlap as an event that needed to be prevented at all cost. This only lead to the entire simulation looking as though it would get stuck. The second and final version of my physics engine treated object overlap as an event that would correct itself in time. The allowed all the objects to collide nicely and gave a good smooth feel when playing. The camera model for Pingo is similar to that in many third person action/adventure games. The camera follows the player but is not locked in the direction the player is facing because in Pingo, the players have no direction that they are facing. The best description of how the camera model works is that the player is dragging a long pole behind them with the camera attached to the end of the pole. I implemented this idea by moving the camera to a fixed distance from the player based on its current position. The height of the camera over the ground is simply adjusted by the player to provide the effect of looking up and down. Copyright 2005 (C) DigiPen (USA) Corporation

Pingo

In my third year project, you are sphere on a 3D planet. This planet is inhabited by creatures called Pingos. The goal of the game is to try and rescue the Pingos by leading them to your goal flag. You can lead the Pingos by having them follow a trail of colored paint that you leave behind as you roll. There are creatures who like to eat Pingos and in a multiplayer game you are competing with others to rescue more Pingos.

I worked as a programmer/producer on a four person team. My responsibilities included writing a 3D physics engine and 3D camera control code. The world in Pingo is a sphere with six height maps applied to it to create rolling hills and lakes. The world is populated only by sphere shaped objects from the physics engine's point of view. This was one of my first experiences working with the problems of stacking objects. The player can jump on top of a group of enemies or charge through them like pool balls. In the first version of my physics engine, I treated object overlap as an event that needed to be prevented at all cost. This only lead to the entire simulation looking as though it would get stuck. The second and final version of my physics engine treated object overlap as an event that would correct itself in time. The allowed all the objects to collide nicely and gave a good smooth feel when playing. The camera model for Pingo is similar to that in many third person action/adventure games. The camera follows the player but is not locked in the direction the player is facing because in Pingo, the players have no direction that they are facing. The best description of how the camera model works is that the player is dragging a long pole behind them with the camera attached to the end of the pole. I implemented this idea by moving the camera to a fixed distance from the player based on its current position. The height of the camera over the ground is simply adjusted by the player to provide the effect of looking up and down.

TCubed
	For my second year project, my group decided to create a game that was inspired by both Nintendo's Metroid series and the Disney movie Tron. In the beginning of the game, you find yourself inside a large computer system and must defeat your enemies to escape. The first level has no enemies and is designed to allow for exploration. As the player progresses, he is confronted with components of the system that have become corrupted. He must fight to escape, from a world where bits and bytes have come alive. I worked as a programmer/tech director on a four person team. My responsibilities included creating our level editor, defining data structures to describe internal game data, and implementing the game's physics. The level editor was a simple Windows application that allows the user to edit a tile map of arbitrary size and with an arbitrary number of layers that use parallax scrolling to create a sense of depth. The maps use a palette of tiles, one for each sector of the game. The association between a tile in the map and it's palette entry used an extra look up table that provided the ability to easily animate the tiles in the map. The game world was split into five sectors, each with around ten rooms each. Each room took up about three or four screens of play area. This was represented through data structures for a world, sector and room. These were nested so that the world contained sectors which contained rooms. This allowed us to load just the room that the player is in to keep memory use to a minimum. The sector level of the structure allowed us to load sector wide resources just once when switching sectors. The physics of the game provided quite a challenge for our team. We allowed nearly every object in the environment to interact with all the other objects. In a given room there could be the player, the player's disk weapon, enemies, moving platforms, doors, switches, and enemy projectiles. Copyright 2004 (C) DigiPen (USA) Corporation

TCubed

For my second year project, my group decided to create a game that was inspired by both Nintendo's Metroid series and the Disney movie Tron. In the beginning of the game, you find yourself inside a large computer system and must defeat your enemies to escape. The first level has no enemies and is designed to allow for exploration. As the player progresses, he is confronted with components of the system that have become corrupted. He must fight to escape, from a world where bits and bytes have come alive.

I worked as a programmer/tech director on a four person team. My responsibilities included creating our level editor, defining data structures to describe internal game data, and implementing the game's physics. The level editor was a simple Windows application that allows the user to edit a tile map of arbitrary size and with an arbitrary number of layers that use parallax scrolling to create a sense of depth. The maps use a palette of tiles, one for each sector of the game. The association between a tile in the map and it's palette entry used an extra look up table that provided the ability to easily animate the tiles in the map. The game world was split into five sectors, each with around ten rooms each. Each room took up about three or four screens of play area. This was represented through data structures for a world, sector and room. These were nested so that the world contained sectors which contained rooms. This allowed us to load just the room that the player is in to keep memory use to a minimum. The sector level of the structure allowed us to load sector wide resources just once when switching sectors. The physics of the game provided quite a challenge for our team. We allowed nearly every object in the environment to interact with all the other objects. In a given room there could be the player, the player's disk weapon, enemies, moving platforms, doors, switches, and enemy projectiles.

Scat Attack
	My first year project, is a puzzle game that will challange your mind and speed. You find yourself in a basement with a sewer line directly above you. You can see disgusting green waste filling pipes which are heading straight for you. You only have a few seconds before the contents erupt from the pipe and fill the room. Your challenge is to add new pipes to the line, in order to connect to the drain at the other end of the room. You find that some of the pipes split the flow into multiple directions, creating a complicated network. Try to see if you can stay ahead of the flow. I worked as a programmer/designer on a four person team. My responsibilities included programming the tile-based fluid flow through the pipes and detecting wining or loosing conditions. The program was written to run in a Windows console window using the console API to manage the window and display graphics. I implemented the fluid representation by creating a linked list of flow points that were considered actively flowing. The code had to handle cases when the fluid divided or merged. The code also had to handle pipe configurations which, when represented as a tile grid appear to be closed, though were clearly not joined pipes. The speed of the flow had to be dynamic to account for each time the fluid followed multiple paths. Each time the path divided the fluid had to slow and each time it merged the fluid speed increased. Copyright 2003 (C) DigiPen (USA) Corporation

Scat Attack

My first year project, is a puzzle game that will challange your mind and speed. You find yourself in a basement with a sewer line directly above you. You can see disgusting green waste filling pipes which are heading straight for you. You only have a few seconds before the contents erupt from the pipe and fill the room. Your challenge is to add new pipes to the line, in order to connect to the drain at the other end of the room. You find that some of the pipes split the flow into multiple directions, creating a complicated network. Try to see if you can stay ahead of the flow.

I worked as a programmer/designer on a four person team. My responsibilities included programming the tile-based fluid flow through the pipes and detecting wining or loosing conditions. The program was written to run in a Windows console window using the console API to manage the window and display graphics. I implemented the fluid representation by creating a linked list of flow points that were considered actively flowing. The code had to handle cases when the fluid divided or merged. The code also had to handle pipe configurations which, when represented as a tile grid appear to be closed, though were clearly not joined pipes. The speed of the flow had to be dynamic to account for each time the fluid followed multiple paths. Each time the path divided the fluid had to slow and each time it merged the fluid speed increased.