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.

GDC and Beyond

I am now back from GDC.  I have a quiz in my data mining course in a few hours.  I am recuperating from a cold I caught during the week of GDC.  I will detail GDC week and then my plans moving forward with the rest of the semester.

GDC week was entertaining.  My wife and I left for San Francisco early Sunday.  We walked to the bridge and to fisherman’s wharf.  It was nice to spend some time together.

Monday I attended the math tutorials.  My favorite math tutorial was the homogeneous coordinate lecture by Squirrel Eiserloh.  I feel like the W coordinate was not explained well enough in the graphics lectures.  Having worked in projected space with elliptic curves I had a rough understanding of the space occupied by (X, Y, Z, W) in R^3.  Squirrel’s lecture justified that homogeneous coordinates create a projected space.

Tuesday I attended the physics tutorials.  My favorite physics tutorial was “Physics Optimization Strategies” by Sergiy Migdalskiy.  The tutorial addressed cache misses as a large loss of performance in game physics.  Suggestions to fix the issue were data packing, specialized pointers and generalizations for taking advantage of parallelism.  I noticed business people in the room and watched their eyes glaze over when assembly code was presented.  That made me smile.  He also had animations to help break the concept down for non-technical people.  Some people were only there because they thought Half-Life 3 might be announced due to a coincidence of being at 3 PM on March 3….

On Wednesday I helped Topher with Hostile Territory at the EAE booth from 10:00 AM to Noon.   We met some interesting people.   There was more interest in Hostile Territory when it was moving, so I was messing around in the game.  My messing around however caused me to miss talking to someone that was standing behind me.  Corrinne told me I was bad at this and shouldn’t be playing my game, so I stopped.  Interest waned.  Topher came back and we pretended to play and interest rose again.  Overall the experience wasn’t terrible and we met some people.

Also on Wednesday I explored the expo floor and found it similar to last years expo floor.  I went to the career area.  That area seemed the same which means I am likely crazy expecting different results from the expo floor and career area.  I left the area and attended Microsoft talks for the rest of the day.

The rest of the week was largely uneventful.  I had caught a cold and was coughing frequently.  I went to the Intel event.  It was great to see 404sight compete.  I was also impressed by the diversity of the winners from the Intel event.  Otherwise I avoided most contact with the conference since I didn’t want to spread the cold.  The sessions I could have went to were sponsored events and if I were at the conference I would have spent more time with Microsoft.  I did meet David Setser at one of the Microsoft events.  He is an alum of the EAE program that is working at Microsoft.

Moving forward I am going to take my quiz today in data mining.  I am then going to devote all my time to catching up in game engineering.  Unfortunately I have ended up behind in game engineering.  With GDC behind me I have more time to spend with game engineering.  I am looking forward to working hard to finish my studies over the next two months.

One week left in the GDC count down

Hostile Territory has been progressing well.  Iteration time is quick.  The team is working well together.  The engineers have consistently delivered new features.  The team has also been working closer with faculty for thoughts on how to best improve Hostile Territory.

I have been working closely with Rody, Allen and Topher from production to find the fun in Hostile Territory.  I built bomb and light cycle mechanics when Ryan and Jose mentioned them to the team.  Bombs explode after a timer elapses and take an area around them.    I also helped finish a speed up and slow down mechanic that Triston started work on.

The team was supposed to decide on the best delivery method.  Rody, Allen, Topher and myself spent a lot of time changing the mechanic to determine which one was most fun.  Among our trials were a light cycle mode that removed tiles instead of coloring them, shooting that removed tiles instead of coloring, bombs that removed instead of coloring, turning colored tiles on and off, removing colored tiles permanently and mixing and matching delivery methods.  Showcasing the build with everything and coloring to Ryan and Jose garnered the response that we should keep everything.  We proceeded.  Last week Ryan mentioned that we should focus on one delivery method.  The team is unsure which method to keep.  I think Rody has been leaning toward keeping all the delivery methods.

I worked with Peijun on getting rounds implemented.  Rounds restart the game anytime a player dies.  On player death the other player gains a point.  If either player hits three points then the game was supposed to end.  There were issues with some of the other code, so George has been looking into fixing the issue.  Whether the issue is fixed remains unknown due to build issues.

I built a camera for making trailers.  The camera currently prevents movement of the players when active.  Rody mentioned we probably want the camera to allow player movement, so I am working on building a camera to fix the issue.

I have been bouncing around the team working to support engineers that need assistance.  I have also been responsible for the build.  If the build is broken I spend time tracking down the issue.  If I can’t solve the issue I contact the person that made the offending commit to work together to solve the issue.

Working up to GDC I am trying to get my work done for Hostile Territory in addition to game engineering and data mining class.  I have also been trying to maintain my work-life balance.  I am excited for GDC and graduation.  I am grateful for all the progress made on Hostile Territory over the last two months.

Game Projects 3 First Quarter in Review

Hostile Territory development has been going well.  I have assumed more responsibility on the team.  I am now responsible for creating builds for production to play.  That means I ensure that the build works and that the behavior of all the systems is working enough to be reviewed.  I am also an engineering voice on the design team.

The entire team has been prototyping for our final design which has been amazing.  The team will be making the cut for design Thursday.  I am unsure how the team wants to go about making the cut, but I am going to prepare some possible cohesive designs to help prevent unfounded team arguments.

There have been advancements in the engineering behind the game since the start of the semester.  Saumya and myself were able to fix camera jitters.  Saumya was able to find the source of controllers not providing input.  Shelwin and Sty have been adding interesting shaders that make the game look better and an orb that chases players, claims tiles and explodes after a duration.  Triston has been managing the group and ensuring people have work to do.  Peijun and George added bombs, which needed touching up, but are currently working well.

I have been floating on the team with regard to tasks.  Generally during the class hours when everyone is here I help others do their work.  My first major individual contribution to the project for the semester was to fix the camera backward movement jumping issue.  Afterward I added ring removal as per Rody’s request.  The feature has since been cut do to not supporting a meaningful design.  I fixed the bomb and a speed up/slow down mechanic that were added by others, but weren’t quite working.  I also added light cycle mode to the game.

The team is trimming the design on February 6th.  I have a bad feeling about how the meeting related to trimming will go.  The team lacks a common vision for the game which means the design suffers.  During the last month the team has had amazing contributions from engineers due to removing the constraints that existed design wise last semester.  Now constraints are coming back.

I am going to try to get the team excited about the return of constraints.  I want to keep the team working well together.  There are talented engineers on our team.  I would hate to see their moral broken by a design dictator.  The goal for the team design wise is to prune features that don’t fit a frenetic arcade game.

Game Engineering 3 Assignment 1

Controls

Camera Movement:  Arrow Keys and Insert and Delete

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

Abstract

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

Aims

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

Implementation

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 13

Controls

Left and right arrow keys move left and right. Forward arrow starts the car moving. Back stops the car.

The ‘1’ key toggles debug. Press it quickly to see Christmas lights! Create your own light show!

"Almost Christmas" is a game about final projects, tedium and long nights.  The game has a Christmas theme and is a tunnel where players can't reach the end, but they can enjoy the light show by pressing the '1' key rhythmically.  In the end it is "Almost Christmas".
“Almost Christmas” is a game about final projects, tedium and long nights. In the end it is “Almost Christmas”.

Abstract

The scope of assignment 13 was a to make a game with the engine. The game I built is called “Almost Christmas”. “Almost Christmas” is a game about not being able to reach Christmas break. The experience is meant to inspire tedium in the player. The player is presented with an artificial choice of left and right. Moving forward moves the player closer to christmas, but before the player reaches Christmas they are warped back to the beginning. Here’s a picture of the game

Aims

My aim for the assignment was to built a more automatic asset process. I also wanted to update my scene file format. Both goals were met. The game was supposed to be an AI racing game where the player and an AI opponent navigate a grid and whoever reaches the goal first wins. With the asset and scene modifications I wanted to make the scope of the game was too large. I decided to make a game about my current emotional state. I long for Christmas. Capturing that in a game led to “Almost Christmas”, a game about the tedium of trying to reach Christmas break and getting set back.

Implementation

The bulk of my implementation time was spent on making the reloader. The reloader is a process that runs in the background and monitors the assets folder. When a change is made to the assets folder the asset that changed is determined. That asset is added to a list which is piped into the asset pipeline. The asset build process is ran and builds the edited assets. Here are examples:

The Reloader is loaded.  I have not made any modifications to files yet.
The Reloader is loaded. I have not made any modifications to files yet.
The Reloader is up and I have made edits to a scene, mesh, material, shader and texture file.  There are even errors that are being printed due to copying and pasting a fragment shader and then renaming it to be a vertex shader.  The not found error is due to the Reloader copying the copy file from Windows into AssetsToBuild.  Definitely some kinks in the reloader, but I do not need to touch AssetsToBuild very frequently.
The Reloader is up and I have made edits to a scene, mesh, material, shader and texture file. There are even errors that are being printed due to copying and pasting a fragment shader and then renaming it to be a vertex shader. The not found error is due to the Reloader copying the copy file from Windows into AssetsToBuild. Definitely some kinks in the reloader, but I do not need to touch AssetsToBuild very frequently.

The 2D UI element is the level. If another scene were made that scene would have the number 1 on it. I initially planned to have multiple racing maps, but had to make some concessions.

Overall, the asset builder has been the best tool from the class. I have been excited to expand the capabilities. My Reloader reduces the number of times I have to manually edit AssetsToBuild and execute AssetBuilder. Paired with a scene system that uses key value pairs and controllers I do not need to touch actual source code as frequently as I otherwise would allowing my engine to be more generic.

Issues

I ran into time constraints which required me to reduce the scope of my game. Building better tools took most of the time allotted for the assignment. I am happy with my choice to build better tools. I am going to continue to extend my tools, but tool development takes a lot of time.

I would like to thank JP for explaining asset build processes. I am going to refine the process since it saves time. Sophisticated tools take time to build, but save time if used with enough frequency.

Time Estimate

The workload for the project was about 50 hours plus or minus 15. I spent a lot of time on tools. The game was maybe a 4 hour endeavor after building tools.  I am tired.  I am going to sleep and enjoy Christmas.

Activity Time Spent
Reloader Tool 20 hours
Editting Scene Format 20 hours
Scoping the Game and Freaking Out 4 hours
Building the Game 4 hours
Write up 2 hour
Total 50 hours