Deep in the woods neighboring a quiet village, an experiment has gone horribly wrong. The powerful witch who once had the skill and knowledge to brew any potion one could imagine… has erased her own memory! It’s up to you to help her rescue her animal familiars, rediscover her forgotten recipes, sell potions to the many heroes and villains throughout the land, and restore the lost memories of the lover she can’t remember in Idle WitchCraft!
This is the description of the mobile game I’m developing in a team of three as the lead designer, and I’m super excited to bring it to life!
Idle Witchcraft began as a simple idea: a potion selling simulator where you don’t know what you’re selling. A customer might come to your shop asking for a potion of strength to slay a dragon, so you hand him some bottle of red liquid with orange swirls that you think will do the job. However, you later found out that the potion caused the customer to explode instead! While a funny idea, it doesn’t entirely suggest much of a gameplay loop, so I tried to build that out first.
Firstly, how do you get your potions in the first place? I decided that it would make sense if the player was a witch, mixing ingredients in her cauldron to see what she can brew. This immediately implies a crafting system, but there are plenty of ways to go about that. A teammate of mine suggested that any two unique ingredients should combined to create a unique potion. I thought that this would really achieve the sense of discovery I wanted to offer players, and so I immediately took to creating a table of which two ingredients make what.
Someone once said that game development is secretly all spreadsheets. I think I’m starting to understand
With this idea however comes a harsh constraint. For each Nth unique ingredient, I would need to come up with N-1 unique potions to go along with it. However, this also meant that with only four ingredients, I could have six unique potions. I didn’t want the recipes to feel random either, so I tried to have the combinations make at least a little sense as to the effects they produce, that way players could be rewarded for trying to predict what ingredients might do (Ex. Phoenix Feather + Night Shade. Fire, Transformation + Poison = Deadly Explosion). That said, I didn’t want it to be too easy and trivialize the potion-crafting system, so it’s not super intuitive. Essentially, if I decide it makes some abstract sense to me, I think that’s perfect. We’ll see if I’m creative enough to come up with a lot of potions and ingredients!
The next question I had to answer was how does the player gather these ingredients? I decided that as any proper witch should, the player has a couple of magical animal familiars. These familiars can be sent out to different regions of the world to gather different ingredients, and that different animals might be able to gather different ingredients from the same area! I thought that this would provide players with an interesting choice of which animal to send where, rather than just which region has the resources they want the most. This idea isn’t quite as developed though, as I deemed it unnecessary for this sprint’s end product: a paper prototype.
Over the past two weeks, an elephant has been lurking in the room that is my design. From a technical standpoint, how am I going to make it so that each potion can have a unique effect on each customer? Writing a different outcome for each customer is a decision that will have exponential time costs as the roster of customers and potions increase, so I couldn’t choose that without a time machine.
Thinking back to the fantasy setting, I had the idea to borrow some tabletop RPG elements in the form of character stats. Each customer interaction, or “scenario” as I’ve been calling them in my design doc, will have a character and a task. For example: a knight who wants to slay a dragon, or a scholar that needs help studying. In the code, there will be six stats that can be relevant to a given scenario: Power, Endurance, Dexterity, Intelligence, Perception, and Charm. Each potion, in turn, will give unique bonuses or debuffs to each stat. Each scenario will then take one or more of those stats, and tally them up against a total point requirement for success.
For example, take the knight’s dragon-slaying quest again. Say the applied stats are Power and Endurance, and the point total is 4. The player offers a potion that grants +1 Power and +2 Endurance. Now since the player has scored 3 out of 4 points, the character has a 3 in 4 chance of success, which is determined by a random number. This is meant to both tip the scales in the player’s favor (not meeting the point requirement does not mean immediate failure) and adds some tension to the game. For better or worse, it’s no secret that a large subsection of gamers enjoy gambling, just look at the gacha genre, or mobile slot games. With this decision I hope to capture some of the thrill of uncertainty that RNG brings to a game.
Most importantly though, at a technical level, this means that each potion is a collection of six numbers, and each scenario is a point total and a list of applied stats. This makes it extremely easy to program new potions and scenarios, while still giving each potion its own unique identity and use cases.
Now, with the two core elements of the gameplay loop nailed down: Potion-making and customer interactions, I was ready to create a player prototype to playtest the game. My main goal with this prototype was not only to iron out a set of rules and procedures that could easily translate to code, but to prove that this idea was fun in the first place. For the prototype, I made three different kinds of cards: Ingredients, Potions, and Scenarios
With just four ingredients, players could brew six unique potions!
The most basic of these were the ingredient cards, these had the name of the ingredient, and some basic art on them, with no information on the back. I would give all four cards to the player immediately, and they would choose two to brew a potion with.
Beware the Potion of Immediate Combustion!
Upon choosing two ingredients, I would give the players a potion card back. The front of a potion card consisted of its recipe, and its artwork. The back featured its name, the recipe, and the effects. I handed the player the potion card face up, and told them not to flip it over yet, to simulate the unknown nature of the potion effects that I wanted in the final game. After brewing their first potion, a customer would arrive at the player’s witch hut.
The scenario cards are basically just dialogue boxes!
To simulate scenarios, the front would show the name of the character, their request, and the reputation points that would be awarded if they succeed. From here, I would offer the player a chance to brew a second potion, then letting them choose a potion to give to the customer. Upon making their decision, I would flip over the scenario card, revealing the point total and applied stats.
You may notice that the second scenario has two different conditions. If the player fails the first charm check (winning over the knight’s affection), the second check (6 Power/Endurance) is applied. If the second check succeeds, the player is given an alternate outcome! (The maiden impresses the knight with her astounding strength and falls head over heels for her!). This provides players with a second chance if their potion didn’t do what they’d hoped, as well as surprises them with an unexpected outcome!
The potion of radiance proved particularly strong, immediately succeeding at 2 out of the 5 scenarios, and scoring 2/4 points on 2 of the remaining 3!
After revealing the scenario stat check(s), I would flip the potion card over, revealing its name and stat effects. After that, I’d tally up the points, and then if necessary, use my phone as a random number generator to calculate success. Afterwards, the player would keep the potion card flipped over and could use it again. Then the process of brewing up to two potions and serving a customer would repeat!
Overall, the paper prototype proved to be an astounding success! I served as the game master for most of the playtest sessions, and players really enjoyed the guessing game of which ingredients would make which potion, and which potion would help the most. Even on failure, players still felt satisfied with the knowledge they gained, and that would help them succeed at later scenarios. One potion that got a good laugh out of players and spectators (people were even watching others play the game!!!) was the potion of Immediate Combustion. This potion applied -99 to all stats, immediately failing the scenario and implying that the customer blew up. Most players were shocked at this, and found it funny. One player even intentionally gave the potion to every customer!
Throughout the playtests, one thing became immediately clear. Players really enjoyed seeing the impact of the choices they made on the world, whether it was blowing up a knight, or accidentally helping the scholar charm his way out of a failed wizarding exam. In fact, multiple players asked me, “Since I blew up the knight, can the young maiden fall in love with me instead?” This was an immediate green flag to me. Players saw these simple drawings, lines of text, and number checks, but also engaged with a fantasy world and wanted to see even more impact from the choices they made.
This provided me with a clear direction of where to take the game from here: branching storylines. Some of the scenarios already built off of previous ones, for example, the young maiden falling in love with who is assumed to be the knight from a previous scenario, or said knight trying to escape from said maiden in a later scenario, but players would encounter the same scenarios in the same order no matter what choices they made. In future playtests, I want different scenarios to appear based on the success/failure of previous ones. Maybe if the knight fails in his introduction, the young maiden will instead appear wanting to fill the shoes of the fallen knight, or perhaps have a different love interest. Maybe if the scholar flunks his wizarding exam, he’ll find that his true passion in life was being a tavernkeeper. Having branching narratives like this will greatly increase the amount of scenarios the game needs, but the value it will provide to the player will be well worth it, as well as offer a reason to play the game more than once to see what could go differently!
Comments
Post a Comment