Since this blog series is called "Magick Systems in Theory and Practice," I feel that I should talk about my own practice in terms of concrete design of magic systems. For the past year and a half or so, I've been working on a project tentatively (and perhaps temporarily) titled Arcana Manor.
For the sake of consistency, I'll reproduce some of the most recent design document, starting with the game's elevator pitch.
"In Arcana Manor, the player wields a uniquely immersive and symbolic magic system to defeat the demons of a surreal Gothic mansion and unlock its secrets. Arcana Manor is a ceremonial magick simulator with an elaborate system of gestural sigils, incantations, colors, and sounds that makes players feel like true adepts, not mere button-pushers.
The magic system has these overall goals:
• to let players feel like they are the ones casting the spells rather than watching a character cast them
• to allow players to express and re-configure symbolic ideas differently in order to warp and alter reality, i.e. the system changes and adapts to different players' behaviors and personalities
• to be learnable, in part, through experimentation and trial-and-error so that there will be mystery surrounding the system; while the system is rigorously rule-based, a part of magic should remain magical in the sense of unpredictable, hidden, and knowable only through direct experience.
The conceptual framework of the magic system is based on ideas derived from authentic mystical and occult lore, in which magic is a metaphor for the power of the creative imagination.
• Players cast spells through their mastery of arcane knowledge and the symbolic correspondences of ritual
Aleister Crowley, Liber 777: 'There is a certain natural connexion between certain letters, words, numbers, gestures, shapes, perfumes and so on, so that any idea or (as we might call it) "spirit", may be composed or called forth by the use of those things which are harmonious with it, and express particular parts of its nature.'"
When I first started thinking, working on, and blogging about Arcana Manor, Kevin graciously posted on the Gameshelf a quick synopsis from my home blog, http://www.designingquests.com. Early in the process of development and team formation, I also set up a wiki with the game's design documents and concept art. Much of this information is now outdated as the game's concept has shifted, but some of it still applies.
Arcana Manor started out as a prototype in the Unreal 2 engine, which consisted solely of a small labyrinth of rooms meant to convey a Gothic funhouse of strange winding staircases, treacherous platforms, and walls textured with backwards Tarot cards. The idea was to convey the experience of moving through an architecturally instantiated tarot deck in an action-adventure game with a unique magic system.
As I worked, it soon became apparent that creating a magic system from scratch within the Unreal editor would be extremely difficult. (The designers of Clive Barker's Undying actually did so, but only through a large team of artists, as well as programmers with expensive source code access--which costs hundreds of thousands of dollars per seat on the project).
So I decided to move to a less expensive and more flexible indie engine: the Torque Game Engine Advanced, a relatively cheap non-commercial license of which gives access to source code. The Torque Game Engine Advanced allowed me to create more customized levels with my own textures and 3d models, culminating in a 3d version of the kabbalistic tree of life, with the branches or sephiroth marked by appropriate Hebrew letters and Golden Dawn attributions of hovering major arcana tarot cards.
Arcana Manor didn't fully hit its development swing until I started using the gui editor to create my own custom interface for spellcasting. The interface that I developed reflected all of the theories that I've described in earlier blog posts about spell grammars and symbolic correspondences, and creating the interface actually refined these theories considerably. The player dials in a spell through a complex set of revolving tarot wheels derived from an Iphone interface, as well as a radial set of buttons distributed along a hexagram.
I like the look and feel of this interface because it conveys the feeling of the magic system that I'm going for, but there is little backend code to make the system work consistently as a method of spellcasting. Furthermore, the Torque gui editor is not very flexible, so writing such code was a maze of C++ modification and scripting, the cost of which far outweighed its benefits. (I also began an academic year of teaching four classes a semester, which brought my own game development to a temporary halt.)
Halfway through the following summer (i.e. this one), I switched to Flash because of its flexibility of interface development, and I starting learning GlovePie (a program for alternative input methods, such as WiiMotes, P5 Virtual Reality gloves, the Novint Falcon force feedback controller, and the Emotiv EEG reader). Flash development entailed study of Actionscript 3.0 using Gary Rosenzweig's excellent book Actionscript 3.0 Game Programming University. Anybody interested in a blow-by-blow account of my slow migration to Flash and GlovePie, as well as the current progress of Arcana Manor, can check out my twitter feed: @arcanamanor. I ended up separating the interface of the magic system from the background game, enabling me to focus on two-dimensional art assets and a gui with a working back end.
The current interface consists of a drag-and-drop set of tarot cards, gems, and Enochian letters that can be placed on three targets in order to form three-element combinations that constitute various spells. Most of my Actionscript 3.0 programming has focused on enabling the drag-and-drop functionality and developing a set of arrays that track spell input, store it in an array, and then matching each element of the array as well as the completed array against a database of spells. To make this work, I had to write a function to match individual elements as well as a function to compare arrays against a multidimensional array. My colleague in the DSU game design program, Steven Graham, generously helped me tweak and edit this code to make it fully functional tonight.
There is still a lot of work to be done to match up with the vision of multimodal input and corresponding multimodal feedback at the heart of this project. I've summed that vision up in a long series of design documents, which I will post in a subsequent blog entry, along with more videos, links, images, and descriptions. But I hope that this entry gives a taste of what I'm up to and how I'm putting the theory of magic systems into practice, one step at a time.
