Date: September 30, 2014

This update might be a little flimsy, but some exciting things happened.

Systems Failing

First of all, we brought our game to QA testing for the first time. Things were going very well, people were very intrigued by our little toy. Like in the video I posted last week, we gave them a plethora of block-made structures and they felt incredible satisfaction punching through them with the spheres.

The computers, on the other hand, were not having as much fun. Running on 4 out of 5 computers on a single pod, the processing of the physics overloaded the computers until <insert intelligent electrical knowledge here> failed and the small collection of computers were without power for 3 days... Oops. Not very many games can make this sort of claim, however. Other than it meaning that our game will require some fairly high end computers, I consider this a badge of honor.

Fixing Failures

We now have two veins that we have decided to explore for fixing this issue. As a systems designer, I set out to design enemy behaviors and player controls to shift the focus from the ball manipulation towards combat with adversaries. Theoretically, the removal of some of our mechanics from Code Mushroom's original systems would allow us to increase our frame rate dramatically. While control of the orbs will be maintained, they won't be 'animated' with physics and each would be treated as a more projectile-like entity. Also, we wanted to explore player movement and are testing a side-dash mechanic for avoidance. We will see how the class reacts to these changes. However, since we removed the physics kludge from this one, I don't expect a great reception. Because we are removing features of the original project, also called Four, we are calling this iteration Too. (Typo intended)

Simultaneously, Adam, our environment artist, is making a rudimentary test level with our current mechanics to allow for more focused testing of controls, situations and mechanics. In addition, we are continuing to iterate on things like a variety in attributes. For instance, we currently have a working prototype for a sort of 'sticky' object that can be attached to objects to push and pull them away. 

It worked out fairly well, but he went out of his way to implement some puzzles that revolved around some physics based kinks in our sphere controls (kinks we have come to describe as 'Advanced Techniques'). This made it hard to actually complete and the lay out made people assume our game would take place in a test facility. It was kind of annoying, as we emphasized that this area was for testing the mechanics and had no bearing on the artistic vision, but that's testing for you.