Chimera: Genesis and the Constructor

Since I graduated from SCAD I’ve been redesigning and programming the basic structure of Project Chimera. Since I haven’t done much updating on my progress since then, I figured I would give a simple explanation of the main structure of the program I’ve been writing.
There are two major static classes, one that handles the importing and functions for DNA, and one that takes the DNA and translates it into “physical” parts which each creature is built from. I named these two programs Genesis and Constructor.

Genesis takes XML files describing genes, creates Gene objects based on the XML information and puts them in a global collection of all genes. These genes can be selected and placed in a DNA array, either through predetermined or random selection, or by crossing over two DNA arrays. The DNA is then passed to the Constructor which creates Part objects based on the genes in the DNA array. Parts are then attached to a Creature object and the Constructor produces a new-born creature.

Chimera Reboot

A lot has happened since I completed the first iteration of project Chimera. Now that I’ve completed my classes at SCAD, I will be further developing project Chimera. I plan to rework the structure of the DNA and rewrite a lot of the code.

Features of the new version of Chimera include:

• More realistic genetic crossover
• Mutation
• Part size modification
• Color
• Interactive Animation

Training

I’ve come up with the absolute simplest way to implement a skill-based randomization for training. The function works as follows:

If a random number between 1 and 15  is greater than the creature’s current stat, that stat increases.

With this formula, it becomes less likely to succeed at increasing a stat the higher it is. It also creates a level cap at 15 because the highest possible “roll” is 15, which can not be greater than 15.

A more complex version of this training system could roll against the cumulative values of all stats, so that one creature could never have more than a certain sum of attribute points. Experience points could then be earned in battle which would add to the creature’s roll score, increasing the likeliness of gaining higher skill points in more stats.

From Here to the End

Ok, folks. It’s officially crunch time. The presentation of the completed project is next Tuesday. In my case this will be a relatively polished prototype of a single player version of the Chimera game concept. Here I will outline what I hope that prototype to include (in order of importance):

• Fluid Interface

I’m basing the interface around a radial theme, trying to make it feel like a scientific readout with information radiating out from each creature. To the right is the current prototype for the interface. I hope to get more polished graphics by the final iteration, but that is of lower priority than completing the flow of gameplay.

• Combat

Random combat without engaging animation is boring and impersonal.  As an alternative I will be emulating a typical Pokemon-like battle system. Creatures have a set amount of energy, determined by stamina, and each attack takes a certain amount of energy.  An amount of energy is regained every turn.

In addition to attacking, the player has the option to defend against the enemy’s next attack which will reduce the amount of damage sustained by a successful attack. Defending costs no energy.

• Training

This will soon get its own post, as I’m trying to come up with a training/level up system that doesn’t simply rely on gaining points that the player allocates to the skills they want to advance. Instead experience  earned in battle will increase the probability that a creature will gain a skill point when training a particular skill.

• DNA combination machine

Forced mating is a little risque…  Especially because most of these creatures look male. The solution? Artificial DNA combination. When you win a battle you receive a sample of that creature’s DNA. You can then take that DNA to the combination machine and combine it with one of your creatures to produce a selection of offspring.

• Parts variety

My goal is to have at least 4 distinct variations for each part set. I believe this will provide enough variety to make each creature look different from the next.

• Selective randomization

Eventually the creatures the player will be presented with will not be 100% random, but randomized from specific sets of parts that fit well together. This will also be used to provide difficulty scaling, as the initial creatures generated will have low level parts, and as your creature gains experience, more powerful parts will be used in generating opponents.

The Chart Must Flow

The first step I chose to take in improving the battle system was to design the interface. As you may have noticed, little to no care has gone into the UI if the previous prototypes. Now that I have a clear view of what the program will eventually require, I can tackle interface design. In mocking up the UI, I outlined 5 screens that the player will move through when playing the game: Select, Inspect, Train, Combat, and Combination (Select and Inspect may eventually be made into one screen if it feels more intuitive).

Though I’m still roughing out the design itself, I have drafted a new gameplay flowchart with everything the player will do in the final prototype, and which screens each activity takes place on. Interface shots to follow soon.