This is the second of a series, here is Part 1.
After Heroes of Arcadia Beta 1 (Sept 2007), it took 13 months of development to reach Beta 2 in October 2008.
Towards a Story-driven RPG style…
We remade the game, essentially, in a lighter, more streamlined single avatar model where story counted for more and resource management for less.
Instead of requiring the player to manage the whole village concurrently, by default we focused on a party of adventurers led by a single Hero lead character. The village became an NPC faction managed by the AI but allied to the player, that serves as the backdrop to scripted interactions with NPCs, each leading to quest sequences.
Scripted Content
The scripting itself is one of strongest innovations in the Arcadia engine. It supports a Domain Specific Language (expressed as a fluent API) for describing the logic and content that drives character interactions and game quests.
This language is encoded in a sequence of executable objects that are run in response to event triggers that fire within the Arcadia world model. Script objects are also Serializable, so they can be saved to- and loaded from- both the downloadable game package and the mobile device’s memory.
Single-Avatar Control
During beta 1, while watching play-testers try to play Arcadia, I observed a key problem that turn-based games with many concurrent avatars suffer from. The more avatars that a player controls concurrently, the longer it takes to take a full turn among them, and thus the slower of overall game goes.
So the intended reward of growing the number of units under player control can in fact become a curse, because the per-turn effort to play becomes unsustainable.
Our response to this challenge was to introduce a simple level-of-detail system into the player interface, so that they could switch between
- Quest Mode: Controlling just their Hero, with the rest of the party running in an automatic “- Assist Mode -“, but with the option for the player to manually control of other party members when desired.
- Tactical Mode: Controlling their whole Party in round robin fashion by default.
Removal of Resource Rules and Growth
We also removed the village operation, food production and human reproduction aspects of the game from player control. It just didn’t seem to fit in an adventure-oriented game where zones of in-world locations can be loaded into and out of memory, as the player travels through them.
If a player controlled the village unit’s, what would happen when his or her attention moves to another zone, and the village gets unloaded from memory? Presumably it waits fairly passively until the player re-enters the zone, at which time the player-aligned units indigenous to the zone re-join the player’s party. These are certainly big ideas to explore in a future game, but the the first release I wanted to keep it simple and focus on a small group of mobile adventurers.
Zones
Zones have been a key idea in Arcadia since the early days. Each is a named rectangular region of the game world, complete with inhabitants, quests and scripting, as large as can be comfortably fitted into the memory available to the game at any one time. Beta 2 saw us develop a robust method for traveling between them, while maintaining a history of past events previously visited zones..
Getting the player’s transition between Zones to work properly was some of the most difficult design and programming I have yet had to do in my career.The main challenge was determining what objects in the current zone’s World Object-Graph are player owned- and which ones are zone local-, and devising a method to separate them when a transition occurs. A transition can result in dangling references where zone-local objects (eg a monster) were referencing a player-owned object (eg party member), that was then suddenly removed. Ensuring such situations were handled gracefully was one of the trickiest problems.
Zone transitions also required:
- A PlayerProfile record to store the player’s current and on-going transferable state, including the Hero character and their traits, inventory and effects, all other party members likewise, XP and Monetary wealth, and the state of any active or completed multizone Quests.
- Re-combining the PlayerProfile and the incoming Zone’s local- objects when a transition occurs, by injecting the wealth, units and quest state into the appropriate points in the world Domain Model — though this is much easier than the extraction process.
- A reasonable process of logging and error recovery for the transition process, which involves 2 large -reads and 2 large -writes to the mobile device’s store, as well as a major memory reclamation and re-allocation, and is thus prone to failure.
Beta 2 Process
For beta 2, I again used something like a dozen workmates, friends and acquaintances who had expressed interest in the game.
As a general heuristic, I found that I tended to get good feedback from a given play-tester only on one release version / trial, though there were exceptions. Feedback fatigue seems to take place when you ask the same tester to evaluate multiple editions of the game, if they are at-all similar.
Something I tried for this release was a web survey form to collect responses, via SurveyMonkey.com. I felt the survey helped to harvest good constructive feedback, though observing people play your game, and listening to their verbal accounts of the experience, are probably the most important activities. I did need to remind people to complete the form though, and even then only about half filled it in.
The road ahead…
- Improving the experience in the first 5-minutes of the game.
- Popup tutorial/info boxes that teach the player the game concepts and interface unobtrusively as they play, drip feeding them enough info to progress without forcing them to learn everything upfront.
- A 60-120s scripted “Woodhaven Village Raid” scene at game start, which ends with heroine Eleanor hiding in the bushes from the raiding orcs.
- Better player character growth through expandable unit abilities, purchased from earned XP.
RSS Feed 
My Digital Neuron 