Game, game and game: Alchemy Mini-games

Summary
I'm focusing on designing my game that centers on item creation (synthesis) by trying to solve problems with the world and gameplay design. This is a mixture of notes, thoughts, processes and images that are and aren't coming together to form my prototype. There are some half-formed ideas that could be something if I give them some tender loving care. Things have been haphazard in the workshop so step carefully. Once again the content of this post is a little old so some things may have changed since.

Design Aim
To produce a player experience that allows players to experiment and explore through a fantasy world via item creation.

Premise
After being duped by a fraudulent alchemist, the player is left to deal with requests from a nearby village while learning how to be an alchemist.

World Design
The game environment has to be varied so that the player doesn't get bored and provides them with goals to accomplish. The design of this environment must have something of interest that provides an activity to do or "puzzle" to solve. Puzzles are defined as areas of the environment that the player will require particular tools, items or skills to gain access to. Solving the puzzle grants the player access to additional sources of ingredients, tools, quests and recipes.

I'll be taking inspiration from Last Day of Work's Virtual Villagers series which have small game environments but also interactive sections of map that take time to solve. The following screenshots feature some of the puzzles that can be solved in the more recent games. Solving these puzzles is a eventual process as the player's villagers lack the tools and knowledge to solve the puzzle. The player also has to work out what items and other puzzles that will need to be gathered, made or solved before continuing with another puzzle.

Gameplay

Activities include:
- Ingredient gathering
- Farming
- Synthesis
- Exploration
- Experimentation

Players will need to level up certain skills or tools to explore the entirety of the world and "complete" the game. Tools aid ingredient collection, item production and exploration while improving skills increases the success rate of item creation and item quality during synthesis.

Seasons and the weather will affect the varieties of plants that can be raised, ingredients that can be found, areas that can accessed and some of the activities that can be fulfilled by the player. During rainy days, the player won't need to water plants but may need to repair bridges or other items in the area.

Tools
These are created by the player to assist with item gathering, production and exploration. Better tools can be made which increase the quantity of items gathered or allows the player to harvest higher grade items. Eg. a basic pickaxe gets you 3 pieces of copper but a magical pickaxe gets you 3 pieces of gold. I still need to work on what the upgrade curve will be like.

Farming
The player will be given a portion of land that they can use to grow plants for synthesis or to earn money. The majority of plants grow in particular seasons and have different growth and harvest cycles. Some plants may grow differently depending on their neighbours and environment. Players will need to manage their crops to ensure a successful harvest by watering their plants and learning

Greenhouse
The greenhouse allows players to grow plants under controlled conditions but players will have to devote more care towards the plants The greenhouse is accessed once the player has gained access to it by solving the puzzle of its restoration. All plants require water to grow but some may require additional items to grow and produce crops.

Synthesis
Synthesis are the processes the player undertakes to create items by mixing various items together. The items created can aid the player gather ingredients, explore the environment, supplement income and fulfil quests.

Players will have the option of synthesising using a recipe or by experimenting with various quantities and ingredients.
Recipes can be found, bought or created by the player via any experimenting with the synthesis system. Recipes are used to produce specific items but can also be used as guidelines for experimental synthesis.

Some synthesis processes are interactive which produce items of differing quality based on player's performance. Item quality will determine how much an item can be sold for but also the success of subsequent creations using that item.

The following are interactive processes:
Basic Synthesis
- Involves stirring mixture
Distillation
- Time pressure and heat to create right mixture
Pestle and Motor
- Crush things into powder or pellets, pellets require a liquid to form

I’ve been having some trouble coming up with ways to iterate on Poffin creation and “alchemy” mini-games. I’m starting to worry that any processes I come up with is going to make the game feel like Cooking Mama, which is not what I want. Making a lot of mini-games could be really time consuming and I can’t guarantee that people will think it’s fun unless I do a lot of testing.

I came up 3 basic procedures that I could begin designing and I’m worried that my initial plans are too basic and repetitive while later renditions feel too complex and aren’t cohesive in regards to the overall design.

The 3 initial procedures were:

Stirring (essentially Poffin mixing)

• I hadn’t decided if spillage would be a factor in this

• I was also considering including shaking of the pot

Distillation

• The player adjusts how much pressure is applied by following indications/clues from the heating element
• I hadn’t decided if this would be a flame colour change or build up of steam

Mortar and Pestle

• Crush objects into powder or pellets
• Pellets require the inclusion of liquid to form

As you can see these are pretty rough and aren’t very interesting. I dabbled with the idea of trying to get the player to use the same movements but in varying degrees. For example, a left to right motion would shake the alchemy pot but grind objects using the mortar and pestle. All this is doable but then I realised, this works in Pokémon Diamond and Pearl because there is a stylus to draw with. The average PC user doesn’t have this kind of peripheral.

I hadn’t even considered the Apple or PC users in my early designs and that made me do a double take, how could I implement something similar or would I need to come up with something different? I thought about condensing the above processes into 1 that required the player to do different things based on what “procedure” it was doing.

I started with the idea of an oscillating machine and thought about getting the player to “spin” it so it’d combine objects. In my head it looked like a steampunk washing machine crossed with a wooden ship wheel. It work by the player loading it with objects and then spinning it in different directions and angles to make liquids or solids.

I did consider getting the player to pack the machine in particular manner to achieve the best result but I did a bit of Googling and saw video and guides about a Minecraft mod (Equivalent Exchange) that lets you craft items. I ditched the idea as it required players to think like the designer and doesn’t really make experimenting fun.

I then considered making particular movements relate to particular processes:

Rotate

• General synthesis (think “Will it blend?”)

Push Downwards

• Trying to simulating added pressure
• Maybe the machine tries to resist the added weight/build up

Left to Right

• Controls heat

Up and Down

• Releases steam from the machine

I don’t think I got very far from my initial idea and it’s frustrating me because these systems are integral to the concept. I did toy with the idea of a transmutation circle that the player had to create and various symbols and positions would indicate what would happen to the items placed. The player would have to either slot pieces together to form the circle or rotate them until they “fit”. I might scrap it as it doesn’t seem very interesting and it doesn’t fit with the game’s tone.

I remembered using an item creation system that was interesting and involved a level of strategy. It’s from a game called Rogue Galaxy and is best explained via video. The player would collect/buy/find blueprints (recipes) which would set up an equipment template (just lay stuff out to get the player started) in the factory and provide clues (if the recipe was difficult) to what ingredients the recipe needs.

The trick to this process was that the player had to figure out what processes and items to put together into a complex assembly line. All materials/ingredients have to be processed by particular machines and occasionally more than once. Ingredients have to arrive at the same time into machines called assemblers to be fused into the item. Each piece in the assembly line adds time so players may need to install extra pipes to delay items so they reach the assembler on time. A more complex item is created here.

I also like the fact that players had to install power cords to run the machines and that you could watch the whole thing go when ready to see what happens. Since this was an extra, players got a set number of items to discover. If I remember correctly, you could also make upgraded or additional equipment to make processing easier. This system does remind me of The Codex of Alchemical Engineering and similar games.

The ideas I have been working on go back to my one I wrote about earlier the oscillating machine.

Initially I hadn't thought about the player having to wind the machine up and do additional actions like pulling the valve to release the pressure built up as I had originally designed this as an interation to the Poffin creation system. I believe it was one of those moments where one has to step back to see what you've created. That said, there can be something appealing about having to keep a machine running while waiting for the item to be processed. This could get quite complicated if recipes require exact temperatures, general pressure levels and momentum to create their item.

This design does follow the earlier derivative of getting the player to engage with a method that encourages them to practise synthesising items but I have my misgivings about this one has it involves numerous "hot spots" and could be too complicated for casual users, as this machine requires immense co-ordination. I don't think the "chore" like aspects will appeal to casual players as it's not overly engaging and could become very repetitive. I'll be interested in seeing if this machine works at a prototype level, provided I can devise a way from making this mini-game too frantic but also keep it challenging for players.

I also considered having a basic version of the machine that would then add additional parts to its basic layout when required or when the player chose to perform a particular process. It seems less efficient to compartmentalise the synthesis as it would give players too much control over their synthesis and may be problematic if they miss out on particular items because it can only be made using a particular method.

The version was made up based on my original brainstorm and encompasses The main problem with this version is ensuring the "machine" recognises all the different movements within a set area and how to prevent the player cheat their way by just waggling the mouse willy-nilly. This will be difficult to execute and I think the movements won't work too well without getting the player to "draw" using the mouse. This one would work far better with a touch screen to get the machine to register the variations of movement.

I think the transmutation circles work best in a casual game environment as it can become as easy or difficult as I dictate. This design does lack a level of complexity as it doesn't take much tactical thinking from the player and could become a matter of routine motion (read: chore) rather than something fun. I did have some thoughts about the player having to align it under a time limit, complete two or three different circles to transmute stuff, players being given a riddle that explains that certain symbols have to be in certain quadrants to complete the circle and a sliding puzzle variant to make this mini-game a little more interesting.

I'll be working on the first alchemy machine and transmutation circle mini-games while I work on the game's overall design. Hopefully something interesting will come out of the whole thing. I'll be updating this space when new developments arise. So game, game, game and game.

Game, game, game: Alchemy - Prototype II

Recap
I'm prototyping a game that focuses on item creation and am running through its second iteration. I'm trying out newer and revised systems that encourage more strategic gameplay and developing content that supports what I'm trying to do. This version, entry and future progress owes its existence to some very helpful fellow designers. A gigantic thank you to Jasmine and Inicus qvist for your help and guidance.

I've made some changes to the playable areas and have started testing the inclusion of tools and farming which has led to some developments that are helping me realise the flaws and positives to this particular design.

The World

I've changed areas and tried to design them as areas that aid completion of player's goals by being sources of ingredients and recipes, pathways to different activities and areas and providing instructions and hints.

I had planned that at the start the player would encounter a character that forced them into becoming an alchemist by making the first player objective: learn how to create an item. This mentor character would give players additional instructions once they performed particular tasks and then at the penultimate moment skip out of town; leaving the player with an unfinished education and a stack of requests from townsfolk.

I have no idea how to script this series of events so I've got a less effective way (read: lazy) of trying to set the scene for the player.

It's not as effective as it depends on the player noticing the book and then requires additional coding to include events that encourage you to use the recipes found in the book or including blatantly obvious hints from villagers.

It also harks back to problems from the earlier version where recipes and objects aren't very obvious and demonstrates a lack of player guidance.

The following is a Work In Progress (WIP) shot of an area that the players can source materials but also gain access to various areas by clearing pathways. I think this area needs more work as it has limited interactions and activities and makes ingredient gathering simplistic.

The world is taking shape but I do think that will be getting too big, boring and doesn't encourage exploration. I'm going to be researching and thinking about a better designed world that prompts players to explore and experiment.

Like this space below, it's only use at the moment is to provide the player with chances to find seeds and ingredients but not much else. What it lacks is additional items or activities that are found and completed in this area.

This area (and game) would be more interesting if the player could find seasonal items to sell or synthesise with but also solve problems or puzzles using tools and items. A problem like having to create pathways through areas to gain access to elevated areas or clear trees by using tools or creating items like rope.

The inclusion of seasons and real time changes to the game world would be an interesting dynamic to include and one that I'll be considering for later iterations. These changes would be interesting as they'd offer additional stimulation and incentive for exploration by the player.

Farming is a newer addition that is meant to provide players with extra benefits but the system has some flaws when executed.

Farming
It took me a while to get this coded but players can grow plants in a specified area at their home base. I've added a few variables into the growing system so players have to put more work into growing their plants.
To grow plants players need:
- A hoe
- A watering can
-Seeds or bulbs

I originally was going to have two plots, one for "normal" plants and one for "magic" plants but then decided that the player needs to have more freedom over where and what they plant. At the moment, the harvested crop is a random plant because scripting for additional types of seeds, bulbs and plants takes more time than I'm prepared to allocate at this point.

Having random harvests works at this prototype stage because I don't have any short or long term player goals but I imagine that it would become frustrating and limiting not being able to strategise one's harvest.

Above the piece of script that's called when crops are harvested.
$Items = ["I:019,2|25","I:020,3|25","I:021,2|25","I:022,1|25"]

This is the code that randomises the harvested items for crops. In English it reads: $Items = ["Item: Item ID, quantity | probability (%) of item being called].

I've also encountered some problems with providing the player with seed and bulb sources. The sources in the game are village shops and random drops in the woods. Ideally players should get more seeds and bulbs through harvesting their plants or from digging in the ground. I'll be including this at a later point but I'll be making it a random chance to avoid making farming too easy.

Some problems have cropped up with my current method of planting. Without specialised sprites, it's a little hard to know where you're planting and what the plants' statuses are. I thought coding ploughed land as unpassable would enforce the player to think strategically about their crops but it causes confusion and frustration.

Plants require some work from the player, they will only grow if they are watered. To stop players from constantly watering plants (and get them to do other activities), I've put in a delay factor after each watering. I do want players to work a little for their harvest but not too much so they'd feel like they're performing a chore.
I'd like to add additional areas that allow players to grow different plants based on particular conditions like a greenhouse that can cultivate plants if the "heater" is left on. I'd like to think that this might be an interesting way of implementing experimentation if plants grow with particular traits which develop into interesting items. It's still something for the drawing board.

I'm also trialling rewarding them if they plough a particular number of times against finding an item buried in the ploughable area. I think both options work but the former does function as an achievement while the later would work better as an exploration reward if I made additional areas that can be ploughed.

I've been testing out the process of creating and using tools and my observations have brought up a number of things.

Tools
The main problems that I've come across with implementing tools have been:
- Rates of accessibility by the player
- Finding the problems solved by the player possessing the tools

I noticed during my playtests that I was able to create tools rather quickly and made me wonder if I had to do some scaling to make the game harder. Here's some of the solutions that I came up with to try to solve this problem.

Solutions
- Increase quantities needed to make tools
- Reduce quantity gathered
- No tool, player receives lower quantity
- Tool, player harvests a higher quantity
- Add additional step to creation of item
- Player creates metal and then creates tool+

I didn't implement the first solution but I did try the second and also included a delay factor because I was worried that players would easily spam the system. The delay involved delaying the resource's respawn and disallowing the player to use that particular source until it had "recovered". As more playtesting and discussion discovered, my anti-spam decision was deliberating gameplay.

One of my fellow designers suggested a far better solution, tools can be upgraded or the player can create higher level tools which when used increase the quantity of the item harvested or reward the player with a higher quality item. This method encourages players to use the tools to gather ingredients for synthesis of items but also gives them additional goals to work towards.

It'll take some time to work out a smooth curve for the tool levels/upgrades but it will be happening. I haven't implemented the inclusion of an additional synthesis step where the player creates metal and then uses that with other ingredients to create their tool but it will be happening at later stages.

This brings me to my other problem, what advantages do tools give the player and what can the player do while they're aiming to get tools? Not a lot as my playtests showed. In their current state, tools only offer two advantages. They can clear pathways to additional areas that have more ingredient sources and they increase the quantity of items gathered. Some tools like the hoe and watering can grant access to the farming feature.

As outlined before, tools may need some additional uses like helping the player solve problems like gaining access to different areas. I think the main problem with tools is the way they are earned in the prototype. The prototype requires players to create tools in order to earn enough money to buy recipes to further their progress. I had removed the free delivery of tool recipes for the player and now they must purchase them.

I did this as I spent a lot of time thinking about tools and what players could do without them. When I realised that they couldn't do much, I tried to come up with solutions to fill in the gap. I think players need some encouragement and guidance to realise that tools do have benefits. This could be something as simple as scripting an event where they see a character use tools to get an item or even a NPC commenting on the ease a tool brings into his life.

My current planned solution is to provide the player with ways of making money, getting recipes and rewards play by appealing to a sense of achievement. One of the problems with this prototype is that it doesn't encourage players to do anything and I need to find a way to encourage them to play the game but also help them discover what can be done. I'm still working on viable methods for this but I'm hoping that quests might provide some answers.

Quests
I realised that the player does have a limited range of materials available to them so I'll be coming up with recipes that allow them to make use of these ingredients. The items produced by these recipes aren't worth much in terms of cash so to integrate these simple recipes, I'm considering using quests that act as tutorials but also require the player to synthesise these early items to get rewards.

Rewards are likely to be a mix of money, items and recipes. I'll need to start planning a difficulty curve and a scale for rewards. I imagine that quests would be better integrated if I included the scenario with the player being duped by the mentor character as players can make the decision to complete their training.

One of my planned scenarios involved players accepting a quest to supply the Library with paper and ink which would allow them access into it and then eventually reach the Catacombs. The Library is still in progress but I'd like to use it as a place where the player can research recipes, create ideas and discover additional information to help progress.
I'd envisioned the Alchemy Guild to be a place where players could find jobs but also as additional source for recipes and ingredients.

I'm still considering the usefulness of the Library and Alchemy Guild as sources of recipes and quests as I've yet to include a quest system and I'd like to design and implement a slightly different synthesis system I have place holder events associated with these places but I'd like to do more with these places in later iterations.

Synthesis
I'm still having problems working out how to deliver recipes to the player. Leaving them lying around for the player to find is rather lazy method and doesn't guarantee the player will find it. Shopping for recipes isn't too bad but I have to ensure the player will want to earn enough money to purchase said recipe.

I could script additional events where players get clues from characters and then "find" the recipe in a location but that's rather boring and doesn't achieve much. Quests are a better solution as it involves getting the player to play and gives them a goal to work towards.

Recipes and item creation taps into a need to create and collect everything but it doesn't encourage experimentation or exploration as well as intended. I'd like to develop a synthesis system that encourages players to experiment with item creation by just combining items together and coming up with interesting and strange combinations.

Rather than punishing the player for experimenting, I'd like all combinations to return a result even if it's just something like: "You made a strange gelatinous mess...." which the player could then use to make glue or some other product. Finding uses for all these items may take some time but it could be done with careful planning.

I'd still like to incorporate recipes and ideas into the system which would lead to players having an understanding of what items can be made, the possibility to make recipe variants and the development of clues that would lead to expanding their knowledge base.

In my head, ideas would take on the form of notes. For example: if the player reads a book on herbs, they could then choose to research an idea for a healing balm and then experiment with that idea.

I'd also like to incorporate interactive process into the synthesis system much like the support systems for Pokemon contests found in more recent Pokemon games. For those unfamiliar, players can create items that increase particular stats of their Pokemon. To create these items requires work from the player, you can see the creation of Pokeblocks and Poffins to get an idea.

The creation of these items is rather challenging and your performance affects the quality of your produced item. I think processes like this would inject additional gameplay into this design and induce the player to become more involved. It's also a gameplay feature that involves the player's developing strategies to maximise their result and experimenting with ingredients.

Capping Off
I've learnt that I am still making similar mistakes across the two prototypes but there's still a few more ideas up my sleeves. I'll be taking a step back and going over both my prototypes, ideas and trying to work out a cohesive design that is more interesting to me and utilises some of the changes I've outlined in this post.

I'll be discussing these changes and a good deal more with my fellow designer Jasmine so watch this space as we game, game, game.

Game, game, game: Alchemy - Prototype I

Note: I've been busy so this entry is about a month old. Pictures enclosed in this entry are © their respective owners.

Premise
The Atelier and Mana Khemia series, JRPGs by Gust, feature an item creation system that I found interesting so I decided to find out if it could be implemented in a causal game. Why take something from a JRPG and see if it functions in a casual game?

The part of the game that interested me was this item creation system and I wanted to see what happens when you separate it from the other gameplay mechanics and systems. What I have learnt is that I can't completely separate it from all the other systems and that my original perception of what made it fun was flawed.

This perception was derived from how much I had enjoyed using it to customise particular items and discovering new items. Discovering new items and improving old ones gave me a sense of achievement and I wanted to replicate this sensation. I'll go into why I'm finding this perception flawed later.

There have been changes to the system over the games but I'm just going to discuss the general features and functions of the system.

Synthesis
These Gust titles use the premise of the player as alchemist and allows them to create a range of items from weapons and armour to healing and support.

The player has a home base where they can create their items (synthesis) and receive tutorials for item creation system.

The player needs recipes to create objects. Recipes can be found, bought or received during quests, boss battles and events. Characters will suggest variations or provide recipes when the player creates a particular item.

Ingredients are sourced through exploration of maps, shopping, enemy drops, stealing, conversion of enemies into items and synthesis.

Creating an item requires the player to have the necessary ingredients as specified by the recipe but substitutions can change the item's quality or produce a recipe variant.

Take the item Flame which derived from the recipe "Bomb" which the system changes based on particular ingredients.
Flame ingredients :
- Canone Rock
- Polish Powder
- Nicro Cloth
Bomb Ice ingredients :
- Glacier Stone
- Polish Powder
- Clearwater
Thunder Rod ingredients :
- Thunder Stone
- Polish Powder
- Legien Steel

Substituting the item Canone Rock creates two deviated recipes, Bomb Ice and Thunder Rod. The created item also inherits attributes from the selected ingredients which can determine its usefulness to the player. For example substituting Polish Powder for an more explosive ingredient has the potential for making the bomb better.

Initially the item Flame is made with no attributes but eventually a Flame can be made with the attributes Range (S) or Range (L) that help in battle or attributes that lower the cost of creation. Here we get to the crux of how this system works, the game encourages players to customise ingredients and items where possible so they receive more benefits.

Item quality is a factor that varies between the games but it can affect what attributes are inherited, occur during synthesis and NPC reaction to item dependant on how they interact with it. Some games featured quests where NPCs would request items with particular attributes and shops where players could sell items and item quality would affect the shop's popularity.

Brief Analysis
I happened to find it enjoyable acquiring recipes, testing them out and then trying to search for variations to create. It is a deceptively relaxing to swap ingredients in and out and review the results. I fell into part of the trap that this game system creates for players; working to create items that max out player benefits, which in essence is play as work.

As a JRPG, these games use the conventions of "grinding/levelling" to encourage players to keep playing the game. Seeking out enemies to fight generates money and ingredients which can be used to buy and create items. Fighting is also part of exploring maps and gathering ingredients as enemies can get in the way of exploration. Taking on quests provides extra monetary and item rewards.

Gameplay is limited to cycles resembling the following: gather & explore -> battle -> synthesis -> gather & explore -> battle -> synthesis -> battle -> complete storyline -> gather & explore new area ->synthesis. Keeping the cycle going rewards players with better items and equipment, provides the incentive to play and makes the player spend more time in game.

I decided to test what happens to gameplay when the battling mechanics are removed, I was presuming the game would become a more relaxing experience with the player being free to explore and decide what they wanted to do. Would removing the main incentive for item creation still give the player enough motivation to play the game?

The Prototype
I started out with this concept:
Sandbox style game where the player can collect ingredients from the "wild" or from their own managed supplies (farm). The collected ingredients can be sold or used to make items. Items can be sold for greater value or used by the player. Creating more items can lead to opening up new areas, more "recipes" or power-ups for the player.

Note: I didn't get a chance to get play testers but the following are reflections and thoughts about where to go next.

Initial Test Aims: To construct a working prototype that can test forage and synthesis (item creation) systems. It must also be built so player constraints can be incorporated. For this project, I've defined player constraints as variables that I can manipulate to change player behaviour and gameplay.

Based on similar games and systems, I decided to limit the player's action to the following:
- Create items by mixing things together
- Forage for items

I started out with RPGMaker VX as I could quickly produce a working prototype without having to create various systems from scratch. The prototype's synthesis system is the Actor Item Synthesis system © Yanfly and is demonstrated with this video. It requires players to either find or purchase recipes which dictate ingredients and amounts required to create newer items.

I encountered a lot of problems with the set up and the functionality of the prototype which makes me wonder; am I going about this in the wrong way?

Direct vs Indirect Instruction
The prototype doesn't have any instructions or tutorial as I was trying to figure out the best balance of work and enjoyment. I did realise that having no instructions gives the players no indication of what they can do, which leads to entrapment in uninteresting experience.

Take the above image, all the elements here could just be for show. There's nothing to indicate that you could do anything with those turnips or the well unless you try and interact with them. Nor is there anything that suggests "You're an alchemist".

Ideally any game should deliver enough instruction for the player to become acquainted with the system but not enough to hamper exploration and experimentation. Exploration and experimentation are experiences that I want players to desire and achieve with this game but I need to find ways of delivering this without loading too much information onto the player and avoid patronising them.

Teaching the player how to play through play and fulfil an objective, aids player engagement without them having to breaking from continuity and engagement. It's a technique I've seen in various games and it is pretty effective at teaching them to play the game but also allows for any extra content (subtext etc) to filter through to the player's head should your game need that kind of thing.

Visual cues, interaction and feedback
Item gathering is one of the key mechanics in this design – it’s the main method to get enough items to create different and better ones. I set up two different variations on item gathering feedback. Both require the player to press a key to pick the item:

One with a visual indication but no text response. To be most effective, this method requires creating assets for each different pickup and using a generic asset can be confusing if there is no indication of what that asset is especially if items are randomised.

The other with only text response. This requires players being able to identify which objects to interact with and requires additional work (one has to press a button to proceed with dialogue boxes in RPGMaker). I also think it makes it a little obvious when it's clear what one picks up but does have a distinct advantage for communicating the contents of a random pickup.

I had these running on different kinds of items but I'll be combining the two so pickups are consistent and prevent random pickups from being confusing.
I set up a prototype that has a "home base", where the player can synthesise items and places to gather ingredients. The immediate concern with having a home base is unless the player is instructed on its use, they'll need to figure out how to use and trigger anything or everything. Item creation is trigged by interaction with the fireplace.

The fireplace doesn't have anything to distinguish it as an interactive item or clues to its purpose. If I wanted to, I could evoke and manipulate some fantasy tropes like a witch's cauldron which would induce some players to start making assumptions about the game and its mechanics. Having the object indicate that a button press will trigger something is surprisingly a simple and effective solution to increasing useability.

Even the recipes that can be picked up aren't very obvious so I'm not getting the player to realise that these are necessary to the game. I'm thinking about alternative ways of delivering them while I test if the current synthesis system works with any changes I make.

Player Agency and Incentive to play
The incentive provided by combat in my studied models compelled players to customise their equipment to their advantage. The creation and testing of this prototype has shown me that incentive valuable to the player experience but that the combat system is a variation of resource gathering.

Players battle because it earns them experience points, money and the chance for items. These rewards can then be used to buy and synthesise ingredients and items, increase player stats and abilities and progress the game's narrative through boss battles. Boss battles can also unlock recipes, bonus items and additional content.
The Gust gameplay cycle demonstrates how all the individual systems interrelate to each other. The advantage of this kind of system is that the effort expended goes into advancing player progress of the whole game, not singular systems.

The actions available to the player in the prototype only exist to support and fuel the synthesise system. You need to find items and recipes to synthesise but synthesis doesn't make exploring and item gathering any more interesting, nor does it give any additional bonuses. The prototype is extremely limited in what it offers players and that is rather frustrating for players and myself as the designer. So how to solve this problem?

I could solve this by using a similar system to Markus Persson's Minicraft, where the player creates equipment and items to help them explore and survive the world. The player also collects ingredients to make better equipment. All systems are interrelated and support the player's goals by encouraging the player to use the other systems.

I'm disinclined to include a battle system as I think can require a lot of unnecessary work for the player and diverges from the relaxing casual experience I originally envisioned. I do think that I need another system that can be used in conjunction with the others to provide players with variety of allowable actions but also contribute meaningfully to gameplay.

Should I introduce a levelling up system to test and establish player agency and gameplay? While I think it'll be interesting to compare versions of the prototype that have or lack a levelling up system to see if gameplay and player agency differs, I doubt that will make improvements unless I can find a way to integrate the multiple systems in a meaningful way.

Some possible methods include:

1) Point based level system
Synthesising items will earn the player points and then level up when they earn enough. I'll be interested in seeing how varying difficulty levels and level caps will influence gameplay.

I could do something like the above where the player character comes up with additional recipes once they've reached a particular level. Although this does gives player goals which they can aspire to, it can result in players losing interest once they reach the highest level or requires a difficulty curve so that progress is spaced out.

2) Unlockable achievements
Instead of levels, I'm could see if offering players the choice to choose their own objectives accessible via a menu or list. Players will receive a bonus based on the achievement unlocked. Better prizes are awarded for achievements that are unlocked. This system also suffers from the need to design difficulty levels.

Neither of these systems are interesting as they make playing the game more chore-like than I or some players would want. These and the existing systems in the game don't offer emergent gameplay, are too passive and don't allow for any variation. Achievements and levels require a lot of planning to set up and maintain, I'd have to spend a lot of time testing and ensuring gameplay and difficulty balance. To solve this dilemma, I'm going to try integrating some systems that require more active participation from the player but also encourage different means and options for resource gathering.

These implementations should offer various game play choices and styles, the player would have more control over their actions with the use of strategies and experimentation and allows the game to be more free-form. Inspired by Minicraft and Harvest Moon (a Japanese farm simulation RPG series), I've decided I'm going to be testing:

- The creation and use of exploration tools
The player can use these to explore areas but will need to make these tools to gain access to higher quality materials. I will need to decide if tools can be upgraded or if they will break over time. This will also involve having to design environments that will support I'll start off with some basic tools like an axe, pick and a hoe and see if there will need to any more.

- Farming crops
Originally I intended for the player to grow speciality plants in a greenhouse and some crops to support their income and allow them to manage their own supplies. I didn't implement it in the prototype due to time constraints but I'm going to be trying a farming system in my next iteration.

Harvest Moon features a few interesting things that I think will work well in this prototype. The game featured seasonal crops but also crops that can be harvested multiple times during a season.

The shape of your crop formation is important as players have to water crops everyday to ensure a successful harvest. The shape is determined by the player and they must plough the land before planting. Things to consider when farming, the player has to be access all plants to be watered and harvested. Strategies for farming do vary but I've taken some of the basics from a guide for the SNES edition of the game.

Viable Planting formations for Harvest Moon:

Information © The Admiral (Admiral1018@yahoo.com)

A costing and revenue guide for various crops and planting formations:

Bag refers to seed bags that one purchases to sow crops on their farm. Information © The Admiral (Admiral1018@yahoo.com)

Harvest Moon is an appealing model as players have to manage their farm to maximise the benefits of crops grown by strategising how crops are grown and which ones are more cost effective. I'd like to add favourable and unfavourable conditions to planting, I'd like to test out parasitic and symbiotic plant relationships and plants that grow under particular conditions.

I think it would be interesting to see if players would be open to having plants that grew better when next to others and having a variety of places to raise crops. I'll be interested in introducing seasonal plants and items that can be foraged for which may introduce some limitations and decisions about synthesising particular items using the ingredients or selling the items for a quick buck.
I also be interested in observing if plant life cycles have an effect on gameplay and seeing if other styles of gameplay can be achieved based on test player behaviour.

Problem Solving
Analysing my prototype has uncovered a lot of problems that I'll need to solve. The next batch of problems I need to solve are:

- Teaching the player the game's systems
I'm going to try to implement a method that teaches the player how to synthesise by making it an objective. I may have to walk the player through the system or find a compromise that doesn't involve force feeding the player instructions.

- Establishing rewards for playing
Players should get some kind of reward for playing so they receive a sense of accomplishment but also feel that every (or most) actions they do will aid the completion of their goals. Player goals can be something like "finishing the game" or "purchase X item/upgrade" and time spent in the game should be getting them closer to the goal. Bonus points if it gets them to spend extra time in game but also lets them unlock additional content.

- Set up a basic set of tools to create and use
To implement this, I'll need to make an environment that can be used to forage for items and edited so players can explore and carve out their own spaces like be able to choose to clear forest for more farm land.

- Implement farming capabilities
I'm going to start off with a farmable patch of land and see if I can get plants to grow and produce crops from seeds. I'll then try to introduce seasonable crops and plants that produce more than one crop. I'd also like to test if plants should produce seeds at the end of their life cycle or should players purchase more seeds to replace plants.

- Make it fun
The hardest part of a game designer's job; I'll have to think of some ways to work fun into this particular prototype. The design and prototype may need some subtext, art and narrative to flesh it out to get close to something that is fun.

Through writing this entry, I've learnt a lot about the problems of my prototype and devised some potential solutions. I'm still looking at how to ways to make this prototype better, it does appear that more thought needs to go into the whole design rather than individual systems. I may need to go back to the drawing board for a while before trying to implement and test if my improvements are effective. It's time for a little less conversation and a little more action.

Hot Potato 2.2

Uploading Hot Potato version 2.2, some minor tweaks made but perhaps some more work to do. Both documents are .pdf format.

Edit: Small tweaks now added to make these the final versions.

Design Document 2.2

Hot Potato Pitch

Tater Dev: Logo

A rough of the game's logo/cover.

Tater Dev: Player and World Interactions

In my previous post, I mentioned that the shape of Hot Potato's world plane and the controls are giving me some design headaches. It's a big problem to solve as the gameplay of Hot Potato depends on these two elements.

I'm going to be editing this on and off through out the week so come back and check it out.

The Problem:
Hot Potato's play mechanic is the player tilts the world and the ball moves according to the tilt's angle. By tilting the world, you're angling the ball so it falls onto objects to destroy them (score points). The tricky part is making this interesting and the solutions involve adjusting how player interaction is done.

Arguments on World Planes:

Notes:
The Rotating box(screen) is the easiest method to implement as it can work with multiple methods of level construction and 2D or 3D art. The player's view of the world isn't obstructed and game objects can be clearly identified. As movement is limited to left and right, the game might not be as entertaining.

Notes:
This rendition would make things more interesting as the player can tilt the world in more directions. This method can work with either manual level construction or procedural building generation. However the main issue with this method will be determining the maximum and minimum amounts of tilt the player can achieve and where the camera is positioned in relation to the ball.

Notes:
This curved shape would give the game an interesting look based on the camera's position. The amount of tilt and level of rotation is constrained by the world's shape. This world type would work best with procedural building generation.

Notes:
I once tried to explain this type of world plane to a friend using the 1st picture, instead it is best explained as being similar to some of the spherical levels found in the Ratchet and Clank series or Mario Galaxy.

Like the Cylindrical world, maintaining player interest will depend on the position of the camera. The camera position will determine the level of detail seen. Eg. A top down view will limit or negate the use of smaller objects such as crates. A zoomed in perspective would allow for more detail but can rotating and tilting a little disorientating for the player.

This method can work with building generation via scripts or manual placement. Manual placement would be dependant on the scale of the sphere, a larger sphere = more space to place objects.

GUI
Hot Potato has a minimalistic approach to GUI, it's a simple game and I see no need to make it complicated. The most important graphical interface the player will ever need is the ball. It's colour coded so you know just how much heat you're packing. If you need a refresher, it'll be in this previous post.

The menu will be acessed by pressing a keyboard button since trying to press an onscreen button would be a bad design choice for this game. Everything else is explained below:

Hot Potato v1.0

Here be the most recent version of the design document which still requires a lot of refinement. Time's a ticking, crunch time is fast approaching and I have very little to show for it. Cries of "FFFUUUUUUUU-" will be heard.

Hot Potato

Genre
3D Destructive Sandbox

Engine
Unity 3

Tagline
Hot Potato got Destructive

Premise
Violence and mayhem as a flaming ball rampages through a city

Setting
The game is set in a large cartoon world where the laws of physics border on the ridiculous. Collisions in the game will be overly dramatic and humorous; contact with the ball will result in flames and explosions. Gratuitous violence is to be expected.

Game Structure
Hot Potato is a destructive casual game where the player's aim is to destroy the city using a flaming ball. Each play session involves the player attempting to beat their previous score before the ball's flame extinguishes.

The world of Hot Potato is designed in a sandbox structure, this allows the player to explore and experiment. Hot Potato focuses on mindless destruction and violence for enjoyment.

The game has room for different environments (maps) to become available for players to download or unlock. These would extend gameplay by offering the player different scenarios and objects to explore and destroy.

Gameplay
The player manipulates the ball's movement by tilting the world left and right. The ball's trajectory is affected by the tilt angle; players can manipulate this to optimise gameplay.

The flame burns out over time and the game will end if the flame burns out or is extinguished. Quick reflexes are required to avoid obstacles found in the game; these could have an extinguishing effect on the ball's flame.

Points are awarded for the amount of destruction the ball causes. Destroying and exploding objects will fuel the flame which aids in the destruction of objects and prevents the game from ending prematurely. The size and temperature of the flame will affect its destructive power.

Controls
Players control the game world via keyboard, the amount of tilt is determined by the duration of the key press. The world can be tilted in 8 directions (X and Z axes) to a maximum of 40°.

The angle and speed of tilting will affect the ball; the player can judge the timing and angle of their tilts to optimise the ball's collision.

Camera
The camera functions by scrolling with the ball, the camera will attempt to keep the ball centred on screen.

GUI
The GUI will only display the player's current score while the ball's current direction will be displayed onscreen as a moving arrow.

Ball
The ball is indirectly controlled by the player, its direction of movement is determined by angle and speed of the world's tilt but also by explosive collisions and obstacles.

Flame
Burns out over time but is fuelled by colliding with destroyable objects. The flame's colour is a visual indicator of how long it will last for. The colour will change from Red > Orange > White, with variations in between.

Flame Colour Chart: Left (Coolest) > Right (Hottest)
Warnings will appear if the flame is in danger of being extinguished.

As the ball destroys more objects, its colour will change to reflect its temperature. An object's resistance to the flame is determined by its size, type and material e.g., wooden objects are very flammable while vehicles require a higher temperature to explode.

The flame's size can increase momentarily when it collides with multiple objects or causes an explosion. Extra points can be rewarded if the flame flares up during these instances. Flaring up will cause the flame to spread out for a limited amount of time.

Collisions
When the ball collides with another object, it will either be damaged or explode depending on the object's size, type and material. A wooden crate will burn up but may explode if it contains explosive material. If the ball collides with a car, it could take repeated hits to explode the car.

Destruction and Explosions
The ball can destroy objects by burning or exploding them. Objects will add fuel to the flame while shrapnel can fly and damage other objects. Points are rewarded for the number of objects destroyed and additional points can be rewarded for explosions that occur during the destruction.

Explosions will fuel the ball's flame for longer and can cause chain reactions by destroying objects caught in its radius. Based the size of the explosion, the ball can be propelled in certain directions. This can be advantageous to the player as they can use it to navigate around the game or reach more objects.

Debris and Flying Objects
When an object is destroyed, there is a chance that it will break into debris or fly into other objects. Bonus points can be earned if the debris or object destroys nearby objects.

Barbequed, Gore and Ash
If the ball collides with flesh based creatures, there is a chance they will become barbeque or ash. Bonus points are rewarded if the player barbeques a large number of creatures. Gory collisions can occur if the creatures are hit with debris or flying objects.

There is the random chance that a pile of ash could become a zombie, points are rewarded if the resultant zombie is killed.

Demolition
Buildings can be destroyed over time by multiple collisions with the ball or during multiple explosions. Large explosions are more likely to destroy a building than smaller ones however small ones could be chained together to topple a building. A building's resistance is dictated by its size and function; a shack is much easier to destroy than a bank.

Destructible Objects
-Cardboard Boxes: Standard fuel that can be found anywhere in the world. Will burn but not explode or burst into debris.
-Wooden Crates: Has a low chance of exploding and breaking into debris. This will provide the ball with a moderate amount of fuel.
- Packed Crates: Wooden crates filled with miscellaneous items, some of these have the potential to explode.
- Metal Crates: Depending on the size and flame temperature, these can be difficult to destroy. These have a random chance of exploding.
Fences: These have varying resistance to flame, a concrete barricade can be used as an alternate pathway while a wooden fence would be fuel.
-Signs: Objects that provide some fuel for the ball, these are more useful as flying objects depending of their size.
- Traffic Lights and Street Lamps: The light and pole can be destroyed as separate sections resulting in more points.
-Trees: Will burn down and fuel the ball for a long period of time. Can be used to crush other objects in the world.
- Telephone and Electricity Poles: These have similar function to trees but can cause more destructive effects like electrocution and electrical fires.
- Oil Barrel: Will explode upon contact, the hot oil can cause a flare up and burn nearby objects.
- Gas Cylinder: Will explode when broken open, the amount of damage is determined by its size. This can cause chain reactions.
- Acid Container: When this explodes, it can spray acid everywhere. This can be used to erode surrounding objects and injure nearby creatures.
- Bombs: Explodes upon contact, can cause multiple explosions and destroy buildings.
- Trashcans and Dumpsters: Colliding into these will cause an eruption of garbage which can then be used to fuel the ball.
- Vehicles: Can explode with direct collision with the ball. A larger vehicle is more likely to be burnt and flung around the world during collision or if pushed by an explosion.

Fleshy Creatures
-Humans: Two legged creatures that will run away from destruction and explosions. They can be hurt in numerous ways; points are allocated based on the death received. Additional points can be rewarded depending on what human is killed. E.g. A civilian is worth less than a Santa impersonator.
-Animals: Creatures that have the random chance of becoming barbequed if they collide with the ball.
- Zombies: Arises from the ashes of killed fleshies, can be killed for more points. These will attempt to consume any fleshies nearby.

Obstacles
Obstacles can be broken down into various types that have an effect on the ball or its flame.

Air
If the ball is left in contact with these types of objects, its flame will be extinguished over time however these objects can propel the ball into an ideal direction. The player can prevent the flame from being blown out by tilting it away from the air flow.

- Fans: The size of this obstacle will indicate the strength of the fan, larger fans can push the ball away and lower the flame's temperature. A high temperature flame can destroy small fans but not industrial sized ones.
- Air Vents: The ball can be pushed in the direction that it faces however the flame can be reduced to Red if encountered.
- Wind Turbines and Wind Mills: These can push the ball back a long distance and blow the flame out.

Water
The majority of these obstacles will immediately douse the flame causing an instant game over. The player should avoid these.

- Puddles: Will lower the temperature of the ball and reduce its flame with prolonged exposure.
-Ice: This will melt when in contact with the ball's flame and the resulting water can extinguish the flame.
- Hoses: Can produce pools and streams of water that will put the flame out.
- Sprinklers: Produces a moving stream of water that the player should avoid.
- Pools: This will extinguish the flame immediately upon collision, these will vary in size.
- Fire Hydrants: Will produce a jet of water for a long period of time if the hydrant is destroyed.

Mineral
Prolonged contact with these can snuff out the flame and slow down the ball's movement. Tilting the world can shift the ball out of these traps. These traps are ranked by the rate they impede the ball's movement starting from low - high.

Dirt, sand, mud, slime, quicksand

Chemical
These obstacles can fuel or extinguish the ball's flame, a logo distinguish these obstacles from destructible objects. Extinguishing effects will be marked by a countdown

- Fire Extinguishers: Fire extinguishers can put the flame out momentarily dependant on its size in relation to the ball.
- Liquid Nitrogen: Will immediately extinguish the ball upon contact.
- Oxygen Tanks: Contact with these will enable the player to have a prolonged flare up for a set amount of time.
- Bicarbonate Soda: This can extinguish the ball upon prolonged contact with the contents of its container.
- Flour: Sacks of flour become explosive upon contact with the ball and can obscure some of the surrounding area from the player's view.

Physical
Physical obstacles can be used to negotiate the ball around other obstacles or to travel further across the world. Unlike other objects, these are inflammable.
- See saw: These react to the ball's position along the see saw's beam and can be used to reach higher ground or as a destructive tool.
- Conveyor Belt: These can be used to transport the ball over unsafe obstacles, reach higher locations or holds destructible objects. Conveyor belts can go in any direction.
- Cannons: This can be used to shoot the ball across the map, the distance and angle of trajectory is random and cannot be controlled by the player. The ball can set off loaded cannons to destroy nearby buildings.
- Catapults: These will fire the ball over a set distance in a straight line.
- Weights: These can extinguish the ball's flames or be used to crush nearby objects and buildings.
- Lifts: Will move any object up or down.

World Construction
The environments of Hot Potato could be manually constructed or via procedural generation. Both methods would provide sufficient game play for the needs of this project however these methods will have an effect on production.

Manual Construction
This method is more time consuming as the design of the level is integral to providing the player with challenging and enjoyable gameplay. The level would be a closed "arena" which has the potential for the player to encounter every object and obstacle possible. To prevent a premature end game, objects would respawn over time allowing the player to continually destroy objects.

Pros:
- Can customise sections of environment for more interesting player experiences
- Opportunities to create varied experience for player
- Gameplay can be varied based on size of level and types of environments
Cons:
- Level design and construction will be a time consuming part of production
- Challenging and enjoyable gameplay dependant on level design

Procedural Generation
An environment created from this method could be a continuous level which would force the player to keep moving the ball in search for more destructible objects. Procedural generation would provide endless gameplay but it does limit the gameplay to "mindless" destruction and avoidance of obstacles.

Pros:
- Level construction done through code
- Continuous game mode suits gameplay
Cons:
- May be difficult to implement
- Object and obstacle placement dependant on code, random results may occur

Scripting

Game Control
- Tilt using keyboard
- Roll Ball

World
- World Bounds

World Construction
- Procedural generation of objects

Ball
- Ball movement

- Collisions
-Identify type of object
- Increase/ Decrease flame
- Score increase

- Move ball

- No of explosions
- Add bonus
- Flare up

- Flame
- Decrease over time
- Reach 0, end game
- Temperature (HP)
- Colour
- Flare up

World Objects
- Collision detection

Destructible Objects
- Collision detection
- Destruction of object
- Replace with destroyed instance if necessary
- Explosion generation
- Movement
- Action/Animate

Obstacles
- Collision detection
- Action (what to do when ball collides with it)

Problems

- No mention of particle systems (Argh, an oversight that must be corrected)

- Scope is fairly large
I may need to reconsider cutting out a lot of the obstacles and fleshies. Fleshies will probably need to be scaled down to something that can be textured differently and zombies and animals will get cut out.

- Control system needs refinement
I need to clarify how the player will play the game and it will be difficult to plan until prototyping demonstrates what will work.

- World Plane
This and the control system will be discussed in a later post. It hadn't occured to me until a good friend pointed it out.

- Collisions
I have yet to consider how the code will identify what sort of explosion/action to take when the ball hits an object. Need to learn some physics, Newton strike me down now! I need to define if the physics in the game will be realistic or cartoony surrealism. Take the case of liquid nitrogen and fire, you'd want the ball to ice up but it won't. Instead the liquid nitrogen will extinguish the ball by reducing the amount of oxygen present. It is explained here in this long video.

- Art style
Where the hell is it? Instant fail.