Shreevallabh Kulkarni

Phase 3: Sounds and Playtesting

This was one of the most interesting parts of development. I had given each NPC a personality, which was defined by the tone of their language they speak while communicating with the player. To make it more effective, I decided to give custom speech voices to NPCs. The problem was all the NPC’s were orcs and my voice tone is soft (at least not “orc-ish”), so I decided to use voice changer and then record all the voice lines. It was fun to listen to my own voice in a game like Skyrim. I playtested the mod with my friends and they found it fun with a couple bugs reported. Some of the bugs were related to “soft lock” which is discussed in the following part.

Things I learned – avoiding Soft Locks
Questing is a very important part of games, especially for the RPG genre. Proper quest design is necessary to keep the player immersed in the story. However, being an RPG there are could be a lot of loopholes which quest designer needs to take care of. For example, what happens if an NPC dies who is a major part of a quest line? Or what happens if a quest item is lost/destroyed by the player and a future quest is dependent on it? Or what if the player tried to complete the quest objective first before accepting the quest?

A simple loophole can break the whole quest chain and possibly stop the player from progressing in the game. These problems are called “Soft Locks” (a term very famous in the speed-running community).
 

Following are a couple of techniques which I used to solve some of the basic Soft Locks:

1. Make important NPC Immortal or respawn them. (This was done using “flags” in Creation Kit)

2. Use of Conditional Logic to traverse between different stages. So, if an NPC dies or the player destroys the quest item, then just traverse to appropriate quest stage.

3. Use of dialogues system. Allow the player to talk to quest givers again in case the player loses an important item and if possible, tell the player through dialogues about what could be done next. For e.g., If the player has given an objective to carry one item from one place to other and player loses the item, then let the player get the item once more from the quest giver. But there can be a problem of game balancing if the player keeps losing items, in that case, tell player first to not lose the item and if he loses it then change future dialogues dynamically. For e.g. NPC’s will remember that item is lost and will say “You should not have lost the item” etc.

General Design Principles I came across and tried to implement in the project

• Sandwich Rule (“Bethesda Tutorial Encounters,” 2018) – Do not immediately engage the player in combat after a loading screen, the player might have gone to get a sandwich.

• The game should provide feedback to the player’s actions to show that the designers do care about players choices.

• Mix up the types of enemies in an encounter. Do not put similar types of enemies in one group encounter. For e.g. have some melee, ranged casters in one group. This will give proper fighting experience to all types of players.

• Players will always try to take the path of least resistance to get to the loot.

• And many more…

Conclusion:

I learned a lot about how players react to different types of rewards. More than 70% players in the sample size of 50 testers, tried to sell the quest item (if it is valuable) while being aware of the fact that this will result in abandoning the quest (one of the side quests). I was also able to get a broader perspective of how quests are designed to keep the players engaged in the story line.

On another note, I was managing the project using a source control tool, due to this the problem of software crashing was practically nullified. Polishing the stuff was not the top priority as I did not plan to release the mod in public. Additionally, keeping the scope of the project small also helped to keep the project on track.