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...