Category Archives: EAE:MGS

Week By Week Milestones

January 12, 2015 – January 16, 2015

The team arrived back from winter break.  I fixed a key camera issue by reversing the order of translation of the player and rotation of the camera.  Features were assigned to engineers.  Sam and I started working on a solution for the camera issue when the player moved from one rotation to another.

January 20, 2015 – January 23, 2015

Sam and I were able to provide an additional geometry that the player collides with fixing the camera rotation issue by smoothing the rotation angle.  Sam and I both investigated the controller input issue and Sam figured it out first.  I spent time floating around the team helping other engineers finish assigned tasks.

January 26, 2015 – January 30, 2015

I added ring removal to the game to provide a sense of time pressure.  Ring removal was a feature that was removed, but provided a framework for bringing tiles back when we decided to prevent islands from forming.  I helped fix a few features that had been added to the game including the slow mechanic and bombs.

February 2, 2015 – February 6, 2015

I began playing the game during class hours with production to figure out how to make the game better.  Delivery systems were mentioned by faculty, so I worked during the weekend to get light cycles, bombs and shooting in the game as a toggle-able option in the Unity editor.

February 9, 2015 – February 13, 2015

I continued playtesting with some crazy game variants.  We tried instant permanent removal of tiles with all three delivery systems.  The game appeared to lose depth when the claiming mechanic was missing.  I explored staying with bombs only making the game closer to Bomberman as per Ryan’s suggestion.  Bomberman is a great game and Hostile Territory could go that direction, but we decided shooting provided the best play experience for our tube level.

February 17, 2015 – February 20, 2015

I built a camera that allows free flying through the tube to allow trailers to be made for GDC.  I primarily bounced around the team to help finish features.

February 23, 2015 – February 27, 2015

The week was spent getting all the required features for GDC into the game.  Playtesting continued and so did making new builds as features were finished.

March 9, 2015 – March 13, 2015

We spent time playtesting and changing variables like speed, bomb charge time and how fast bullets move.  I found a bug preventing shooting.  The targeting system had to be moved slightly.

March 16, 2015 – March 20, 2015

Momentum across the team started to slow down since the GDC ambitions died down.  New art was being created for a turret character, but wouldn’t surface for a few weeks.  Build issues were primarily UI related.  Playtesting was still going strong and balance tweaks were still occurring.

March 23, 2015 – March 27, 2015

Camera was passionately discussed.  To aid action during the meeting I proposed that we try letting the camera go outside the tube.  Transparency would allow the player to see around themselves.  Rob and I spent some time working on getting transparency into the game.  The effect was popular.

March 30, 2015 – April 3, 2015

I fixed the center point for the camera with help from Rody and Rob.  Rob was able to finish the turret animation script.  I added shooting to the turret along the laser sight.  We fixed minor issues that arose from the turret.

April 6, 2015 – April 10, 2015

More balancing through playtesting occurred with the new turret and transparent tube.  The ideas were well received.  There was still talk about being able to shoot independent of view, but the game played well with the new camera.  I attempted to put together solutions for view independent shooting, but didn’t find something that worked well.

April 13, 2015 – April 17, 2015

I realized I had a major problem in game engineering.  I was behind to February assignments.  I spent time balancing and playtesting during class hours.  I spent the rest of my time working on game engineering homework.

April 20, 2015 – April 24, 2015

We finished balancing and packaging for EAE Fest.  I fixed any build related issues that existed and made sure the game was presentable.  I also helped add some last minute sounds to the game.  The result for the sound was not perfect, but it worked for presentation.  I was proud to see Owen bring in big speakers for EAE Fest.  My mind was primarily focused on finishing my game engineering work, so I was unable to devote more time to perfecting the sound.

April 27, 2015 – April 29, 2015

The primary entry here is EAE Fest.  Hostile Territory was well received.  The response surprised members of my team, but I blame all the playtesting with Rody for the state of the game by the end.  The art and sound were amazing.  The entire team pulled together well to put on a good show.  I was also able to finish my game engineering work.

Team Dynamics

The Hostile Territory team iterated very quickly after winter break.  I blame fewer restrictions on design and more acceptance of any contribution.  During the fall we had contributions being managed at the code level which meant that if the person reviewing code didn’t like the name of a variable time would be taken to change that variable or the structure put in place by some other engineer on the team.  As a result team members were constantly trying to relearn the code base which took time away from iteration.

The system we used after winter break was to have a continuous build process.  Code was reviewed for the build only if it prevented the game from functioning correctly.  I ran the build review process and made sure that everything worked so we could have a build ready on the next class day.  The process helped engineers focus on tasks assigned to them by Triston.  Each engineer also knew that they could contribute more to the project and it would be reviewed by the entire team as soon as the next build came out.

I would like to continue working toward finding strong solutions to build pipelines and engineer management.  The solution we found during spring semester worked well for our team size.  Sometimes experimental features were cut, but moral remained high.  Affording more freedom to contributions allowed shining experimental features like jump distortion to move forward.

Delivery Systems

The early delivery system for claiming territory in Hostile Territory was to shoot tiles.  From prototyping done in November 2014 other possible delivery systems were explored.  Some of the ideas were that you could roll bullets, drop bullets that explode or walk over tiles to claim them.  Starting in January the team continued exploring methods for the player to claim territory.

Turning environment tiles on and off was a key feature of the build for EAE day in December 2014.  After continued playtesting we cut turning tiles on and off for a permanent state of always off.  The reason was to drive the negative feedback loop of tiles disappearing faster speeding up gameplay.

A problem with permanence of tile removal is that there was the potential for islands to form in which neither player could reach the other.  I added a fix to combat the issue where tiles randomly returned on a fixed timer.  The fix is subtle, but appears to resolve any of the issue.

Removing tiles instantly was brought up.  The option still exist in the game for fast players which means we need to explore not having a claim state further.  The slowing mechanic proposed by Allen and Rody has helped give meaning to keeping tiles in the game, but it might make sense to immediately remove.

Abysmal Camera

The camera for Hostile Territory has been a sticking point for the game.  After returning from GDC I spent a lot of time working on the camera with other team members.  There were a lot of ideas on how the camera should function.  A primary issue was zooming in when occlusions occurred such that the character filled most of the view provided by the camera.  Being in a cylindrical environment without a definitive up direction creates interesting camera problems.

Possible solutions were:

  1. The camera could drive itself.  The player would move relative to the camera facing direction.  The primary problem with this method is figuring out where the player shoots.  An outcome of this method is that the player can shoot a target that they are not looking at however shooting accuracy would need improved to make that outcome meaningful.
  2. The camera could be fixed from the center looking at the player.  The outcome is a more isometric camera making the curved space flatter and potentially providing more strategic gameplay if shooting were revised to be bombs only or something similar.  Shooting is not a good fit for this camera option.  Level design is constrained to surfaces with a defined pivot point.
  3. The camera could always be at a fixed distance and the environment can become transparent.  Conversations about camera seemed to be focused against zooming functionality, so removing zoom seemed to be a simple option.  The problem of the tube obscuring the view was removed by applying transparency to the back faces of the tiles making up the tube.

We chose to implement option 3 quickly to see if that resolved concerns.  The result was decent.  There were still desires to shoot in a direction not faced by the camera.  There may be a good way to get that to work.  I tried forcing each player to look at each other so the view was constrained to one dimension, but that was disorienting since both camera views moved whenever either player moved.

The result turned out decent.  There was not much talk of the camera at EAE Fest.  The transparent backgrounds allowed three dimensional shooting.  With the constraint of shooting, transparent tiles were a worthwhile solution to an issue that had plagued the project since August 2014.

EAE Fest Success

EAE day was yesterday.  I enjoyed being part of EAE day and showing off Hostile Territory.  Hostile Territory has had an interesting journey since I joined the team in August 2014.  The journey is marked with iteration focused around the core idea of indirectly attacking the opponent.

The current entry will focus on the end of spring 2015 development for Hostile Territory.  I am going to be working backward in a reflective manner with subsequent entries.  I am looking to build the Hostile Territory story from August 2014 to spring 2015.

The last two weeks have passed quickly.  I have been exploring networking as a feature for the game.  I was able to get a server/client system with lobby running toward the beginning of exploration, but finding the data that needs transmitted proved to be difficult.  Building networking after a game has seen active development for nine months is a daunting challenge.  Networking for Hostile Territory is not a two week task, but is a possibility for the future of Hostile Territory.

I was unable to devote large amounts of time to development during the past two weeks.  I was behind in game engineering and devoted all my time outside of class to game engineering.  I was able to go from finishing work due in February to completing the most recent assignment in a little over two weeks.  I regret not staying current in game engineering, but I learned a lot by attending every class and getting the work done.  I doubted I could get caught up, but I kept my nose to the grindstone and resolved to finish the work.

EAE Fest was yesterday.  I was able to show off Hostile Territory to many people.  Hostile Territory was well equipped for EAE Fest being a fast multi-player game.  I was most surprised by my teams reaction to players reactions.  Players were having fun with our game and that surprised some of my teammates.  I was happy to see that design efforts to playtest everything have paid off.

The design process going into the spring semester has been to constantly play the game making tweaks and trying them.  There were tweaks I was unable to put together, but for the most part if there was an idea I tried to build it as quickly as I could so we could continue playing the game.  The approach was not only agile, but also facilitated continuous integration of new ideas and polishing of old ideas.  Continuous integration tools are becoming more common in the software industry.  For a small team a software package is probably too much, but being able to sit together, play the game and make changes within minutes accomplishes continually integrating new ideas from anywhere and anyone on the team.

There have been murmurings of continuing Hostile Territory development as a side project.  I know that there is something interesting and fun in Hostile Territory.  I still believe Hostile Territory, the game and team, have mountains of potential.  I will continue to develop Hostile Territory when able.

Game Engineering 3 Assignment 1


Camera Movement:  Arrow Keys and Insert and Delete

Camera Rotation:  I, J, K, L, U and M.


The scope of assignment 1 was to load a scene from Maya and get a fly camera into the game.


My aim for the first assignment was to update my game controllers, load the scene from Maya and get a fly camera.


I overhauled my actor class to use the new key value pair system that is part of my scene file.  As a result actors now have controllers which are registered with the world system and perform specific operations on that in game actor.  Classes of controllers actors have include information, input, movement and rendering.

Implementing the fly camera involved creating a controller called GetBasis.  The controller uses the camera rotation to find the forward, right and up vectors for the camera.  The controller updates information on the camera actor which is passed to input and movement controllers.

The Maya Exporter needed updating in order to export a scene from Maya.  I updated the Maya Exporter to export each mesh as a single mesh.  I obtained the mesh and material information in code and saved that data to a scene file.  My asset build list was updated using the Reloader tool I built last semester.  There were 1120 meshes in the scene, so entering that information by hand would have been silly.

The new scene exported using Maya and imported using the my engine's scene system.The new scene exported using Maya and imported using the my engine’s scene system.

Time Estimate

The workload was hefty.  I expect that the extra effort I am putting in now will save time later in the semester.  The game and engine split is feeling much better in the current iteration.

Activity Time Spent Estimate
Implementing actor key value pair and controller system 15 hours
Updating Maya Exporter to export single meshes and scene data 8 hours
Adding the fly camera controllers 3 hours
Write up 1 hour
Total 27 hours

Game Engineering 2 Assignment 09


Everything minus camera and floor: W – Positive Z; S – Negative Z; A – Negative X; D – Positive X; Q – Positive Y; Z – Negative Y; R – Rotate in Positive X; H – Rotate in Positive Y; T – Rotate in Positive Z; V – Rotate in Negative X; F – Rotate In Negative Y; G – Rotate in Negative Z

Camera:  I – Positive Y; K – Negative Y; J – Negative X; L – Positive X; U – Positive Z; M – Negative Z; Insert – Rotate in Positive X; Delete – Rotate in Negative X; Right Arrow – Rotate in Positive Y; Left Arrow – Rotate in Negative Y; Up Arrow – Rotate in Positive Z; Down Arrow – Rotate in Negative Z


The project has been updated with a new Maya Exporter. The exporter allows meshes to be built into the format I use to import meshes into the game. The project now has a scene which allows me to make multiple actors with the same material and/or mesh. I can also change controls, orientation and movement speed. The project now has a settings file that allows changing height, width and full screen mode. The project now has PIX debugging information.


The aim of the ninth assignment was to get multiple meshes into the game from a complex program like Maya.


A mesh I used in the game was sphere.mesh.lua. The file format with the mesh.lua isn’t working properly, so please specify the entire file name including extension.

The build that is downloadable is a debug build. The release build is pretending that 0 = -1231253242 which is out of range. I will need to fix the release build before next assignment. It was running in Release until I started playing with full screen mode.

I started by building the scene file. I had a strong interest in the file since last time. I wanted to be able to load meshes and materials on anything. I am now able to do so, but that implementation ate a lot of time. Hopefully the investment now pays off in the end.

An example scene file is:

***Modified from text to picture for clarity 11/19/2014***


***End of modification from text to picture for clarity***

Ultimately the file needs an editor for non-programmers. I haven’t built one yet. I will look into building one in the future.

Here is a screenshot of the game with four meshes and multiple textures:


Here is a screenshot of PIX information showing new events (Set Material and Draw Mesh):



I ended up behind due to iterating for projects. I was able to meet my goals. I am still having issues with release mode, but I have no time to solve the issues.

***Added section with screenshots regarding the issue 11/19/2014***

The call that fails is sent with a value of 0:


The failure in the call is shown here:


***End of section with screenshots****

Time Estimate

The workload with scene files and everything else was around 16 hours.

Activity Time Spent
Scene File 10 hours
Maya Exporter 3 hours
Full Screen 2 hours
Write up 1 hour
Total 16 hours

Game Engineering 2 Assignment 04


W – Up; S – Down; A – Left; D – Right


The project has been updated to use constant tables to allow changing color of a mesh.  Constant tables were used to move a mesh around the screen.  The build asset pipeline was edited to allow for multiple builders for assets.


The aim of the fourth assignment was to introduce constant tables, incorporate code from previous engineering classes and modify the build pipeline to allow more than one builder for assets.


I put together a system for using constants within rendering under the instruction of John-Paul.  Constants are values passed into a shader that modify the output of said shader.  The two cases that constants were used were per material and per instance.  The specific per material case is a color shift to the mesh and are set every time a different material is applied to the mesh during the fragment shader step in the rendering pipeline.  The specific per instance case is a translation of the mesh based on screen coordinates during the vertex shader step in the rendering pipeline.

I added to the material file format from assignment 03.  I wanted to ensure there was room to grow with per material and per instance variables being separate.  I also wanted to maintain a human readable format.  The format I built was:

Shaders = {
Vertex = “data/vertexShader.hlsl”,
Fragment = “data/fragmentShader.hlsl”,
Constants = {
PerMaterial =
ColorModifier =
Red = 1.0,
Green = 1.0,
Blue = 1.0,

The values in ColorModifier are the real numbers between 0 and 1.  The reason for tables within tables was to ensure room to grow as more constants are added.  I am unsure how meshes will be added.  I assume meshes will have their own file format.  Therefore the values in the file are specific to materials.  By providing room for the file to grow I intend to save time as the file grows.  Further readability helps myself and others that use my files.

Screen Shots

I generated two screenshots of the project at this point.  The first screenshot uses RGB values of (1,1,0) and is yellow.  The second uses RGB values of (1,0.5,0.5) and is pink.  The first screenshot is in the default location.  The second has been displaced using the keyboard.  The displacement and coloring is done through constant tables provided to the shader.

Yellow rectangle in the default position with RGB values of (1,1,0).
Yellow rectangle in the default position with RGB values of (1,1,0).
Pink rectangle with RGB values of (1,0.5,0.5) and a displaced position all done through constant tables applied to the shaders associated with drawing the rectangle.
Pink rectangle with RGB values of (1,0.5,0.5) and a displaced position all done through constant tables applied to the shaders associated with drawing the rectangle.


I added code for actors, memory management, mathematics, data structures, controllers, script handlers for file IO and timers.  Adding code from prior engineering classes was a lengthy process.  I spent time working on namespaces within Engine.  There is still work to be done.

I added memory leak detection.  I found a number of memory leaks that I hadn’t discovered last year in my old code.  I will continue looking for memory leaks.

My controllers ended up working great.  I need to find a better way to handle input.  I am iterating over all keys to fill an array of bits.  I would like to be able to pull individual keys.

I added a single actor to my World in Engine.  I need a way to handle multiple actors.  I am excited to bring in old code, but there is an associated maintenance cost in time.

I will be making a distinct Mesh class for handling mesh related data.  Currently both are under the umbrella of Materials.  I will be revisting my Materials class to remove anything not related to materials.  Vertex information is likely unrelated to materials and probably needed in a mesh class.

My asset builders need attention.  I did little architecture work on the build tools.  BuilderHelper and GenericBuilder in particular need attention to at least be classes.


Updating my old code was time consuming.  I have spent more time on this homework than prior homework assignments excluding homework 1.  Game and Engine are currently not specific enough.  World is taking on more responsibility than it should. I didn’t have time to address that issue.

The eae6320 namespace still exist in my code.  I am going to be cleaning it up since it is ugly.  I spent too much time on old code and getting stuff fixed for submission to worry about it.

Next Steps

Implement the mesh class!  Fix input!  Obtain a better separation between game and engine.

Time Estimate

The workload for the project was heavy due to maintaining old code.  Overall the project shouldn’t have been too bad.  I suspect the time I spent on this assignment will be valuable to the future of the project however.

Activity Time Spent
Adding Constant Tables 3 hours
Implementing old code 5 hours
Adding New Build System 4 hours
Write up 1 hour
Total 13 hours

Showing Off Wall Walking

My team showed off Hostile Territory to Bob, Jose and Ryan. The feedback was great and has made our team discuss the game we are making. There is general excitement about wall walking.

I am working on the execution of wall walking. I am building a system with Ron Romero where the camera and controls can completely change. I am making wall walking part of that system.

I am trying not to influence design decisions too much. I am trying to keep myself to a role of being a decent engineer. I need to be a better team player when I am not the designer on a project. That means providing insight when it is needed and backing off otherwise.

Rotations and Wall Walking

I had decided today would be a good day to unravel the spaghetti surrounding the player controller in Hostile Territory’s source code. It turns out I wasn’t very interested in getting that fixed yet. Instead I spent my time figuring out the math to prevent the player from feeling like their rotations has changed when they move onto another surface wall walking.

In layman’s terms our shooter now has surface walking. That means the player could be on any surface in the game. If I were directing design, which I am not, I would allow the player to spin while in the air changing their gravity.

Overall the engineering for wall walking has been an amazing experience. I was not on the team from the beginning, but I watched the team get asked if people can run up the walls. Now they can.