1.31.13 - A Fury Void Update

Team Fury is now starting to wrap-up the software additions to Fury Void.  Final features are being implemented, with the three main points of interest being: enemies with AIs; Xbox controller support; and saving.  However, there has been much done in the past few weeks, and those bring Fury Void closer to completion in a very fast way.

Firstly, an energy system has been added to the game to allow for a stricter balancing of what the player can do at any one time.  ‘Energy Balls’ now serve to replenish spent energy if the refresh rate is not adequate enough.  With the new energy system, weapons now have a cost to fire, while the feature leaves open the possibility of abilities such as speed-boosts and shielding.

Since the energy system has been implemented, Team Fury now has a member nearly completely dedicated to finding a balance of weapons.   Damage, firing speed, and energy consumption are all taken into account.  The weapon systems are still undergoing changes daily, but it should be settled upon an increase of QA testing.

In regards to balancing the weapon system of the game, Team Fury has gone in and redone the laser weapon for the player.  Previously, code would only occasionally allow for an object to be harmed by the laser beam.  Now, damage is incurred by the objects the laser effect produces all of the time.

Other changes to weapons include the auto-firing of the in-game flak gun.  It now shoots a stream of bullets, making it so that, when it was first implemented, convinced the entirety of Team Fury to use the ‘bullet hose’ exclusively.  The same code will be implemented with the laser beam, and may alter the missile scripts at a later date, but this new feature now requires extensive balancing.

Lastly, weapons no longer damage the player.  The lead coder on Team Fury discovered an inherently simple, but otherwise unrealized feature of Unity during a local Game Jam event.  The discovery involved placing an object that took collisions and an object that generated other items (that would otherwise collide with the collision taking object), and place them both on the same layer.  That way, through scripting, when a ‘bullet’ would be created, it would not strike either the thing making the bullet, or other bullets that had already been generated.  This is a big break-through for the team, and will be utilized to the fullest.

To clean-up the mess of C# and Javascript code files inside the Unity project folder of Fury Void, the lead programmer on the team has converted nearly all C# scripts into Javascript equivalents.  Though this was not a pressing change, it does lead to better documentation of what certain code does, while also allowing for certain code blocks to be combined.

In making the sweeping switch of C# to Javascript code, explosions now do minor damage to the player.  This is to discourage a too-tight of engagement of the player with objects in-game, while also bestowing a sense of power to the player in the regard that their actions have very intense consequences.  The extent of what is appropriate for this damage is as of yet unclear, as reshaping the play-space is currently undergoing discussion.

To play Fury Void, previous QA sessions came-up with a recurring necessity: the player must know how to use the controls.  Therefore, a control menu was top priority these past few weeks in considering what needed to be done.  Such a menu is now it, and even is prepared to show the controls for an Xbox controller when the code for the controller is finished.

Other menu changes involved the inclusion of a menu for the player to customize their ship and the load-out they take with them into play.  A ship-switch menu has been added, but it takes a long time to load initially.  This load-time is caused by having a roster of ships now added to the library of assets in Fury Void.  Due to the wait the player faces, another screen – a loading screen – is on the list of soon-to-dos for the team.

Further aesthetic change comes in the form of showing the boundaries of play to the player on the in-game minimap.  Prior builds of Fury Void did not show the player if they were reaching the edge of game space visually (aside from a small warning message).  Through testing, a visual cue to let the player know where their play-space was at was deemed necessary for addition.  A consequence of this feature is that it is now shown just how big the play-space is.  Plans are now in motion to reduce the field of play to encourage a faster pace of action.

Finally, there was an issue with some builds of Fury Void in that the menu screen would at times be cut-off at the edges if a player resized their screen or chose a resolution that was not accounted for.  This is now being handled by specifying what resolution the game can be played in through Build Settings provided through the Unity engine.  This likely will lead to fewer headaches from those generous enough to play-test the game.

Team Fury is approaching Beta fast, but there of course is more work to be done.  To get access to the alpha build, please email furyvoidgame@gmail.com, visit Fury Void on Facebook, or talk to one of the Team Fury members.  Any and all input is greatly appreciated!

P.S. On a lighter note, Team Fury ‘discovered’ moons in the game.  Though moon objects had been added and implemented many months ago, that fact was largely overlooked by the entire team.  Just recently, during a reworking of the code due to an SVN loss, Team Fury was made ‘aware’ of their presence again, resulting in a hunt for how/when moons were put in place!

And, a look at next time: