tikkun
1.0 Abstract.
This project is another attempt to bring at least some of my varied interests and influences together into a coherent result. Some of these lying in computer programming and video games, the path seems almost predetermined. So I’ll be making a game. As far as a theme goes, my interest in religion and mysticism seems a good direction, primarily, my interest in the Qabballah. Of course, I want to do something visually interesting as well, and so for ground textures and maybe elsewhere I plan on using monoprints. Each of these elements I’ll discuss in greater depth following.
2.0 Introduction.
2.1 Style.
Needing a style for the game, for a while I’ve wanted to make a Zelda or Rogue-like game, and without getting too much into the differences between the games, I decided on using Zelda as my point of comparison. Visually, that’s closer to the look I’m going for, and the gameplay is much simpler and straightforward. This amounts to a simple animated player character walking around a series of rectangular rooms, very basic sword and shield combat with a series of enemies, collecting items and opening new areas progressing to a final showdown with the antagonist, ending the game.
Like Zelda, I want the game to be simple. This will allow me more opportunity to concentrate on making the game fun, and engaging. Likewise, the player won’t be troubled with learning a complex control scheme; the less between the player and the game, the more immersive the experience.
On complexity, something should be said. When I say the game is to be simple, what I am specifically referring to are the rules the game functions by. Zelda functioned by very simple rules, and given those, the game was pretty complex. Similarly, I want to get the necessary rules down to the bare minimum necessary for a rich and engaging experience.
For the visuals, I want a consistent approach. Texturally, the ground will be one of a series of monoprints which I’ve been developing specifically for this project. The prints are richly layered abstract pieces, flat patternless patches of colour, which I build with thin layers of textured colours. As I’m thinking of using vector graphics for the characters and objects in the game, keeping the two styles of graphics from conflicting with each other will be a challenge. Aiding in this, I hope, any vector graphics will be hand-drawn and then vectorised, rather than drawn on the computer.
2.2 Story.
Any good game needs a story, but the story doesn’t necessarily have to be complicated. Meaning, no complicated back-story is necessary. In this game, I’m basing the story on the Qabballistic creation story of tzimtzum.
In the beginning, the ain soph aur desired to create the world, but it existed everywhere and thus needed to withdraw its light from the universe and create a void in which to place creation. In order to do this, the ain soph aur created ten vessels called sephiroth. As ain soph means roughly “limitless light”, these vessels were unable to contain the light and shattered. This shattering is called shevira, or the breaking of the vessels.
According to this story, mankind’s purpose is to release the light trapped within the broken shards, the qlippot. This, then, is the goal of this game. Where tzimtzum is an allegory for the creation of the world, this game shall be an allegory for the recreation of the Tree of Life, mankind’s purpose. The recreation of Adam Kadmon, the primeval man, and finally, reuniting with the light of God.
3.0 Gameplay.
As above, the gameplay will be based strongly on Zelda. The player will explore an overworld, encountering enemies (which will be discussed later) and collecting items. The “old man” from the original Zelda will be replaced by a series of characters, possibly mystics, who will explain some of the mythology and help the player on his or her quest.
3.1 Items.
The primary goal of the player is to collect qlippot. These shards will be represented as tarot cards, which have accepted mappings to each of the paths on the Tree of Life (22 major arcana cards each map to one of the 22 letters of the Hebrew alphabet, and the 22 paths of the Tree of Life). These, along with 10 chalices (each chalice represents a sephira), will be what the player needs to acquire in order to recreate the Tree. In addition, of course, will be other traditional adventure-game types of items, like keys, swords, and armour.
In addition to their primary function, I am considering having the cards serve a secondary function, since I’m guessing the player will amass quite a collection of them during the course of a game. This is up in the air at the moment.
3.2 Gameplay modes.
I’m not big on games that have two or more different styles of gameplay, because one is usually relegated to a mini-game or a small part of the game; the sudden change invariably brings the player out of the experience. This is partly because the two aren’t balanced - one is the main gameplay, the other is a sudden interlude. Also, the control schemes are usually drastically different, and the new scheme is often harder to use.
That being said, there are two major parts to this game. There’s the game proper, which has already been described. However, merely collecting the qlippot isn’t enough - there’s also combining them to recreate the Tree. This being the purpose of the game, its interface will require thought. Since this part of the game involves manipulating items, the interface will be part of the inventory system. One benefit of this is ensuring that its control is something the player will be familiar with from normal gameplay - the commands should be similar, or identical, to those used to manipulate other items. Also, an inventory system is a standard feature of an adventure game - any player will be familiar with that, so the chance of it taking a player out of the experience of the game is minimised.
The way the combination will work is this: beginning from malkuth, the 10th sephira on the tree of life, the player will need to place chalices (sephiroth) and tarot cards (paths). At the outset, the player will only be able to place malkuth. He or she will only be able to place paths that emanate from a sephira that’s on the board, and likewise only chalices that have paths going to them.
3.3 Characters.
In the course of the game, the player will come across a small number of supporting characters. These will most likely take the form of mystics or possibly angels. The player’s encounters with these will carry the story.
3.3.1 Enemies.
The antagonists in the game need to relate somehow to the story. More importantly, there do need to be enemies. Since I want these to be a natural progression from the story, rather than a driving force, the “forces of evil” will be things brought to life or brought into existence by the qlippot, rather than antagonists also out to collect the shards. In effect, the player, by fighting these, will be releasing the light from the earthly husks. A mystical journey, after all, is not a competition.
So, ideas for enemies are golem-like creatures formed of clay, maybe living statues, and elementals. Fallen angels and Sons of God are also possibilities. Another idea I had would be using traditional demons or evil forces from Hebrew myth.
4.0 Implementation.
The first natural course for something like this would be to program it in C. However, that course poses several problems. Not the least of these is portability - the only C programming I’ve done was for Linux, and I know nothing about libraries or compilers for other systems.
4.1 Software.
As it’s very likely I’ll want to make this available online, a couple cross-platform options are available to me. Java seems a likely solution, but honestly I hate it. There are simply too many problems associated with it - implementation is finickey; it crashes far too often. Also, the Java virtual machine, by nature, is terribly sluggish. Two other options are Macromedia Flash and Director.
After some amount of deliberation, I chose Flash. With the possibility of online release, file size is of central concern, and .swf files are generally much smaller. My only concern is the lack of a Flash 6 player for Linux currently, but I can either write the game in Flash 5 or wait: according to the Macromedia site, a Linux Flash 6 player is in testing. A release is planned “sooner rather than later.” Considering the extended capabilities of Flash 6’s actionscripting, it looks like I’ll probably be using that.
5.0 Process.
5.1 Documentation.
In order to keep myself on track, and as a general aid to my process (for other projects as well as this one), I’m attempting to extensively document the creation of this game. Since nearly everything involved will be internet-based (right down to transferring files from one machine to another: it’s far easier than disks), the documentation will be web-based.
To assist in this, I’ve decided to format this proposal from the start in HTML. Using CSS, I can easily reformat it for the web or for print. And as it is written in HTML, I can add hyperlinks to newer sketches, current screenshots, and anything else.
Primarily, however, the process notes will be a separate page where I can put a link to each subsequent version, as I add functionality, with notes - such as a changelog, and ideas on what will be added or changed in the next version.