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:
