Emergent Gameplay: Gamers Gone Wild

On 07.15.10, In Ideas, Video Games, By The Villain
One thing I hate about some games is their predictability. A predictable plot with bad guys stationed at predictable intervals leading to a predictable ending is downright boring. This boredom factor has been appeased with creative design and Game AI to a certain extent, but there is another more interesting way to play a game: try making your own plot, with your own mission, using your own creativity to go somewhere the game’s designers did not intend.

Here are 9+ fascinating examples showing what can happen with a little bit of imagination:

Alice and Kev

- Alice and Kev

was an “experiment in playing a homeless family in The Sims 3.” Interesting to watch the homeless try to get by in this virtual community.

- Space Ranger 2, Arthur Stone and the Rusty Nail

Instead of becoming a space hero by working his way up through the ranks, as the game was intended to play out, this guy decided to take a different path and destroy all the ships that outranked him. It wasn’t easy, but it worked!

- “Livin’ in Oblivion”

tries living as a face in the crowd as a Non Player Character, instead of taking the normal approach of adventure-seeker.

- Razorlength

A giant computer built in Dwarf Fortress. "I believe this is the first programmable digital computer that anyone has built in DF. I believe it is turing complete, for anyone who cares. - Jong89." More info is available here.

Dwarf Fortress Computer A portion of Jong89's working Dwarf Fortress Computer

- The Great Hogtie Massacre of 1911

(Red Dead Redmeption): There is plenty to do in this game, but why not do something out-of-the-ordinary and tie not 1, not 2—but 19 people to some train tracks.

- Creating self-replicating lifeforms

in Conway's Game of Life.

- Grand Theft Auto videos

Gameplay-turned-movies on Youtube. Here, here, et cetera...

"I have got to make sure that YouTube comes down to tape this."
- Michael Scott



- Brain Age Hacked

Finding new answers to age-old math problems. They have to be right--the computer says so.

Brain Age Hacked

- Fraud in Eve Online

This is just one example of the economy-gone wild of this game. Here's another.

Being able to go somewhere and do something unintended requires some ingenuity, but also enough depth in the game itself. Many games are so limited in their options that you simply can’t go anywhere with this; you must stick to the two or three options you are given because anything else will either kill you or break the game. But as these examples have demonstrated, crazy things can happen if you the game is deep enough and you are willing to think outside the box. I would love to know about other examples.

Stumbleupon Twitter Google Buzz Digg it del.icio.us Facebook Reddit Yahoo Buzz
Tagged with:
 
0 Comments
Leave A Response

Neural Networks

On 05.02.10, In Development, Ideas, By Pariahpism
Well hell, we're now reaching the point in The Project where not everything can be solved with some tangle of Genetic mishmash. I blame myself partly for letting my brain assume this for little problem’s answer. Now when we're actually figuring out the data flow, it's not nearly that simple. But the structure was good. We just need to replace a few things. Our DGP (Decision Genetic Program) had for me the problem of scope. We assumed complex choices could be evolved from the data passed to it from the EGP (Environmental Genetic Program), something that also evolved complex physicalities such as sight and color. The question that arose was, "When do these GP's increment their generation?" The GA does doing the Characters either Cross Over or Mutation. This would leave possibly the Characters blind, deaf (un-evolved sensing organ) and dumb (very poor/random decisions) for thousands of Generations. That would make things accurate...but very boring for something targeted to an audience with a five minute attention span. Problem: Too slow, albeit realistic. Solution: We could brew (literally) some templates to load into basic Characters. Sub-Problem: Things would still be slow to change. Likely the player would never know or see these changes. Sub-Solution: Unknown The alternative would be to let the two GPs increment Generations freely, once every cycle of the Game Loop. The problem here is that a Character could potentially change its entire advanced physical body and behavior within its lifetime. A Dear could suddenly act like a Wolf with the eyesight of an Eagle, if it saw fit (pun intended). This siphons both the realism and some of the static-ness of the game. Problem: Unreal and far too dynamic. Solution: Maybe a limit to the amount of Generation increments? Sub-Problem: Still fake and not addressing the real problem. Sub-Solution: Unknown. I mentioned scope before as the source of the confusion. That’s because as a whole, The Project is a GA within a GP within a GP, each with its own population and fitness. The user only interacts with the outer most layer. Its population are the Characters that house the FFGP, the EGP and the DGP. The FFGP generates the fitness for the GA layer. Problem: We don’t know how to do this. Solution: Figure it out. The DGP takes the information gathered each turn, (Hungry = True/False; Sensing Organ = True/False; Bored = True/False; etc.) to make the choice (Move; Attack; Reproduce; Nothing; etc.). Problem: GPs aren’t usually used this way. The data sets are usually static and the program is left to evolve better and better ways. Solution: Maybe a GP could be made to handle each state and called upon only when certain states are true. Sub-Problem: This feels like micromanagement and could impede growth potential. Sub-Solution: Learn more. The EGP handles the advanced physical attributes (Sensing Organ’s attributes; Exterior Attributes; etc.) This should work as intended with a basic template. Simple a bunch or attributes being juggled for a fitness value. This could even be a GA unless I’m totally forgetting something. All that the DGP should do is making it seem like it could be a Neural Network. But we need to learn more about them before making any lasting decisions. Problem: If the EGP becomes a simple GA and the DGP becomes a NN (Neural Network) then we’ve removed all the GPs from the program that have a significant part to play. This kills a lot of the dreamt unknown potential from the game. Solution: Hmm.
 
0 Comments
Leave A Response

Defining Fitness

On 04.12.10, In Development, Ideas, Video Games, By The Villain
Keeping Fit What we have so far: Having a good definition of fitness is going to be crucial to our success with Alphabet Soup, and any of our games for that matter. So far we have only one fitness factor, a rather rudimentary "meatiness" goal: the more 1s, the better. Aiming for the maximum fitness of 1, we define an ideally fit chromosome of 16 binary "alleles" as 16/16 =1, or: chromosome = 1111111111111111 = 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1 = 16/16 = 1 = 100% fit. Anything less than ideal is given a fitness value such as 13/16 = 0.81, or: chromosome = 1111110111011101 = 1+1+1+1+1+1+0+1+1+1+0+1+1+1+0+1 = 13/16 = 0.81 = 81% fit. This is all very simple. Too simple. But it's a start. The question is, where do we go from here? In progress: The next step will be to include the schemata for the letters. Fitness will be a combined value of the "meatiness" and the "likeness" defined by a comparator function. Here is how it will all work: First we will have the letter genomes in the Binary Letter Library broken down and defined into the final schemata: charLine[0] = 0*****0000000000 ... lines 1 thru 14 ... charLine[15]=0******0000***00 Where there is a "0", the value is always zero--in any letter in our population. Why calculate that if it is never going to change? The remaining values then, represented by asterisks, will be either 1s or 0s, depending on the letter. The results of the GA generations will be run through the schemata, with the remaining asterisked positions matched up against the letters in the library. Matching to the nearest letter will be easy. Say there are 125 asterisked positions. After the first generation of GA takes place, the fittest-so-far (meatiest individual) is passed through the schemata. All zero-only spots (such as charLine[0][0], charLine[0][6] are dropped immediately. All asterisk "either-or" positions are evaluated. If charLine[0][1] is a '1', it is matched to all letters with a value of '1', and so on. The genome will then take the shape of the letter with the most matching values.... An important technical aspect of this that we have agreed on is to have the comparator only change the way the letters are displayed, while leaving their array intact--aside from the schemata. In other words, the original GA-defined chromosome/genome is maintained, while a copy of itself is stripped to be matched against the schemata. This allows it to maintain its evolutionary integrity with a level of abstraction so more fitness functions can be performed. I will deal more with this later. So how do we define the new fitness value, with both the schemata (likeness) and meatiness in mind? Here is a 5-step process that should do the job: 1. Take value of current generation individual. Let's use for genInd[5], say: 0000101011101110 2. Pass through schemata. Let's use generic letter line 5, which might be 00*****0******00, making genInd[5] now equal 0000101011101100 (the only bit that changes is the second-to-last one, because based on the schema that bit always equals 0). 3. Define "likeness value." For simplicity's sake let's use charAline[5] which equals 0000010001000000. For all bits of genInd[5] that match charAline[5], add a 1: So, comparing 0000101011101100 (genInd[5]) to 0000010001000000 (charAline[5]), and disregarding schemata characters that are always 0 (blue), we find only 4 bits that match (red), giving genInd[5] the "likeness" value of 4 as compared to charAline[5]. 4. Define the "meatiness value." To incorporate the "meatiness" factor, let's add an additional +1 to each value of matching letter that is, actually, "1" (meat). When we add up all the matching value of 1s between genInd[5] and charAline[5], we only get +1: 0000101011101100 compared to 0000010001000000. So, for this particular example, the meatiness value = 1. 5. Add "likeness value" and "meatiness value".To get the total fitness value, add the likeness value (4) to the meatiness value (1) for a total value of 5. Note: since this schemata line has 5 characters that are always equal to 0 (shown here: 00*****0******00), they are subtracted from the maximum fitness amount. So, the maximum fitness of this line is 16-5 = 11 possible values that match ("likeness" value), plus the possibility that all of those values are 1s ("meatiness" value), making the total maximum fitness of this line equal to: 11 (max "likeness") + 11 (max "meatiness") = 22. So in our example, 4 (likeness) + 1 (meatiness) = 5 was not all that great (5/22 = 23%). Other letters in the alphabet will much likely have higher fitness on this line. I think this will be a good way to determine total fitness--at least in early versions of Alphabet Soup. Future awesomeness: All technicalities aside, this is where Alphabet Soup can get really interesting. This will probably be around... version 3.0 or so. Right now, these are just vague ideas. Fitness based on letter shape was the original goal of Alphabet Soup all along:
"Hark! Here comes a second generation character, ‘i’, who has lost the vestigial tittle (the dot). Most other letters are unchanged or changed in a negative or neutral way. The lower mass of the ‘i’ makes it faster and take in less calories. Alas, it’s lower weight makes it do less damage and is losing ground to the dastardly ‘T’s and their hearty top most shield. Will the character genes be favorable enough to carry on or will they be lost and another random variation will make itself dominant. At the front of ‘i’s’ and ‘T’s’ war, a fork occurs with the ‘w’s. The ‘w’s strike fast coming down but their double point distributes the impacts, lessoning the effect on harder shelled letters like the ‘T'."
With this, things like food, environment and the ability to reproduce/fight/defend are all important. Another idea is this: fitness is dynamic, determined by the players. They change the landscape--by adding obstacles, giving new goals (such as winning a race, building a tower, et cetera). Different letters will be more suited to different tasks, so fitness will vary from task to task. This might keep it more interesting than if fitness was just based on one thing (like meatiness or shape). Also, on the note of shape mattering--maybe shape won't matter as much as far as fitness value is concerned, however shape may be important for movement in Farseer if we can get the physics of it right. So... if the goal is to get over a mountain or something, the shape and physics will be important to the letter's success, indirectly having an effect on the fitness anyway. A good comparison is to think of how to keep a Sim alive: by balancing a variety of values that are important to the character's success at staying alive, such as social value, food, health, activity, recreation, knowledge, and so on. Any of these kinds of ideas could be incorporated into the fitness value to make it more interesting and keep the player more involved in what is happening in the Soup. One important key to this is to allow the Evolutionary Computation to do its thing without interferring. If we can hone that delicate balance between the EC and the player-letter interaction, Alphabet Soup could be great. The future awesomeness of Alphabet Soup depends on our ability to come up with more fitness ideas, and to make them actually work. Other considerations: We have talked a lot about including sensing organs for letters to be able to interact with their environment on a biological level. Also in discussion are color values which may or may not be related to fitness, sensing ability, or overall health of a letter. We will have to deal more with these ideas and see what we can agree on. One thing we have reached consensus on is the level of abstraction that will be present in our final product. Overall, we are going to let the GA and GP do their things in a very precise way, keeping the Evolutionary Computation aspect as pure as possible--but this will all be going on behind the scenes. The precision in the background will be modified and "rounded" (such as with the schemata) before reaching the eyes of the player. This will allow the letters to maintain their forms, allow the Physics Engine to operate on fixed shapes, and so on. However there will likely be a more abstract level of EC going on as well, such as with the shapes present in the physics engine and how they react to one another. The more levels of EC operating within the game, the more rich the environment and the more capable it will be of surprising us. But we don't want the abstraction to completely cover up what is going on behind the scenes. One way to be able to unite the abstraction with the player's awareness of what is going on is through keeping a detailed history of each genome in the population. We should somehow tie the chromosomes to their respective genome so that the genome holds its identity and evolutionary lifespan throughout its own history. Maybe stamp each chromosome with some sort of hidden i.d. assigning it to its current genome. These generational histories will provide the owner of the letter with information showing how old the letter is (how many generations it has survived) and each detailed transformation it has undergone during its evolution to its current state. This could be useful for farming, trading or even--who knows--combat? Dog-fighting is illegal, but how about pitting our letters against each other? There are all kinds of scenarios and places we could go with Alphabet Soup. And as the creators of Dwarf Fortress believe, the more ideas we integrate, the better the game might become.
Tagged with: • •
 
0 Comments
Leave A Response

Character Collisions

On 02.02.10, In Development, Ideas, Video Games, By The Villain
The binary-bitmap conversion portion of the BBC has already been discussed and is in development. But there are many other aspects of this part of the program that need to be considered, including a physics engine and the motion of the letters. One thing that's been bugging me is how the letters will react when they run into one another. Let's assume that two letters, an 'A' and a 'B' are floating around in their predetermined environment. They run into each other--what happens? First of all, we need to clearly define what consitutes a character. There are 256 pixels in the 16x16 square, yes, but most of the border consists of '0's--white space. Is it going to be considered a collision when the outer white pixels of the bitmap collide, or are we going to go with a more literal description of the letters running into each other, i.e. the black pixels ('1's)? I think the second idea makes more sense, even though in computer logic the bitmap touches the other bitmap when the 16x16 squares meet, which causes a kind of predicament for us. The crazy thing about going with option 2 is that it will cause a morphing in the bitmap of at least one of the letters, even before the actual collision takes place. In other words, the 'A' bitmap will already change before the genetic code is activated.                     Purple shows changed pixels:                     0000000000000000                     0000000000000000                     0001111111000000                     0001111111100000                     0001000000110000                     0001000000010000                     0001000000010000                     0001000000110000                     0001111111100000                     0001111111110000                     0001000000010000     'A' bitmap becomes: 00000000000001000000010000     0000000000000100 00000001000001000000110000     0000000100000100 00000011100001111111100000     0000001110000111 00000010100001111111000000     0000001010000111 00000110110000000000000000     0000011011000000 0000010001000000                         0000010001000000 0000110001100000                         0000110001100000 0000100000100000                         0000100000100000 0000100000100000                         0000100000100000 0001111111110000                         0001111111110000 0001111111110000                         0001111111110000 0001000000010000                         0001000000010000 0011000000011000                         0011000000011000 0010000000001000                         0010000000001000 0110000000001100                         0110000000001100 0000000000000000                         0000000000000000 One way around this is to make the border '0's (white pixels) invisible, or transparent to the other letters. Also, we could somehow use them so that when the outer pixels of two letters collide, they activate some sort of "signal" (probably a specific function in the code) that a collision is imminent and that the decision-making procedure needs to occur. Maybe this could even change the white pixels to a different color as an extra visual aid to show that a collision is about to take place somewhere within the soup--a way to highlight the action. Just a thought. Before:                                             Collision Imminent! 0000000000000000                         0000000000000100 0000000100000000                         0000000100000100 0000001110000000                         0000001110000111 0000001010000000                         0000001010000111 0000011011000000                         0000011011000000 0000010001000000                         0000010001000000 0000110001100000                         0000110001100000 0000100000100000                         0000100000100000 0000100000100000                         0000100000100000 0001111111110000                         0001111111110000 0001111111110000                         0001111111110000 0001000000010000                         0001000000010000 0011000000011000                         0011000000011000 0010000000001000                         0010000000001000 0110000000001100                         0110000000001100 0000000000000000                         0000000000000000 The fight-or-flight function, another good chance for GP to help with decision-making, will then determine: Do I, as an 'A'... 1. continue toward the 'B' (attack), 2. change direction to avoid 'B' (retreat), 3. breed with 'B' (perform GA/GP)? The thing is, both letters will be running this function to determine the best course of action. It would be interesting in this scenario to see what would happen if 'A' tried attacking while 'B' decided to activate the genetic algorithm. What would happen? Who would win? Maybe the program would crash and we'd need to tweak it, but whatever--this is just a brainstorming session. All this can be figured out. I think the main problem with the white borders in a bitmap will be aesthetics: the collision wouldn't really look like a collision if just the outer empty sections of the letter boxes are running into each other. We can go with the highlighting/color-changing idea, or maybe we can implement some sort of overlap in the outer white pixels on the bitmaps to show more precise-looking collisions. The speed of the letter movement could also be enough to distract the user's eye from the extra white space. Then again, as small as a 16x16 bitmap is, the difference is probably subtle enough that it won't even be noticeable.
Tagged with: • • •
 
0 Comments
Leave A Response

Starting with Subclasses for Alphabet Soup, 0.01

On 01.24.10, In Code, Development, Ideas, Video Games, By The Villain
(Originally published January 10, 2010) Time to get some thoughts down on digital paper concerning the actual code for Alphabet Soup. For simplicity's sake, here are some more specific ideas: To stay close to the code in MSDN's ant program, we can start with a similar "ant" grid, allowing only up/down and left/right movements. This is not our "floating letters" environment yet, just think of it as a first step toward that. We also have to redefine what the classes are and where they belong. The "ant" class becomes our "alphabet" class. "Food" in our case should be redefined to individual letter "species." Let's start with Alpha, Beta and Charlie to keep it simple. So, while an ant in MSDN's program will encounter food along its path, any alphabet character will be encountering alphabet subclasses (formerly food) along its path. What the code decides to do results in whether the encountered character is devoured (or eaten, as in the original program), morphed, defended against or something else. So, the individual letters must obey the general rules of the alphabet class, but what they do individually depends on the evolutionary code that is run every time a collision occurs--and what happens should depend upon which letters are involved. I call this the ContactReaction() function. Here is a general framework: Alphabet class, stay with MSDN example, with adjustments: public Void Init(Cell[,] grid, int StepLimit, int SurvivalGoal) Move() function includes basic movements and the results of contact between letters, to call on evolution code: public void Move() {     if(NotFinished())     {         GetFacingCellCoord(outxLocation, outyLocation);         mTrail.Add(newTrailSpace(xLocation, yLocation));         mTotalSteps++;             if(mGrid[xLocation, yLocation].HasAlpha())             {             ContactReaction(Alpha) // calls function for what happens            when character encounters Alpha             // This will be where the evolutionary choice takes place,             well, part of it (see below)             }             if(mGrid[xLocation, yLocation].HasBeta())             {             ContactReaction(Beta)             }             if(mGrid[xLocation, yLocation].HasCharlie())             {             ContactReaction(Charlie)             }     } } Here we will place the evolution stuff--to include within ContactReaction() function: {     // (Define basic function here with evolutionary aspect,     including specifics for each letter (see below))     if(result=Devour)     {         mGrid[xLocation,yLocation].SetEmpty(); // this is as if the         letter eats the other character     }     else     {         (OTHER OPTIONS/TRANSFORMATIONS/EVOLUTION) // Run Generator code        } } The ContactReaction() function will involve a lot of tweaking in combination with MSDN's Generator class. It will call on the Generator class and expression tree constructors to perform the genetic crossover algorithms after every collision. The code for these can be found at http://msdn.microsoft.com/en-us/magazine/cc163934.aspx#S5 An important question... Generator and Expression Tree from MSDN look great for our purposes, but should we include separate generator/expression tree specs for each of the different letters? More specifically, how will the letter's shape have an effect on what happens in a collision? Should we define this aspect of it within the generator/expression tree? I think the best solution is to define those specs in our ContactReaction() function, meaning that function would have to be tailored to each individual character--but that way the generator/expression tree class can remain one and just be referenced by the ContactReaction() function--as I have shown above. So the evolutionary choice will still take place in the MSDN-defined classes, but each of the collisions will involve a "lean" toward reaction based on letter shape, as we define in ContactReaction(). This may or may not be the best solution, but it is a start.
Tagged with: • • •
 
0 Comments
Leave A Response

Alphabet Soup, 0.01

On 01.24.10, In Code, Development, Ideas, Video Games, By The Villain
(Originally published December 29, 2009) The Project still requires an immense amount of reading and research before it can produce much fruit, but there is nothing to keep us from starting with the basics (except of course the risk of extinction like everyone who has ventured before us). We obviously cannot do this completely from scratch, so to find out where to begin, we look to simple GP and GA examples. Pariahpism discovered MSDN's example program using ants to find the most efficient way to follow a trail of food in a 32x32 square matrix. The program uses C# in the .NET framework, along with Microsoft's System.CodeDom Namespace. Full source code for the example program is available here. Now, to apply the principles of the Ant/Food program to Alphabet soup, we begin by breaking the program into the comparable classes. I consider the User Interface a separate aspect of the program to be built later, but additionally there are two necessary sets of high level classes. The first set is the problem set, which includes the customized goals and limitations. Basically, these are the details specific to our program (letter class, number class, case class, goals, movements, starting population, and so on). While the article's program describes an ant following a path of food, Alphabet Soup will involve alphabet characters reacting to collisions with one another. A secondary but important aspect of this set of classes is a private method (or methods) included to record what happens within the program--the generational "history" which is saved to an array so the array instances can be compared for fitness level. This allows the program to use natural selection for determining "who" survives to the next generation--and, in the case of Alphabet Soup--what the future holds for those letters which collide, based in part on the fitness of past results. For the early versions of our program, the problem set and UI will take up the bulk of our customized coding. The GP framework, on the other hand, already exists more or less. It does still have to be customized as far as the variable names are concerned, but the basic set of code instructions will be very similar to what the article defines--especially if we create our first program in C#. In other words, the GP framework is a standardized code including the necessary algorithms for mutations and inheritance. At the core of the GP framework, the Ant/Food program uses the Generator class, which the article refers to as the "kernel" of the GP implementation. It does, after all, perform: "selection, breeding, code generation, execution, and result sorting." Something I've been seeing over and over again in GP is Koza's "tree" full of terminals and functions. For the ant program, functions include "FacingFood" and terminals include "Left" and "Right." For Alphabet Soup, let's use the examples of function: "CollidingLetter" with terminals "Avoid" and "Attack." Random expressions are created by the algorithm by combining available functions and terminals from the tree. For instance, "if CollidingLetter, then Attack else Avoid." These random combinations are weighed against a fitness measure (defined elsewhere in the program), which helps determine the outcome of the future generations. In following traditional GP, the selected alphabet characters (a certain percentage) are copied for crossover and reproduction while the rest are discarded--depending on how exactly we choose to do it. Again, this code should be easily modified from MSDN's version to what we need for Alphabet Soup. The article also addresses the role of mutation in the ant program. Mutation will be crucial to how Alphabet Soup plays out: "[Mutation] involves making a random change in a small number of offspring in order to maintain diversity in the population. Mutation is essential because otherwise the population becomes completely dominated by a few good bloodlines, which makes it difficult to continue progress beyond a certain point. [The Ant/Food program] performs a simple mutation step during the crossover operation to introduce randomness. When a terminal node is copied, a random terminal is substituted two percent of the time." So these are the basics of the basics to get us started. Another note to keep in mind is the usefulness of XML. The Ant program copies the ant path to an XML file which can later be reloaded. This may not have much use for the application itself, but it can be interesting for reviewing past generations and possible patterns/flaws/suggestions in the code. Also, check out another simple example in C.
Tagged with: • • • • • • • •
 
0 Comments
Leave A Response

Game Untitled

On 01.24.10, In Ideas, Video Games, By Pariahpism
(Originally published December 10, 2009) So my latest idea for a game came to me in the shower like all good ideas. I was trying to be less similar to the last few and was trying to do something in the same vein but exactly contrary. Mostly our idea is to use artificial evolution against the player and watch him struggle and die in varying degrees of difficulty. So my thought led me to attempt to think of a way for the player to be the one evolving. I've seen plenty of games that fake evolution. You can buy Evolution Upgrades that either improve you caprice shell or sharpen your pincers with evolution points. I want a game where the engine for evolution is your play-style. Let's say there are 10,000 in your herd of The DeathDinkles. They all do what you do in 10,000 similar situations. The only variable is individual strengths and weakness. You avatar only has the strengths; the best of everyone. You see a bear. Do you fight it, jump over it, climb a tree, outrun it, hide form it, ...etc? What you do determines which of your species lives or dies. Half of them have the strength to fight the bear and survive and only a half of them have the fortitude to stave of infection from the wounds inflicted. You could quarter your herd in one simple choice but the resulting herd would carry the traits needed to survive similar situations. The offspring of this herd would have children and a higher likelihood of producing mutations of increased strength, stamina, fortitude and disease tolerance. Pretty soon bears become your easy prey and staple food as was naturally selected (by you). The bears undergo the same evolutionary changes and maybe become faster and stronger, or maybe become lithe, agile and harder to see. Or maybe the fail as a species and go extinct. So your herd of tough brutes is having increasing trouble with the new agile b'ougars (bear-cougars) and have started to lose population. There are some mountain goats in the west mountain range that seem like easy prey. The high jumps of the mountains split your herd between those that have good balance, equilibrium and jumping strength. The split doesn't kill the other half, simple divides them into another species variant, The PrairieDinkles, while you become the MountainDinkles. The PrairieDinkles will continue to survive unassisted with an emulation of your behavior prior to the split. They may someday target you as a prey but completely unrecognizable as having a common ancestor. The mountain goat high rate of reproduction makes them a good sustainable resource. The cold mountain winds and winters weeded out those with thin pelts and make your herd more hardy to the cold weather. Layers of fat to protect against the cold have made your herd a bit slower and not as agile. You, the player, continue to force your herd to areas of increasing agility and cold; contradictory elements usually. You herd thins dramatically and is split many times. The few that can survive your demanding play-style become smaller and wiry; almost rodent like. No longer can you feed on goats unless skeletonized via an en mass assault where many are crushed or hurled off into the abyss. It's a grim choice but a better one than the losses expected in changing the diet to the local poisonous fauna (perhaps 100%). The massive regular losses from both the climate and behavior engage an high birth rate as being your only saving grace. Birthing twins leads to triplets leads to litters of pups with higher and higher numbers. I could just go on forever writing this. I think the same could be said for playing it. I can see some cool 2D models for this. There would be different segments for each moving part that would be randomized and passed down each generation. Say like you grew one arm larger than the other giving it greater mass, strength and therefore hitting power. And it became so favorable that it almost became exacerbated into one giant club arm and another small arm on the side for delicate work. Maybe backjointed legs? Longer necks? Nothing would be default except perhaps the parameters. Things would be designed to mailable through chaos and natural selections. You can't say, "I want a tiger with a unicorn horn," and expect it to happen. You've got no choice in the way you herd looks, just acts. There could be a farmer option where favorable traits and looks are grown purposefully with genetic engineering. But that would be an easy little side addon to the main quest part of the game. It'd be cool if it was a persistent world. Say you got tired of the RodentDinkles and started a new one. You'd be going along and learn of the PrairieDinkles and make them your new prey to your poisonous venom snakes or whatever.
Tagged with: • •
 
1 Comments
Leave A Response

Methods for Meaning

On 01.24.10, In Development, General, Ideas, By The Villain
(Originally published December 8, 2009) Finding meaning: Chapter VI of “Godel, Escher, Bach” begins to delve into trying to pin down the location of meaning. It discusses the recursive enumerable set: something being defined in terms of simpler versions of itself (such as Fibonacci numbers, or cells in a body). Small, simple parts make up complexity, out of which meaning is drawn. Levels of complication increase until the recursive system might be “strong enough to break out of any predetermined patterns… Instead of just considering programs composed of procedures which can recursively call themselves, why not get really sophisticated, and invent programs which can modify themselves—programs which can act on programs, extending them, improving them, generalizing them, fixing them, and so on? This kind of ‘tangled recursion’ lies at the heart of intelligence.” (p. 152). “…meaning is part of an object to the extent that it acts upon intelligence in a predictable way” (p. 165) – In context, deciphering may take more or less effort but the eventual result is in essence inevitable: the intended interpretation remains the same no matter what. We are just “drawing out” the information that is inherent in the message. (Consider elemental DNA being chemically drawn out to establish the “who” of the overall person). It is like the principle that “information is in the air” waiting to be grasped as it inevitably will be when the right condition, place, time and intelligence exists to grasp it. The Project should be able to grasp such ideas using the power of evolutionary computation and memristors beyond human brain capability. So, a little more about grasping meaning: According to GEB, 3 mechanisms are needed to draw meaning from any message (p.167): Message: 1+1=2 (just the “meaningless” figures themselves) / GEB’s FRAME MESSAGE Core message: 1+1=2 (meaning: start with one, add one, end up with two) / GEB’s INNER MESSAGE Trigger: 1+1=2 is understood for what it is to be important through the use of mathematics / GEB’s OUTER MESSAGE The trigger is the interesting part. The message can be anything. So the question for the trigger becomes, “How do I interpret the message? What method do I use to accomplish this?” This can require a lot of information, and it acts as the “schematic,” the barebones algorithm used to draw meaning from the meaningless. Where does it come from, how is it determined? The way this triggering occurs may be a universal dialect (algorithm?) which can be applied to biology, technology, and so on. From GEB: “We could ascribe meanings… of a message to the message itself, because of the fact that decipher mechanisms are themselves universal—that is, they are fundamental forms of nature which arise in the same way in diverse contexts” (p. 171) . But when we really try to pin it down, no meaning is absolute; at its core, meaning is accepted by what makes the most sense and there can be no absolute certainty. “…one can never give an ultimate, absolute proof that a proof in some system is correct. Of course, one can give a proof of a proof, or a proof of a proof of a proof—but the validity of the outermost system always remains an unproven assumption, accepted on faith.” (pp. 192-193). We as humans recognize these patterns subconsciously; our intelligence rises above the inherent contradictions and endless downward spiral of circular reasoning. Machines need to be trained to do the same for effectively drawing meaning from patterns in data. Computers already have more processing capability than our brains; we simply need to learn how to mold those capabilities. Methods: Here are some methods for extracting data in a meaningful way, mostly drawing from what we know about the human brain, as consolidated in Kurzweil’s “AI toolkit” (found here): Expert systems: Using human-like decision making with not only blatant logic, but also underlying logic which our biological brains take for granted (something that can be spelled out in the Propositional Calculus [GEB, chapter VII]): Basically determines things based on small bits of logic combined into large decision-making systems. Bayesian Nets: A self-training system, learning from past experience. “Many expert systems based on Bayesian techniques gather data from experience in an ongoing fashion, thereby continually learning and improving their decision making.” (i.e., spam filters). Markov Models: Useful for application in speech recognition, including word patterns and grammar rules discovered through machines “listening to” and analyzing human speech. Neural Nets: Many dumb parts (neurons) organizing in layers and patterned configurations. Meant to replicate the neurons in a brain. Ignorance is improved through “coaching” (experience) from one or more sources, until eventually the neural net makes its own choices based on experience. “A powerful, well-taught neural net can emulate a wide range of human pattern-recognition faculties. Systems using multilayer neural nets have shown impressive results in a wide variety of pattern-recognition tasks, including recognizing handwriting, human faces, fraud in commercial transactions such as credit-card charges, and many others. In my own experience in using neural nets in such contexts, the most challenging engineering task is not coding the nets but in providing automated lessons for them to learn their subject matter.” Genetic Algorithms: Given a goal, the GA makes use of mutations and sexual reproduction (inheriting parts of two chosen parents) to feel out the best paths towards this goal while discarding bad paths along the way. Basically, natural selection in code. “Like neural nets GAs are a way to harness the subtle but profound patterns that exist in chaotic data. A key requirement for their success is a valid way of evaluating each possible solution. This evaluation needs to be fast because it must take account of many thousands of possible solutions for each generation of simulated evolution.” Recursive Search: This involves analyzing a tree of every possible outcome, and narrowing the search by eliminating bad or unlikely branches to more quickly find adequate solutions. This recursive algorithm was used by Deep Blue and Deep Fritz for analyzing chess positions. “Key to the success of the recursive formula is pruning this huge tree of possibilities and ultimately stopping its growth.” So what is the best AI methodology? Use a combination of all of the above, depending on the application. Generally, the more varied the approach, the more robust the processing and analyzing power, along with better potential for evolutionary growth. And this still doesn’t touch on the use of memristors (et cetera). There are more tools to come as the workings of the brain become more understood.
Tagged with: • • • • • • •
 
0 Comments
Leave A Response

The Organ of Sin

On 01.24.10, In Development, Ideas, By Pariahpism
(Originally published October 30, 2009) Here’s the point by point for my making of the Organ of Sin. Now the organ is what gives a computer whatever it doesn’t have now that makes it just a bit less innocent. Why sin? Because it’ll give computer a level of conciseness. And then it’ll have a level of accountability. I don’t know what I’m talking about. I’m trying to be philosophical with my definition. Let’s just say you can’t blindly blame robots for killing your family even though it was a computers logic that played a part in their death. It’s not the computers fault because in the end it was a human decision to build that killer robot. It’s like blaming a gun for being shot. Someone had to pull the trigger. Right now computers are tools. Having the choice, the intuition, should blur that line. That’s what the Organ of Sin should do. I’m placing a lot of faith in the memristor theory. I’m actually thinking it has to be the missing link in AI. For too long people have been programming computers to think like people with no luck. Genetic programming had an elegance to it that seemed like it couldn’t fail in this task. Give the computer all it needed to succeed and then wait as evolution took its course. But so far there’s be nothing but mild advances. Visual Studio C # or Java That’s the question. This question stems from whether we want to work on a Windows or Linux platform as we build it. I suppose both are preferable in the end but each language has a nativity to an OS that should be respected. So far I’m in favor on Windows and Visual Studio because my college offers them for free. Circuits, Logic Gates and Processors This is step one. We need to build a toolset to have an emulated simple circuit. It has to be able to place resistors, inductors and capacitors into a circuit and be mathematically accurate. I’ve found several examples in both Java and VS. To this, we need to modify them to incorporate the strange math and idiosyncrasies of memristors. At this point we’ll have a theoretically complete toolset for simple electronic circuits. Layer 1 is the Building-Blocks. (Things needed to know to build this layer: Visual Studio. Simple electronic theory. Memristor theory. The mathematics behind both). Off of this we need to have another layer added. We need to have the simple components collapse into more complex logic gates for a simplification and better hu-man understanding. This layer has to predict the types of gates that don’t yet exist in nature using the memristors. Strangeness like a variable XOR gate should be seen here. Layer 2 will be the cells. (Things predicted to know to build this layer: Everything from layer 1. Simple gate logic.) Off this layer we need to build a simple processor. Just something that can cogitate some simple numbers. No more powerful that a calculator at first. Layer 3 is the organ itself. (Things predicted to know to build this layer: Everything from layer 2. Simple processor logic and theory) Add Life At this point all we have is an emulated calculator with a whole lot of overhead. We need to evolve it form here. I want to program it to attempt to solve simple math problems with a genetic algorithm. This will run constantly. While that’s happening we add another external genetic algorithm to evolve the building-blocks level. The two algorithms will be twined to co-evolve and react accordingly. The success of the higher layer algorithm should affect the breeding of the memristors into the building-blocks by the lower level algorithm. Harder and hard problems will be introduced. Eventually intuition should be bred into the processor in a way that can be expounded upon. It should be enough to rob innocence from computers. The processor will grow into something grotesque in the eyes of professional circuit designers. There will be no order, only function. (Things predicted to know to build this layer: Advanced knowledge of genetic algorithms. Familiarity with the Organ thus far) The Organ of Sin can then be used in most other projects requiring highly intuitive and adaptable processing. And since it’s software based, it can be used everywhere. Every project component after this can foreseeably use this organ.
Tagged with: • • • •
 
0 Comments
Leave A Response

Important Thoughts on Some Mentally Evasive Subjects

On 01.24.10, In General, Ideas, By The Villain
(Originally published October 17, 2009) Breaking it down: the constant is free will, and the most important variable (so far, that we are aware of) is the amount or “level” of choices available to the participant, be it human, biological agent, or technology program / game. Level 0: no choices, just actions. You are basically a robot, doing what you are told and not having the ability to realize that there are other choices from which to choose. Levels above this increment exponentially as a set of choices are involuntarily encountered. For instance, level 1 requires that you must make a given choice. You have a pool in Sims; you must choose to add a ladder to it or not. The end result of adding the ladder is that you can escape from the pool; otherwise you drown. Take it up another level. Each decision set leads to more inevitable encounters with the given set of decisions branching off of the original(s). It's a schematic of logic gates or a roadmap of connections. However you visualize it, realize that the level or "layer" is not dependent on the number of choices per se, but more accurately it is based on the choices you have already made to lead to the present layer. Each choice along the path determines the destination. Obviously if there are more choices available, there will be more possible destinations. In the Sims pool, for example, what if someone jumps in the ladder-less pool and drowns, then a second sim jumps into the pool and also begins to drown. In addition to the choices and the level, there must be a goal--in this case survival. If the need to reach the objective is strong enough, then innovation can take hold--as long as the parameters allow for such choices to be made. In Sims the parameters do not allow it, but what if the person could "figure out" the option of somehow using the other body to climb out of the pool? The real beauty in this emerges when it is not explicitly defined as an option, but it is not explicitly denied as an option either. That is when the available data set of choices may not be as clear, and where the evolutionary game has the potential to surprise us. There is the pool escape example in Sims, but each level is not necessarily limited to two choices. Another example would be the infinitude of involuntary "choices" at work in our everyday living, breathing bodies (blood pumping, cells working, et cetera). Each process can be observed and broken down--at the most basic level--to options. Taking that thought further, can every process in our known universe be broken down into 1s and 0s? Maybe not necessarily completely true, but as a general concept it helps organize everything into comprehendible compartments. As another way of thinking about it, can everything be broken down to mathematics? Even the more complex pool example can be literally broken down into thousands of ones and zeros. One modern accomplishment is our ability as humans to streamline these millions of bits of data by organizing and standardizing these decision-making procedures. The best example of this may be the many levels of programming languages: translating and interpreting the ones and zeros of machine language into higher and higher level languages to the point of understandable human language or even GUI interfaces. All those thousands and millions of ones and zeros are still completely necessary and they are still doing their thing, but it is all transparent to us. We are harnessing the data in a very energy efficient manner. And we're getting better at it, but I still think we're only scratching the surface. A multitude of individual tiny decisions end up determining large-scale, complex operations. Just as organs make up a body, bees make up a hive, and trees make up a forest within the realm of biology, computers have the capacity to organize the "organs, bees and trees" of data into meaningful advancements within the realm of technology. This is an important revelation, but it is not new. One important difference between biology and technology, however, is the fact that biological evolution is bound by biological time. Technological evolution is not. Because we continue to find more efficient means of organizing these technological decision-making processes with tools such as high level languages, behind-the-scenes processes, and so on, we are in essence accelerating the process of evolution through technology. Furthermore, biological evolution is restricted by its boundaries, already defined by layers of earlier decisions defined by physics, history and circumstances. Technology has a similar set of restrictions, but these restrictions are much less limiting. In other words, with technology we are capable of optimizing the evolutionary process because we are not bogged down by biological time, unnecessary appendages, and all those other restrictions with which biology has to contend. The grand idea out of all of this is that to truly optimize technological evolution to reach its full potential, we need to add another layer of technology. Don't rely on the slow human who is restricted by his biological brainpower. Let the computer program do that data organizing / mining / evolving. When we are able to achieve this, I expected to be amazed by the results. So we begin with evolution-infused games. The balance in design lies in figuring out where to draw the boundaries: how many options? How many layers? It is all about letting the program make the decisions, but first we have to determine the correct parameters. How do we promote innovation? This will probably be the hard part, and is going to take a lot of research. That, of course, is where we are at for now. There are still many things to consider, study and write about later to consolidate our pool of knowledge as it progresses. Some more topics I want to deal with at length: The potential of software memristors. Coevolution in technology. Quantum computing potential.
Tagged with: • •
 
0 Comments
Leave A Response
« Previous Entries
Go To Top »