4.1.13 - A Fury Void Update

The last time writing was indicating that Team Fury had moved Fury Void from Alpha-phase of development to Beta-phase deployment.  Since then, a massive collection of advancements have allowed Fury Void to stride to a final release in the coming month.

To refresh the reader of what Fury Void is, it is a frantic, top-down space shooter combining the random madness of Asteroids with the fast-paced blasting of a ‘bullet hell’.  Over the course of the past seven months, a team of 4 students has put together one of the most successful games of the Dakota State University Game Design program; steps to completing that success are as follows.

Major tests have been conducted on the behalf of the game.  The first one of note was during a presentation at March’s start.  This presentation exposed major gaps that may be included in the design of Fury Void; optimal destruction meters, planet labeling, flavor text inclusion, and further elaboration on the capabilities of the ship were not apparent/were wanted by the audience.  Much more was discussed, but Team Fury would encourage all to attend the monthly presentations to garner what Fury Void is doing.

Later, Fury Void was exposed to the local Game Design group established by Dakota State University.  From that, much feedback was recorded as well as the event was a mark of the first time that Fury Void was mass-tested under the supervision of the entire team.  The main points of feedback consisted of the game being addicting, there needs to be a bit of context given to actions, the Xbox controller needs to support axis aiming, and instructions need to be given to the player.  Lastly, an optimization gauge should be added to judge when a player can move on from a play space; this feature is now on the top of the development list.

Fury Void has been proven to be a fun and addicting game, but it is still a fallible game.  Thus, the following bugs have been handled as-of-late: There was text pixilation of filler and intro messages, but that is corrected; The ship body no longer is ripped from the ship when a black hole is created; Enemies are on the minimap; The intro cinematic text is centered on the screen; Xbox controllers support any axis shooting; and, music and sound plays everywhere.

The final bit to cover would have to be minor features being added or tweaked in gameplay.  The Difficulty option available to the player has been moved to the Ship Switching screen.  Enemy weapon shots have visible light trails added to them.  Enemies now have the code structure to be randomly spawned in-game.  Any text option that is selected is visibly highlighted.  A ‘warp zone’ has been added to identify where the player can go to change solar systems.  In closing, a smaller arena has been created ( a feature added that was lost at some point in the version control software ).

To come, here are some of the features on the development list.  First, time orbs in the liking of the energy orbs are to be implemented; they would add time to the clock so the player could play longer.  An optimal destruction gauge is on the top of the creation list; this gives an indication as to when the player has done their duty in the given system in destroying enough of the solar system they are in.  Additional customization options should be given to the player; ship speed, health, agility, and damage are to be included.  Context to what the player does and why they are doing it is of utmost importance; this feature will require a bit more thought.

Before the next report, there will be more playtests and even some professional advice given on the game at the Game Development Conference.  Please pay attention to the changes to come, check-out Fury Void on Facebook, and play a beta here.

3.1.13 - A Fury Void Update (Goodbye, Alpha)

March 1^st marks the last day of Fury Void’s official Alpha-phase development.  In the past 2 weeks, the rush to get features into the game has been full of vitality, but avoided any sense of ‘crunch’.  The following is a summary of what was completed to hail Fury Void into its time of Beta.

To follow-up on the reporting last time of saved games, profiles now may be loaded.  The previous standalone save feature was only usable in the fact that Fury Void would let Team Fury know if a save had been made, and of what variables, while developing.  When loading a saved game, thus far whatever ship was selected last time is automatically selected, along with the player’s choice of weapon and score.

When objects are destroyed in-game, the player’s score grows.  Now, when those point-giving objects explode, a pop-up of the point total for that object is displayed.  It appears quickly, and then leaves.  Such a feature delivering this form of visual feedback to the player is hoped to have only beneficial consequences when Beta testing is conducted.

Further development of the previously mentioned black holes has led to a few new tweaks.  The first is that black holes spawn in-game given a random probability when a sun is destroyed.  Second, the black hole no-longer pulls objects in indiscriminately; neither do the holes warp themselves in the 3 dimensions of the play-space, as restrictions have been added to their movement.  The third tweak would be that the black hole visually grows in the game to help show the reach of the object.  And again, the player will be caught by the black hole – there is no way to escape a black hole’s pull forever.

A note on AI enemies would be that patrolling, shooting ‘drones’ are now in-game.  They currently are manually generated without the random placement featured in the rest of Fury Void, but refinement of the feature is to be handled in the coming weeks of the Beta-phase of development.  However, these enemies currently dodge out of the way of planets, they occasionally dodge the player’s fire, and follow randomly created pathing-nodes if they are not chasing-down the player.

Next, an introduction text cinematic has been included at the start of the game.  It gives credit to Star Wars in how the message of the game is presented (scrolling up into infinity).  The screen of the cinematic also has a soundtrack to play while watching the screen in an attempt to keep the player’s senses fully engaged when watching the cinematic.  Lastly, a simple button press will allow the viewer to escape to the main menu, as Team Fury hopes to include further details on the game being played.

On weapon switching, more options have been added for the player’s options.  All weapons can be assigned different colors in their projectiles, while development of engine color, weapon effects and damage, and player speed is currently underway.  Future tweaks will likely be greatly influenced by player feedback.

To scheduling, the week preceding March 1st was to host the feature-lock of the game.  Team Fury proudly met this goal, with time to spare.  In reality, Beta-phase was instantiated on Wednesday of the week, putting Fury Void on an early track for the coming Beta development.  This occurrence spurned an in-house QA walk-through of the game, keeping a special eye to any and all bugs, things that need a visual or code tweak, and places were additional functionality would be key.  A list was compiled, and now offers a constant reservoir for future issues and issues that have yet to be handled.

The week after March 1^st is considered Spring Break, and will most certainly dampen the work put forward by Team Fury.  However, many tasks scheduled for the week are of a brainstorming and sit-and-think variety.  If any work is to be done on the Fury Void game, handling the ever-growing bug list will keep any team member busy.  After Spring Break, major changes specific to the Beta-phase will take place.

With what has been laid-forth, Fury Void is safely said to be one of the top 2 best developed games of the Dakota State University Game Design program.  Team Fury is excited to present their game to the world, but is arguably just as excited to work on the project, as every week sees accomplishments made.  If interested, the final Alpha-phase build is online, and Team Fury encourages all to play it and give feedback to any member of Team Fury or at furyvoidgame@gmail.com.                                                                                                                                                                   

I Make Games Followup (with Rules!)

Number 1 is Done!

To take off from my previous post on rolling dice to affect gameplay, a few more play-tests were made.  With that, I feel confident in laying my results down and moving on.

To save space, suffice to say that more games were played.  The votes are in: using dice to randomly kill-off pieces gives a different form of fun from the regular board game.  But before a final rule-set is written, here is a summary of the last few games:

The Chess mod should keep the random chance to destroy any piece on the board.  The player whose turn it is nor the opponent can tell what any given turn will bring.  Even the most carefully constructed strategy can be torn to ribbons in the space of a roll.  In effect, this simulates an actual battle, where 2 sides can't always count on either the enemy opposing their every move or that their own units will be in the key locations at the right times.

On thing suggested to change for the mod is to make it an option for each player to roll.  This is a strong suggestion, as the number of units on the board would come into deciding when to roll; if a player has more pieces on the board than the other, the first player is more likely to lose a piece.  Such probability and gambling to take a gamble on a pair of dice raises great curiosity in my mind -

- But despite what curiosity I have, a game designer needs to know when to call it quits and move on.  Therefore, with what I've learned from repeated play-tests and iterations through my Chess mod, here are the rules and suggestions for play as they stand now:

Chess Mod - Bomb Drop
This mod is played with the regular rules and pieces of Chess, with the following additions.  First, 2 dice are needed for play where 1 corresponds to the row, the other die to the column, of the Chess board.  Secondly, the 2 dice are rolled at the start of each player's turn.

When the dice are rolled, a 'coordinate' of row and column is made.  If there is a piece of any color on that 'coordinate', that piece is removed from the board as if it were taken in regular play.  If the piece happens to be a Queen, that Queen may not move on the player's turn it was rolled on.  If the piece happens to be a King, the dice are rerolled.  If there isn't a piece on the 'coordinate', it is a miss, and the player's turn resumes as normal.

Following that, here are some suggested edits that you can try out for yourself:

• Allow each player to decide for themselves if they wish to roll or not.
• A player doesn't remove their own piece if said piece's coordinate is rolled.
• The Queen has 'hit points' and can be hit a certain number of times before being removed.

Lastly, here are some questions that I didn't get answered in my play-tests, but were present when I first created the design:

• If the game is timed, does rolling the dice apply to the time?
• If a piece is taken, do its points still apply to the score of the game?

(Not incredibly important for casual play, but these questions are a must if any sort of standard tournament were to be held.)

Well ,that is my first game on this new adventure of mine.  Creating games is what I want to do, so I aim to do it.  For all of those that were swell enough to play my mod, thank you.  My next adventure aims to be a RISK mod (it has zombies!), but it may take a bit to get the board; play-testing will also be a trial, so I may make a separate game in the meantime.  So, until my next report, or when I conscript you into play my games, take care.