Today the writing team hosted a meeting with the game designers in order to discuss mechanics and if our ideas were possible/feasible to implement within the game.
In order to keep each other informed and to progress with game development, we decided to catch up with the game designers and discuss the mechanics of the game and how they interlink with the story. We listed several mechanics on the board and narrowed them down to accommodate the time and skill constraints the teams have. The below mechanics have been discussed and listed with their priorities (1 being most important):
1) Text/Speech system: We decided that speech is one of the most important mechanics because of the power it has to convey the overall feelings and atmosphere to the player whilst guiding them towards their goals. Not only is speech important for the development of the game but it also gives work to several teams, allowing for open communication channels to keep everyone updated and on the same page.
2) Combat/Hacking mechanic: This mechanic is joint first for the games designers priority list as this mechanic is the unique selling point to our game - we have replaced violence with another "Hacking" mechanic. This mechanic has still yet to be decided upon, however, the plan is for it to be a mini puzzle that scales difficulty depending on which robot is being hacked. This mini-game still needs further research from the game designers in order to know what type of mechanic is feasible to implement.
The idea behind this mechanic is to deter violence and replace weaponry in our game, "battles" would be replaced by quick time events (QTE's) and mini-games and the more robots you hack/tasks you complete collates in our games version of an experience bar - hitting checkpoints would unlock the next "level" of the game by allowing the player to access the next boss.
3) Shop/Vendor system: We discussed having a shop where the player can exchange collectables (planned to be pieces of scrap metal/electronics if implemented) for items such as power-ups and temporary boosts to help with hacking robots. However, we discussed that, if implemented, there could possibly only be one vendor within the game, depending on the time and skill required to code such a mechanic. We decided that, whilst it would be a nice detail, their efforts should be spent on the first two points and only on the last two if there was time for them - In order to have two perfected mechanics instead of four rushed mechanics.
4) Inventory: Tying into the last point, with a vendor, the character needs an inventory to hold the exchanged goods. However, this mechanic has the same arguments as before - only research/implement this mechanic if they have enough time after producing that other mechanics.
We also mentioned implementing a spec tree, allowing the player to customise their playthrough and acquire different skills depending on their play-style and ability. However, we felt that this mechanic would be asking too much of the game designers as this would be quite an advanced mechanic to design and implement.
Overall, I feel that today's meeting was very successful and allowed for a clear exchange of ideas between teams and also allowed the rest of the class to see what has changed through the effect of this meeting. By working so closely with other teams, it allowed a sense of consistency throughout the game and would give the player the feeling that the game was created together as a team, not just stuck together at the end of the project.
Commentaires