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:

Small Team Dynamics in Fury Void

Something to discuss this week is the intimate look into small-team dynamics that Team Fury must face.  No student team could ever be contrived to have the hundreds of souls that work on typical AAA games; heck, breakthrough games have been made on the skills of a single coder!  But in terms of big and small, there are vastly different ways that those team sizes effect game creation.

Fury Void is being worked on, by all accounts, what could be considered a small team.  A 4 man team of part-time game creators leads to many interesting group outcomes; some are good, others could be better.  So, let’s start with areas of improvement.

In the past semester, getting Fury Void worked on (in terms of man-hours) has been a trying affair.  Every person is resigned to work 8 hours a week, with those hours being more or (likely) less during any given week.  However, despite being such a small group, it is my feeling that more quality hours of work have been put into the game past that of other project teams.

That leads me to address the cost of laziness.  I make no exception for myself, and I leave none to the rest of the Fury Void team.  Having a lax day happens; there’s no getting around it.  But, when such an easy-going day arises, harsh impacts are felt on Fury Void’s development.

Even if it isn’t a fact of lethargy, being such a small team, any sickness, travel, or unforeseen situation is murderous to the release schedule.  Entire weeks of work are pushed back in the release window due to events coming-up that ruin work-times.  Though some accommodations and rescheduling is done, it can’t keep up with unforeseen circumstances.  Not even close.

Speaking of schedules, accurate time estimates are the ‘Holy Grails’ of game development.  Fury Void is hampered often enough by either a bug or feature that defies the skills of the 3 programmers on the team (and every forum post on the net).  These issues frequently lead to complete a reimagining of what is to come for Team Fury to develop.

The last ‘negative’ comes more from the structure of the academic course, but the consequences are extreme for the team itself.  This namely deals with the ability to ‘hire’ and ‘fire’ assets for the team.  Therefore, if additional work is needed to be brought in, the course makes it difficult to recruit new developers.  If a person needs to be let go, either from their skills not being needed any longer or that they have become a detriment to the team, they must remain on.  This, more than anything else, has been the largest hamper on both Team Fury and groups that I’ve worked in previously.

But now, some good things of having a small team!  With only a few individuals, getting meeting and work times together is a breeze.    Only 4 schedules are needed to be worked around; in contrast to 10- or 12-person teams that rarely see a true stability to their schedule.

With the regard to being easily brought together to meet, it is very easy to get to know a small team.  As a project lead, I’ve come to know the strengths, weaknesses, mannerisms, and work-ethics Team Fury provides; every person working on Fury Void knows what everyone else is able/looking to do.

Furthermore, if someone has an idea to add to Fury Void’s development process, pitching that idea to 3 others at one time versus a half-dozen others at various meetings is a whole lot easier.  This fact engenders a lot more investment on the part of the team into the project.  Every feature worked on has been developed, in part, by every person in the group.

Finally, having such a short-coming of personnel for Fury Void has helped reign-in scope very early.  Fury Void was originally pitched with a ‘doable limit’ in mind, but only 4 people working on it was never considered.  Therefore, with our numbers as justification, scope has always been taken into account before anything is carried out in Team Fury.  That has and will serve Team Fury very well throughout the coming months.

Small teams have some nasty, terrible qualities, but they also have some great advantages to larger groups.  In this experiment of numbers going against time, Fury Void will likely be better because of having such a low unit cap.  Team Fury is full of surprises, where I’m sure to learn a lot in how to make games.

Welcome to Fury Void

Greetings, soon-to-be galactic saviors!  I write here to introduce you to Fury Void, a student-project game of top-down, space shooting conquest.  Pitch time:

Fury Void is the game of salvation and fire.  This top-down shooter of planet blasting pits you, the survivor of a galactic meltdown far-far away, against the overpopulated denizens of the galaxy set to self-destruct the same way.  Destroy planets, suns, and civilizations to save this galaxy from a similarly dire fate!

Whew – Now a little back-story to the project.  Fury Void started last year as a hastily contrived pitch to become a game sponsored by the game’s projects course of my Game Design major.  The point I built the game off of was to have a title that could, that would, be completed in a year’s time of part-time work by game design students.  I have seen too many student projects fail due to scope/design considerations to want a game of mine to suffer the same fate.  Team Fury was created with this purpose in mind.

So that leads us to Fury Void.  Halfway through the development timeframe, all but 1 or 2 features have been added.  The game has hit alpha (check it out!), with bells-and-whistles being added daily.  The Facebook page is updated weekly.  In comparison, only one other team (Arcana– good stuff!) has made the same scale of progress, so  Team Fury – as I am biased to say – has been doing quite well.

Expect more info coming from Fury Void in the coming weeks and months as the life of this game comes to fruition.  Like and follow on Facebook for regular updates, including new pictures, videos, and alpha links.

In the comments, do let me know what you think of this, or if you have had experience with Fury Void already, I’d love to hear from you, too!  Take care, and happy holidays!