Emergent Gameplay: Gamers Gone Wild

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:
 

Reviewing Facebook’s Top Games

Inside Social Games publishes a monthly "Top 25" list of popular Facebook games based on number of monthly actives. Reviewing the May 2010 list got us to thinking: What is the magic formula that has made these Facebook games so popular? What draws these users in? What better way is there to find out than to play the games ourselves, so we split the games between us and started going down the list. Here is a sampling of my experience so far: Pet SocietyWelcome to Pet Society #2. Birthday Cards I got off to a rough start. Number 2 on this list, Birthday Cards, is most definitely not a game. It’s an app for sharing birthday cards, or cards for any occasion even. Nifty, but not at all a game. I guess it only made the list because it uses Flash and has over 34 million monthly users. #4. Café world This game just makes me hungry. There is plenty of work to do (clicking—and waiting), but no real, actual, edible food to eat. How depressing. It is a static environment, but as I get money I can continue to add nicer chairs, tables, and stoves to my cafe. Oh, and I get to clean the stoves after I cook the food (by clicking them, of course). I’m not gonna lie, it is easy, and almost addicting, to keep cooking different dishes, because, well, I like food, and I'm much better at cooking here than in a real kitchen. #6. Mafia Wars This dashboard environment keeps tabs on how good a mobster I am. Things like Health, Energy, Stamina, and Experience are factors I need to be aware of. The basic gist of it is to keep pressing “Do Job” and advancing levels. So far I’ve gotten to fight people, perform random muggings and steal some cars. But then I lose a fight. Oh no: need more energy! So I wait. And then I’m good again, so I keep picking fights and advancing levels. This is a very interactive process with your fellow FB friends (and enemies), so there is the fun task of balancing who you piss off and who you want to keep on your side. #8. Happy Aquarium Pet Society In case you haven’t guessed, this game takes place inside an aquarium. Little fish are floating around, and as you gain experience you can add new animals (and decorations!) to your tank. There are easy-to-follow directions with cool-looking fish, but to me the most appealing part of the game is the range of options available to the player. You can choose to train, mate or sell any given member of the aquarium. There is a whole training environment for your fish, and you can keep track of tricks learned. Additionally there is a cleanliness and hunger scale which keeps track of, well, cleanliness and hunger levels of the fish. Of the games I played, I was most impressed with Happy Aquarium’s style of play, though I found it far from addicting. #10. Pet Society I am a cute little cat named Bob. I have a pink bowtie on my forehead, and there is always a bug (flee, fly???) buzzing around my face. Makes me want to rip the furry little smile off my avatar’s face, because you just know that as a cat, there is no way I like that stupid bug being there. Three seconds into the game and I am already trying to find my way out of this lucid nightmare. Anyway, despite feeling reprehensibly gay while playing this, there were a couple of redeeming qualities: - With plenty of instructions and an endless amount of stuff to click on, there was some semblance of "depth" or at least variety to the game. - There is an entire neighborhood to move around in. I liked the map perspective of everything as opposed to the typical static or dashboard environment I experienced in the other games; this kind of environment appeases my yearning for exploration. So, what to do, what to do… I went fishing with some apples as bait--but didn’t catch anything--visited the beauty salon... (yawwwn)... However after half an hour or so of playing, I still didn’t really feel like I knew what I was doing, and I couldn’t force myself to care enough to try any harder. In most of these games, there is always plenty of stuff to buy--especially fake money. I am disturbed how shamelessly this "buy-fake-money-with-real-money" idea is promoted. But this concept is what made Zynga their millions, so I suppose as long as people are biting it is not going to go away. Also, the menu systems for these games were all very similar, despite being created by different companies. I'm not sure if this is due to Facebook's SDK, or if there is just a general lack of creativity amongst Facebook game developers. Pet Society"$150 USD--Best Value!" Are you FFing KIDDING ME??? Conclusions: So why are these games so viral? I can only come to three solid conclusions: - Simplicity: These games do not require much depth of thought, so they are perfect for the masses. This is also where I feel the potential lies for something much better in the arena of Facebook / social networking games. Why can't there be something more complex, thought-provoking and out of the norm? There should be! - Friend interaction: This is the obvious key to Facebook's gaming success. You can help your friends, they can help you, and you get to "see" your virtual friends all the time in your digital cafe or kingdom. Or, you can compete with them, or kill them even--if you are so inclined. - Boredom factor. These games are a great time-filler. If none of your friends are posting anything on Facebook, you can at least fill up your boredom time (like, at work): creating a birthday card, cooking hamburgers, stealing a car, training a fish, or, hell, spending real money you don't have on virtual money you don't need to best your friends in an environment that doesn't really exist. After all, an innovative way to waste money is exactly what our economy needs right now, isn't it? By the way the updated top 25 games for Facebook for June 2010 can be found here.
Tagged with:
 

Defining Fitness

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:
 

The Formula For Facebook Games

-True friends list: Gaming can now happen exclusively within the context of one’s actual friends. Multiplayer games no longer suffer from the catch-22 of requiring friends to be fun while new players always start the game without friends. -Free-to-play business model: New players need not shell out $60 to join the crowd. Consumers don’t like buying multiplayer games unless they know that their friends are all going to buy the game as well. Free-to-play removes that friction. -Persistent, asynchronous play: Finding time to play with one’s real friends is difficult, especially for working, adult gamers. Asynchronous mechanics, however, let gamers play at their own pace and with their own friends, not strangers who happen to be online at the same time. -Metrics-based iteration: Retail games are developed in a vacuum, with designers working by gut instinct. Further, games get only one launch, a single chance to succeed. Most developers would love, instead, to iterate quickly on genuine, live feedback. Taken from here
 

Development Notes

There have been some exciting developments in Alphabet Soup. We now have a functioning Binary-Bitmap Converter, and a working Genetic Algorithm. I thought I'd make some notes on the first few successful runs of the GA, so here goes: For the simplest Alphabet Soup chromosome, we are using a 16-bit binary string which, while all 1s and 0s, isn't functioning as a true binary string. Instead, for our simplest calculation of fitness, we are assigning the "meatiest" chromosome (the one with the most 1s) as the fittest individual. So instead of going by the decimal value of 0000001000100101 (which is 549) we are adding the 1s for a value of 4. This cuts back on processing power, especially when dealing with a full 256 bits, and it allows us some easy numbers to work with for churning out a fitness value of any given chromosome. So, the optimal value is 16, represented as: 1111111111111111. Success! Success! Our first run of the GA striving to reach this value with a random starting population has been a surprising success. Reproduction and crossover rapidly increase the fitness no matter what the starting population. The GA often converges on not-quite ideal solutions, but with enough generations the mutations do eventually converge on the correct string. Our mutation rate is set to 10%. The other parameters are: min:0, max:2, crossover:80%, length:16. These parameters seem to work quite well. I changed the population paramater to see how that affected the runs, and the results were interesting. The following chart describes our first six runs of the "Alpha" Alphabet Soup Genetic Algorithm:
Population    Generations to converge    Total number of individuals    
25201040
27911582
42731092
43761504
5042 (w/ 2 mutants)2100
5063 (w/ 1 mutant)3150
I found it interesting that convergence seems to happen faster with a smaller population. I was especially surprised at the efficiency with which only two parents managed to converge on the correct solutions. The least number of individuals required to converge was 1,040, which happened with only two in the population, while the longest run required 3,150 individuals--using a population of 50. That's still not bad, considering the search space contains 65,536 possibilities.
Tagged with:
 

Character Collisions

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:
 

Bitmap-Binary Basics

The Bitmap-Binary Converter will likely be the core engine for at least the early versions of Alphabet Soup. To create it, there are a few things we need to consider. The two most glaring questions are how will we read individual pixels, and how will the actual conversion between pixel color and binary code take place? An even more basic consideration is which programming language we will use. I am leaning heavily toward C#, as it seems fully capable of tackling both problems. There are a couple of ways we could do this. Let's start with the assumption we begin with the bitmap and define all the colors for a given letter ("A", for example). This website explains how to access each pixel individually--exactly what we are trying to do. This is the core of the code allowing the color definition for each pixel based on location within the bitmap: public void SetPixel(int x, int y, PixelData color)     {         PixelData* pixel = PixelAt(x, y);         *pixel = color;     } However this is using 'unsafe' code to access each individual pixel. To use 'safe' code the actual program execution would take forever. So there may be a third alternative worth looking into. And here are more thoughts about this. This is something we are going to have to experiment with to find the best method, or we might have to figure out our own. To save the bitmap code for future use, we will have to set the black pixels to 1 and white pixels to 0. This will produce 256 characters, ranging from charA[0] to charA[255]. We might have the program write this data to a separate file, or just store it within its own memory. For visual reference, here is the bitmap in actual size: A Here is the 'A' bitmap represented in binary: 0000000000000000 0000000100000000 0000001110000000 0000001010000000 0000011011000000 0000010001000000 0000110001100000 0000100000100000 0000100000100000 0001111111110000 0001111111110000 0001000000010000 0011000000011000 0010000000001000 0110000000001100 0000000000000000 Here is the above bitmap referenced in pixel notation (shortened to describe the four corners): (0,0) through (0,15) ... (15,0) through (15,15) And here is the character equivalent to the above pixels: charA[0] = (0,0) = value of '0' charA[15] = (0, 15) = value of '0' charA[240] = (15,0) = value of '0' charA[255] = (15,15) = value of '0' Or, we do it the other way: Start with 62 '.txt' files (52 letters and numbers 0-9, or whatever amount we end up with for the base set of characters), each with 256 "0" and "1" characters representing the 16x16 bitmap. Read the text from the file and use the code "if charA[0]='0'..." / "if charA[0]='1'..." and the earlier bitmap code to convert each corresponding pixel to black or white by referencing the corresponding pixel within the bitmap. Whenever crossover occurs in the program, it creates a new binary (or .txt) file to represent that organism. I think a thorough understanding of the C# StringBuilder Class is going to come in handy for this, in splicing strings of binary characters and performing other modifications. Again, this will be closely intertwined with the GP or GA code, which will be the determining factor for where the splicing will occur each time. Basically we're accomplishing the same thing but from two different directions: bitmap-to-binary or binary-to-bitmap. It will probably be valuable to know how to do this in both directions for purposes of the program anyway. Basic C# data type conversions (string-to-binary-to-decimal-to-chars-to-string and so on) will be instrumental in making this work properly. This should actually be pretty simple; it will just take some time to sort out the details. What I described above should accomplish the basic functionality of the BBC; once we get this working we can move onto the engine's more complex functions, such as attributing higher "sensitivity values" to certain pixels and recognizing "contact" with other letters.
*Define Initial Population* The initial population in the final version of Alphabet Soup may likely contain one of each keyboard character available. For now, for simplicity's sake, let's begin with 4 characters: A,B,a,b. In our game, all 4 characters decide to run into each other at once. First we will convert the 16x16 characters into binary, 0 for gray and 1 for yellow: A: 0000000000000000 0000000100000000 0000001110000000 0000001010000000 0000011011000000 0000010001000000 0000110001100000 0000100000100000 0000100000100000 0001111111110000 0001111111110000 0001000000010000 0011000000011000 0010000000001000 0110000000001100 0000000000000000 A, Binary String: 0000000000000000000000010000000000000011100000000000001010000000000001101100000000000100010000000000110001100000000010000010000000001000001000000001111111110000000111111111000000010000000100000011000000011000001000000000100001100000000011000000000000000000 A, Binary-Decimal conversion: 95786086615602871731981918389383308042547593781186608 B: 0000000000000000 0000000000000000 0001111111000000 0001111111100000 0001000000110000 0001000000010000 0001000000010000 0001000000110000 0001111111100000 0001111111110000 0001000000010000 0001000000010000 0001000000110000 0001111111100000 0001111111000000 0000000000000000 B, Binary String: 0000000000000000000000000000000000011111110000000001111111100000000100000011000000010000000100000001000000010000000100000011000000011111111000000001111111110000000100000001000000010000000100000001000000110000000111111110000000011111110000000000000000000000 B, Binary-Decimal conversion: 46403387827017775033653233413204161160929512263696 a: 0000000000000000 0000000000000000 0000000000000000 0000001111100000 0000011111110000 0000110000110000 0000000000010000 0000000111110000 0000011111010000 0000110000010000 0000110000110000 0000111001110000 0000011111011000 0000000000000000 0000000000000000 0000000000000000 a, Binary String: 0000000000000000000000000000000000000000000000000000001111100000000001111111000000001100001100000000000000010000000000011111000000000111110100000000110000010000000011000011000000001110011100000000011111011000000000000000000000000000000000000000000000000000 a, Binary-Decimal conversion: 86418088698874722540000455600782178239016967 b: 0000000000000000 0000100000000000 0000100000000000 0000100000000000 0000101111000000 0000111111100000 0000110000110000 0000100000010000 0000100000010000 0000100000010000 0000100000010000 0000110000110000 0000111011100000 0000101111000000 0000000000000000 0000000000000000 b, Binary String: 0000000000000000000010000000000000001000000000000000100000000000000010111100000000001111111000000000110000110000000010000001000000001000000100000000100000010000000010000001000000001100001100000000111011100000000010111100000000000000000000000000000000000000 b, Binary-Decimal conversion: 766259462624453036391004127445265907255673543052767246 So, our Initial Population (POPinit) consists of the following four characters and their decimal representation: 1. (A) 95786086615602871731981918389383308042547593781186608 2. (B) 46403387827017775033653233413204161160929512263696 3. (a) 86418088698874722540000455600782178239016967 4. (b) 766259462624453036391004127445265907255673543052767246 *Define fitness of POPinit* First, we establish the Total, the Best, the Worst and the Average based on their decimal representations: Total: (A+B+a+b) 862091952714301014596894421608062875060164244585234517 Best: (b) 766259462624453036391004127445265907255673543052767246 Worst: (a) 86418088698874722540000455600782178239016967 Average: 23958122541618481117083899450474345137254323064508656.25 Based on these findings, we can calculate the chance of Reproduction / Survival for each character. A: 0.1111088977388315456010566688830799217993208329796695901253... = 11% chance of reproducing B: 0.0000538264945878643991068686448919016779835612586246604953... = <1% chance of reproducing a: 0.0000000001002423099146058828565205588056220034311729841463397... = MUCH <1% chance of reproducing b: 0.8888372756663382800852305796155076177170736023305327652329... = 88% chance of reproducing *Perform Reproduction Function* As you can tell from the fitness of each character, the character "b" has by far the best chance at survival, while character "A" is the only other letter with much of a chance at all. In the actual game, the reproduction function will decide who actually survives reproduction so it is impossible to say for sure, but based on these percentages we will go with three b's and one A surviving to population generation 0. So, the result of the reproduction function should look something like: 1. (b) 766259462624453036391004127445265907255673543052767246 2. (b) 766259462624453036391004127445265907255673543052767246 3. (b) 766259462624453036391004127445265907255673543052767246 4. (A) 95786086615602871731981918389383308042547593781186608 *Define fitness of gen0" Again, we determine the total, best, worst and average fitness of the new population, gen0: Total, better: (b+b+b+A) 2394564474488961980904994300725181029809568222939488346 Best, same: (b) 766259462624453036391004127445265907255673543052767246 Worst, better: (A) 95786086615602871731981918389383308042547593781186608 Average, better: 598641118622240495226248575181295257452392055734872086.5 Note that the Total, Worst, and Average fitness of the population all improved as an expected result of natural selection. The Best fitness, meanwhile stays the same--and it has no chance for improvement until running the next stage of the GA... *Perform genetic crossover operation on gen0* Start with 2 parents. Let's use 3 & 4 as an example with an arbitrary crossover point (we'll say 170 digits in--though this would actually be determined by the randomly generated genetic operation): 3. (b) 766259462624453036391004127445265907255673543052767246 = 00000000000000000000100000000000000010000000000000001000000000000000101111000000000011111110000000001100001100000000100000010000000010000001000000001000000100000000100000 | (crossover point) 01000000001100001100000000111011100000000010111100000000000000000000000000000000000000 4. (A) 957860866156028717319819183893833080425475937811868 = 00000000000000000000000100000000000000111000000000000010100000000000011011000000000001000100000000001100011000000000100000100000000010000010000000011111111100000001111111 | (crossover point) 11000000010000000100000011000000011000001000000000100001100000000011000000000000000000 From this crossover, we get 2 new offspring characters: offspring1 (o1): 0000000000000000 0000100000000000 0000100000000000 0000100000000000 0000101111000000 0000111111100000 0000110000110000 0000100000010000 0000100000010000 0000100000010000 0000100000110000 0001000000010000 0011000000011000 0010000000001000 0110000000001100 0000000000000000 o1, Binary String: 0000000000000000000010000000000000001000000000000000100000000000000010111100000000001111111000000000110000110000000010000001000000001000000100000000100000010000000010000011000000010000000100000011000000011000001000000000100001100000000011000000000000000000 o1, Binary-Decimal conversion: 766259462624453036391004127445265907255673543589892144 offspring2 (o2): 0000000000000000 0000000100000000 0000001110000000 0000001010000000 0000011011000000 0000010001000000 0000110001100000 0000100000100000 0000100000100000 0001111111110000 0001111111010000 0000110000110000 0000111011100000 0000101111000000 0000000000000000 0000000000000000 o2, Binary String: 0000000000000000000000010000000000000011100000000000001010000000000001101100000000000100010000000000110001100000000010000010000000001000001000000001111111110000000111111101000000001100001100000000111011100000000010111100000000000000000000000000000000000000 o2, Binary-Decimal conversion: 95786086615602871731981918389383308042547593244061710 So gen1 looks like: 1,2 are the same as before; 3,4 are the offspring of crossover: 1. (b) 766259462624453036391004127445265907255673543052767246 2. (b) 766259462624453036391004127445265907255673543052767246 3. (o1) 766259462624453036391004127445265907255673543589892144 4. (o2) 95786086615602871731981918389383308042547593244061710 *Convert gen1 offspring to valid characters* Now, 3 and 4 are new shapes that do not correspond with any of our 4 letters. The BBC (Bitmap-to-Binary Converter) will be used to "read" these bitmaps and find the closest letter in the space of possible letters which we will define. So, the offspring will turn into something like "h" and "8", because those are the closest possibilities within the alphabet. I was going to include a range in decimal numbers and apply that to the nearest alphabet character within that range, but I don't think that will work because more often than not the offspring will just end up reverting to one of the two characters from which it was created. From this perspective, the BBC may be a very useful portion of the AS program. So, o1 become "h" and o2 becomes "8", converting gen1 characters to: o1=h: 0000000000000000 0000110000000000 0000110000000000 0000110000000000 0000110111000000 0000111111100000 0000111000110000 0000110000110000 0000110000110000 0000110000110000 0000110000110000 0000110000110000 0000110000110000 0000110000110000 0000000000000000 0000000000000000 h, Binary String: 0000000000000000000011000000000000001100000000000000110000000000000011011100000000001111111000000000111000110000000011000011000000001100001100000000110000110000000011000011000000001100001100000000110000110000000011000011000000000000000000000000000000000000 h, Binary-Decimal conversion: 1149389193936678235951120191876555791760811195370319884 o2=8: 0000001111000000 0000011111100000 0000110000110000 0000100000010000 0000100000010000 0000110000110000 0000011111000000 0000011111100000 0000110000110000 0000100000010000 0000100000010000 0000100000010000 0000110000110000 0000011111100000 0000001111000000 0000000000000000 8, Binary String: 0000001111000000000001111110000000001100001100000000100000010000000010000001000000001100001100000000011111000000000001111110000000001100001100000000100000010000000010000001000000001000000100000000110000110000000001111110000000000011110000000000000000000000 8, Binary-Decimal conversion: 23539885800661303801528815919744719668529798326595472592908 So the gen1 now looks like: 1. (b) 766259462624453036391004127445265907255673543052767246 2. (b) 766259462624453036391004127445265907255673543052767246 3. (h) 1149389193936678235951120191876555791760811195370319884 4. (8) 23539885800661303801528815919744719668529798326595472592908 From which we evaluate the fitness again ("8" clearly will be the new dominate gene) and so on, generation after generation... *Conclusion* This is the basic gist of Alphabet Soup by GA. The final aspect of using GA is to incorporate mutations: the random changing of various pixels within the letters, which will obviously introduce the same effect of crossover in adding to the population of letters. Mutations will only be applied to a small portion of the entire population in each generation, just like in nature. With only 4 characters to choose from, let's say there are no mutations in this particular generation. That gives us the current pool of characters, including the initial population, gen0 and the current generation (gen1): [POPinit][gen0] [gen1] [A,B,a,b][b,b,b,A][b,b,h,8] So, we have 6 "b"s, 2 "A"s, 1 "a", 1 "h", 1 "B" and 1 "8" floating around. Granted this is an example run, but it plays out pretty realistically: note that the dominate gene (b) is taking up quite a bit of the population, while a and B have not grown at all in population. "h" and "8" are the new kids on the block, and they will have a direct impact on the future generations, again based on their fitness for reproduction and crossover--with a little bit of mutation thrown in here and there. One of the core questions remains: How do we make the shapes of the characters matter? In other words, how do we specify the importance of various pixels? This, I believe, can also be accomplished through the BBC, and I have some ideas for that. But more on that later.

Alphabet Character Binaries

So we have a situation where we have 256 bits that represent the location of pixels in a 16x16 grid. I’m getting the feeling this is going to surprisingly like IP addresses with their subnet masks only eight times larger. Each pixel will have a one or a zero in the 256 bits. In most of my examples I’ll be using 8 bits because it demonstrative of the same information, only legible to the hu-mons. The first eight pixels when blank are [0000000]. This is pretty simple. But it would improve most of the processes to build a little encoder to make these characters to binary conversions simpler rather than to hard code all the charters once and everytime there needs to be a change. Plus it would add in the functionality to allow the user to make their own shapes in a free form mode. Now if a letter with the [00000011] code breeded with one that had a [11000000], it would produced the Base Subnet of [11000011]. The child could contain any shape within the range and possibly none of them. If we choose to add dominant and recessive traits—which we should—than we’ll need to add another tag to show which pixels will retain dominance. Simply enough this can be accomplished with another two subnets. Back up and let’s look at the parent classes again. [00000011] now needs another three addresses to properly pass down its heritage. [00000011] has a Base Subnet of [00000011] because he’s never once breeded. And he has a Dominant Subnet of [00000011] because we want him to retain his shape as a letter. His Recessive Subnet should be [00000000] just to allow the option to change without the likelyhood. And [11000000] will have similar characteristics. (BS-[11000000] DS-[11000000] RS-[00000000]) When these two parents meet and attempt to breed the BS will become [11000011] with the DS of [XX0000XX] (the ‘X’s are random numbers) and RS [????????]. I don’t quite know how the RS will be generated. Maybe the opposite of the BS that isn’t changed from the RS? Like if the DS becomes [10000010] than we have the unchanged bits [1X00001X]. And make them the opposite of the BS would be [10000010]. I’d have to see this done a few more times further down the line to make sure the DS and the RS don’t always stay the same. I wouldn’t really see the point in just randomizing the RS, so it has to be derived from so other stat. The child would be made from these ranges. At this point other than the Dominant and Recessive context I’ve been using, there’s nothing GP about this. Fitness hasn’t become a factor in these combinations. It’s just a baseline for breeding and how it affects the appearance of the alphabet. And from appearance, it’s reactions to the environments. I think I’ll drop some pictures of a character ‘A’ in a 16x16 bit map expounded by its traits.
The black is what it is. The red is the BS traits. The blue is DS traits. And the block that looks blank is actuality the RS traits.
Same here.
The child needs a lot of explaining. The cells are one through seven from left to right. Ignore the first cell on the left. That comes last. The second is the BS which is the potential, all the things the child could be. The third is an overlay showing in green where the ‘A’ in light-blue and the ‘B’ in dark-blue overlay. The fourth is just the bits that are overlayed. This represents the bits that are common to both and are to be forced dominate. The fifth is the bits that are the ones possible to become dominant depending on randomness. The sixth is if the bottom half was somehow all flipped-on making them dominant. The seventh is the top half that was not flipped on and became recessive. And now the first is the product. The dark-red and green are manifested because of the dominance and the plum color is now the recessive and does not show itself. A problem with this system I can already foresee is that everything will soon become either recessive or dominant after only a couple generations of crossover and soon everything will manifest making every character a big black block. Maybe taking only one side of the family’s gene in step five’s dominance check and make the other un-flipped bits for the opposite family recessive. Now this is something. Here are all the same things but with the families jumbled between all the four possibles I made by cutting them in half (if it were random like I was hoping there would be hundreds of possibilities). The problem is they make some cool looking half-breed letters. But they wouldn’t look like that with only the dominant side (dark-red) and green manifested. Maybe the whole dominant/recessive thing needs to be reevaluated? Maybe when the dominant bits are chosen it'll be different. I don’t know. But it also makes the BS pointless. Maybe I should scrap it and start over.
Tagged with:
 
Over six months have passed since The Project began, and it was long before that the ideas were seeded. Pariahpism published his version of The Project origins right away. While this was an accurate description, I feel it is time to post my view on where it all started, what the past six months have involved, and where we might be going with The Project. It began with an article published in 2007 by Alan Bellows on DamnInteresting.com about hardware evolution, “On the Origin of Circuits”. A comment in this article led me to Kevin Kelly’s book, Out of Control which is fully readable online. Now normally in my internet browsing I am not going to follow a link to a book and end up reading it in its entirety, but that is exactly what happened with Out of Control. The book starts out in Biosphere 2 in Arizona, and I thought, “Hey, I’ve been there!” And it only got more interesting as it went. Who would have thought ecology, philosophy, technology, economies and evolution had so many things in common. Turns out Kevin Kelly is no scientist or engineer, but he is a hub of information, finding new meaning and understanding in many subjects, especially technology, with direct access to the top thinkers of our time. His blog The Technium continues to amaze and inspire me, while helping me think outside the box. Out of Control covered a broad range of subjects, but some information seemed to stick out from the rest. I distinctly recall being impressed by the following, from Chapter 2: In the film Batman Returns a horde of large black bats swarmed through flooded tunnels into downtown Gotham. The bats were computer generated. A single bat was created and given leeway to automatically flap its wings. The one bat was copied by the dozens until the animators had a mob. Then each bat was instructed to move about on its own on the screen following only a few simple rules encoded into an algorithm: don't bump into another bat, keep up with your neighbors, and don't stray too far away. When the algorithmic bats were run, they flocked like real bats. It all came down to simple mathematical algorithms. Throw enough math into the software and, TADA! Biology plays out on your computer screen! Then, Chapter 15 dealt specifically with Artificial Evolution, while Chapter 17 “An Open Universe” expounded on that. Tom Ray and his game Tierra were highlighted, as was the GP master John R. Koza. These would soon become household names to The Project. Fast-forward to July 2009. Pariahpism had taken to game journaling, and while not being interested in gaming I was surprisingly enthralled by his stories. My experience with software engineering combined with the memories of Origin of the Circuits and Out of Control prompted a sudden want to try to develop something of the same substance, but on a different scale. Imagine gaming journals about a self-evolving, unpredictable game! Immediately ideas started to take hold. We could provide the goals and the necessary environments, but let the games do the work! After brief but furious discussions on the matter, Pariahpism proceeded to write about a number of game ideas brewing in our heads: Alphabet Soup The Field of Blobs The Arti-Field of Blobs – The Field of Blobs Side-Quest Game Untitled And then the serious research began to see how to go about bringing such ideas to fruition. Little did we know everything that was already out there. Computational Intelligence is a huge realm under AI which includes, among others, Genetic Programming, Genetic Algorithms, A-life, Neural Networks, and so on. Books, websites and whole development environments are relegated to these subjects, prompting us to back up a step and begin collecting information at a rapid pace. And here we are—still collecting. I have decided to completely overhaul the old website and devote it to The Project, and video gaming in general. Why dailyvillain.com? It started in 2004 as an inside joke, turned nickname, turned URL. It even stood as an acronym on the website for a while—something like Vagabond Interpreting Life’s Lessons and Idiosyncratic Nuances—but that was way too long. Anyway, the web space was already there and now it exists and persists as The Project’s home. So where is The Project headed? Our original goals still stand. Early versions of Alphabet Soup and various programming languages are the focus of most of our attention for the moment, but concerning the future, anything is fair game at this point. The nice thing is that the interwebs allows the unprecedented vast sharing of information, letting us build on what others have already created. The beauty of Open Source is that it is more than just convenient, it also allows for the acceleration of information sharing, and of course, innovation. That’s what The Project is all about. For a tad more organization... This blog will help to track our thoughts and progress, while this blog has become the home for the aforementioned gaming journals, other game reviews and pretty much anything game-related.
Tagged with: