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.

2.17.13 - A Fury Void Update

Though this is a biased comment, Team Fury is fantastic.  The range of what has been accomplished by the few people making Fury Void is a true testament of ability.  In the past two weeks, much has been done, and this is a report hoping to share those things.

To begin, due to player feedback and hands-on play, it was decided that Fury Void uses too big of spaces that have too spread-out features.  With the defense that the game already bends the laws of nature (astral body size, gravity warping effects, etc.), the in-game arena has been condensed.  The decision was reached because the game was not playing as fast as was originally hoped-for in Fury Void’s development.  Now, planets, moons, and suns are closer together, while the bounds to the level are closer to the player’s spawn point.

Making the play-space even more crowded is the inclusion of stationary enemies.  A simple AI script was written and attached to the moons of the game.  The script rotates the moon to ‘look-at’ the player and fire a missile that way.  This ‘proof-of-concept’ demonstrates that stationary enemies are ready to be brought in-game at whatever time proper 3D models are created.  If the worst occurs (no 3D model is found or made), a simple block could serve the purpose of being an opponent for the player.

Look closely - you can see the missiles fly!

Getting to various menus of the game has been an uncertain pain for a long time.  Uncertainty lay with not being able to interact with the screen and the game doing nothing visible while the application was loading; this was not allowable, as some load-times could be many seconds.  Loading screens now handle the visual aspect of the game while the game progresses.  Fury Void no longer leaves the player alone, and this will make debugging and playing the game much smoother (not to mention more fun).

The last QA session held exposed many terrible issues embedded.  One of those would be the lack of audio being produced from the game.  Not a thing played; music and noises didn't utter a thing.  Such an issue eventually was discovered to have been because one of Team Fury’s members had uploaded their preferences for Unity without reason to.  Changing those preferences brought the booms and drums of Fury Void back to the enjoyment of both the developers and the players.

When playing the game, only one level could be played at a time.  When player health drops to zero or below, the game will kick the player out to the main menu.  If the player ship would have been destroyed before going to the main menu, the next time would kick the player out again, as the ship’s health would be lowered again and again.  Thus, whenever the main game level is loaded, the persistent variable that represents the player health resets.  A simple fix this was, but an important one indeed.

Speaking of in-game features, in-game ships can be changed at the player’s convenience.  Fury Void has always been pitched as a game with a certain level of customizability, and altering the game ship is but on feature that’s a must.  Therefore, with half of Team Fury working on the task, a half-dozen different ships can be chosen from to pilot in-game.  The selection can be expanded, but the Team’s time resources are currently being directed elsewhere.

Along with having custom features, Fury Void has always sought the inclusion of game-ending black holes.  A simple script was written for such an object; testing showed that the functions of the code worked.  To continue the development of black holes, suns were tested to make sure they spawn the objects, and that worked, too.  However, further development of the game feature is needed, as when the black holes are brought into the game world, they don’t appear to attract worlds or moons or the player ship as they did in testing.  Additional updates to this feature will likely happen within a week of this writing.

Next, the issue of saving a game in progress, or at least the features of a player profile, has been brought up many times.  It is now in the works to get three available saves in-game.  Using a handy Unity Game Engine feature, the foundations have been laid to fully implement the save feature once it has been concluded what variables of Fury Void need to persist between games played.

In addition to the aforementioned stationary AI being put into practice, path finding AI have been developed.  Though this is a late development requiring much more work, simple blocks find and follow a randomized path in-game.  The AI enemies have yet to avoid planets or other stellar bodies, nor do they find and attack the player, but the fact that the groundwork is done is worth notice in Team Fury’s work.

Lastly, though such things have been mentioned before, explosions finally fully damage the player and other objects.  Exploding suns, planets, and missiles take their toll on the surrounding environment.  This feature truly helps bring forward one of the phrases of Fury Void: ‘Salvation by fire.’  Further investigations into the benefits of damage from explosions will be pursued come March’s Beta.

To end, Team Fury is busy to lock-down all current features, as by the time of February’s last week, no more features may be implemented.  After that, Beta is reached, with a full-force sprint to the end of the year, and the finalizing of Fury Void.  If there are any questions or comments about or for this game, please email furyvoidgame@gmail.com.  Until then, take care.

P.S. Find the previous report here, and stay tuned  for more to come!

I Make Games!

Make More Games

Global Game Jam 2013 came and went like a bang.  In the aftermath, however, I gained some insight into what I do.  And what do I do?  I don't make enough games!  What is a Game Designer to do if he doesn't make games?  Well, it's time to fix that!

With a new fervor, I now design a game every day, with thoughts to the distilled premise of the idea, ways to implement the game, and considerations or questions to take into account.  I won't bore you with every idea I come up with, but details of which games I pursue I hope to share with you.

Here's the first game that I've started to play-test.  It is a mod on Chess, where 2 8-sided dice are rolled; one is the row of the Chess board, the other is the column.  Originally, the rules were that the 2 dice were rolled at the start of each player's turn.  Whatever piece was on the tile rolled was removed from the game, regardless of who rolled the dice.

Then, there was carnage -

Game 1 saw the Black King get taken by a die roll at the start of Black's turn.  Game 2 had White put Black in checkmate because of a roll.

At this point, a modification was made to state that if an enemy King was put in check by a roll, that King could not immediately be taken that turn.  In addition, there was a suggestion made to include 1-8 and A-H indicators on the side of the Chess board to better assist in determining which tile was rolled.

Game 3 had White Queen put Black into check, next turn to be checkmate, but Black's turn rolled the tile of White's King, thereby ending the game in victory for Black.  This move resulted in another modification: rolling the tile that holds a King doesn't remove the King, but just makes it so that the King cannot be moved on the turn it was rolled.

The final game was the first game to effectively end in checkmate.  However, White was utterly decimated nearly every turn by having rolls remove White's pieces one by one.  But, with that, a like/dislike interview was conducted.

Like: There is a great random-chance potential to really alter the strategy of an opposing player by the die rolls.

Dislike: When luck is against a player completely and utterly, the one-sided nature of the imbalance is quite glaring.

Some final thoughts of mine would have to be to mod the game to make it so that a player cannot remove their own piece if a tile they hold is rolled.  Another mod would be to not allow the rolling to be done until either the first piece of the game is taken, or that a King or Queen wouldn't be able to move for a turn if one chose to roll.  Lastly, it was suggested to not allow the Queen to be taken by rolling, which makes the sense to disallow all forms of random-chance regicide.

Well, tell me what you think!  I will likely play this game of Chess again; afterward, there are going to be plenty of other games to make.  Wish me luck, and take care of yourself.



Who makes games?  Who wants to make more and better games?  This guy!

Let me know if I'm on the right track or anything...

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: