Saturday, February 18, 2012

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.

Tuesday, August 23, 2011

Flatpack World

The level builder has gotten bit of an upgrade since its last mention. Inicus' Tile Interpret system has been intergrated.


To cut down on processing time, it will only work on cubes that are selected with the level builder.


I have to recheck some code but you can still make non-retangular shaped buildings.


Particular walls on the buildings can now spawn props onto them. It still need some work as some walls have a tendancy to spawn props out of bounds. But media heavy and congested buildings are coming.


I'm working on a level now. It's still at grey box level. I'll be looking for test drivers tommorrow so if you want to give it a spin, come and ask me. (I learnt yesterday that System.IO.FileInfo.Delete is one of .Net features that aren't supported by Unity's web builds.)

Nag naggity nag

Some graduation house keeping. Thank you to those who did fill in the form that I emailed you all (unless your email broke then you are excused and should ask for an explanation) and those you did find some time to go over the docs with their game descriptions and crew details. You spared me some time.

So I'm going to assume you (who haven't gotten around to it) are happy with the details listed below:

- Contact Details (This is a spreadsheet with names and emails)
- Carrom
- Knight Marshal
- Canon Courier

If you have had other people working on your games, make some effort to credit them. If I haven't gotten your roles right, then fix it or tell me to fix it. I'm still waiting on images for the Graduate DVD book, my deadline for this is getting closer and I have a lot to do for Wreckless so any effort is much appreciated.

If you don't want to donate or participate in any of the fundraising for the End of Year show, then can you let me know. I need to get an idea of numbers so I can gracefully write a letter to Michele and Herman telling them that (potentially all at this point) Gamers aren't going to be doing anything for the End of Year show.

Here's some Mana Bar figures as from this document. The Mana Bar can hold up to 60 people.

Booking out the Mana Bar on the 22nd November (End of Year show night) will cost:
- $1000 bar tab (5pm - 8pm)
- $2000 bar tab (5pm - 12pm)

Booking out the Mana Bar for Friday/Saturday nights will cost:
- $1500 bar tab (5pm - 8pm)
- $3000 bar tab (5pm - 12pm)

Booking out the Mana Bar for Sunday nights will cost:
- $600 bar tab (5pm - 8pm)
- $1500 bar tab (5pm - 12pm)

- Between an additional $200 - 800 for food (depending on your choices for food)

If you don't get your Griffith email: there's some Industry thing that Griffith's holding on the 13th of September at the Ship Inn. You need to RSVP a spot via HERE. Not guarantee that you'll get in.

Sunday, August 7, 2011

Wreckless Conduct: Copy and Pasting Animations

Copying and pasting animations for the rigs in Wreckless now goes something like this:

For the curious, there are about 54 items in the current rig that are used to animate. With the tool, we only have to copy animations from 9 of these objects.

Open up unanimated rig.

Import the animated rig.

Find and select the animated rig's "Root" node. Then copy the animations from it.

Find and select the unanimated rig's "Root" node. Paste the animations to it.

As the script's not in control of importing the rig, I haven't added any capabilities to find and match names of the 2 rigs. You also have to copy and paste for all the IK handles and rig controls. This does cut down the process to about 1 minute so I can't complain. The best part, most of the work is done in 4 lines of code which look like this:

proc CopyKeys() {
string $sourceRoot[] = `ls -selection`;
copyKey -time ":" -option keys -hierarchy below -controlPoints 1 -shape 1 {$sourceRoot[0]};
}//END CopyKeys

proc PasteKeys() {
string $rootNode[] = `ls -selection`;
pasteKey -option replaceCompletely -copies 1 -connect 0 -timeOffset 0 -floatOffset 0 -valueOffset 0 {$rootNode[0]};
}//END PasteKeys

Sunday, July 31, 2011

Link Dump: Bits and bobs

Miscellanouse bits that I found interesting:

- Bioshock Pitch
- Orchestra treatment of Woven Variations from Journey
- The numbers of mobile gaming (for you mobile game devs)
- This year's GDC Game Design Challenge: Bigger than Jesus (Features Jason Rohrer, John Romero and Jenova Chen)
- Board Games with comedian Tommy Dean
- ABC radio on the changing shape of the Australian Games industry and new opportunites Download the mp3

Friday, July 29, 2011

Graduating with Griffith

If you're the kind of person that wants to avoid talking to people or queing up then this might be for you. I give you Griffith's online details about checking your graduation using the Griffith Portal. This feature will probably become available around Monday 1st of August. I'm sure you can always talk to Admin if you're not trusting of anything I happen to spout.

Wednesday, July 27, 2011

Wreckless Conduct: Debuggery

Unity
It has been a long time between updates but I spent a lot of it debugging my level builder and associated scripts. It contains less bugs than before and few more options.


This a quick tool that I wrote to make using Inicus' Cube Interpret System easier to use.
It snaps cubes (any prefab) to a sizeable "tile grid" (Wreckless uses 3x3x3 metre scale), lets you scale the selected items by the scale (+n in x,y,z) and lets you add a tag to the selected. Which is important so the Cube system knows what to turn cubes into.

Road Intersections can align (it's a little buggy) before they generate roads and there's highways happening. I will be working on getting ramps and barriers on those intersections up.

Prop Zones are little areas that will be scattered around the levels that generate props for you to crash into. It saves me time having to place the props in manually. There are a variety of options for how props are spawned inside the zone. It's still a small work in progress, I have yet to find an elegant way to code it.



Skybox Progression
Although it's not apparent, Wreckless is meant to be full of hive city environments so the skybox should reflect it. I dislike matte painting but it's just how I've decided to get something up.




A shot of an unfinshed 3D version.

If there are any artists around who'd like to do some modelling or matte painting, it would certainly save us some time and look 1000 times better. Feel free to contact me or Inicus if you want to work on a cyberpunk environment.

Mel scripting
I got tired of having to set up all my default scene cameras' near and far clip planes so I wrote a mel script. I could add more functionality to it but this is good enough for me.

I spent a lot of time on the break trying to script a tool that will copy animations from 1 rig to another. So far no dice. But hopefully I can get back into it once I've picked some brains of far more intelligent people than I.