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.