Beginnings of a New Project: GAM 111 Week 8

For the second GAM 111 assessment we were told to make a state driven game that incorporated the use of the SendMessage and or Unity Event System functions.  We were provided a few examples such as the Pokemon Battle System, XCom, Earlier Final Fantasy releases, and  games like SolForge. I began planning this project in Google Docs and laid out the core workings of the game.

 

The play for the examples mostly all worked on turn based systems. In Pokemon and Final Fantasy the player would choose an action for the character/s and then proceed to battle. Hearthstone differed from this system and battle proceeded with the players attacking in turns. For my project I decided to stay away from any sort of other gameplay like movement and narrative, centering the mechanics on the battle system.

Screenshot (32)

To aid in the design of the coding I made a rough plan for what I wanted the play screen to look like. I kept coming back to thinking about games like Yu-Gi-Oh and The Stick of Truth with their multi player slot boards. For my project, I decided to start with four slots which is subject to change. Also I have added a stash, where the players select the monster from, and a graveyard to visualise fallen monsters. Another feature I am looking to add is some sort of overall stat bonus, to be name the Frontline. It will be selected in the first round and cannot be changed for the entire battle. Preferably, the game will have minimal UI elements showing at any one time showcasing the monsters and the board itself. When needed or clicked on certain object the corresponding menus will appear e.g the player clicks on a monster placed in a slot and a menu will open allowing them to select the monsters attack state.

Screenshot (33)

 

The game will play similar to the Pokemon system but with multiple monsters.
The players will be able to select an action for each monster. The system will then move to a battle state where the calculations and animations for the attacks will happen. If there is empty slots after the attack stage that players will be able to fill the spot and continue, but if all the slots are still full the monster will proceed to attack again immediately. The process will repeat until one of the players is out of monsters.

 

Each monster will have varying stats but will only have three states of combat. The three monster types currently decided on are:

  • Armoured – Medium Attack, Heavy Defence.
  • Scout – Heavy Attack, Low Defence.
  • Regular – Low attack, Medium Defence.

Monsters won’t have individual attacks but rather have a selectable state for the round. They can be commanded to defend their position, attack the enemy, or heal its companions (the other monsters belonging to the player).
As well as planning the game, a schedule and list of tasks has been created on Hack’N’Plan to keep me on track. I can see myself running into problems creating an A.I player because I have never completed such a task before. If I am able to adhere to planned timing on each component, I will have left myself enough time to overcome any problems before due date.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s