Tue - January 13, 2004
Massive Multiplayer Open Source Collectable Card Game
MMOSCCG? Yikes! Got to think up a better name
for it than that.
Been trying to get into learning Cocoa programming
lately, with little positive results. Other than the holidays making things
busier, I only have two days to run errands and go grocery shopping, which
results in a lot of walking around carrying heavy things, thus when I get
home I'm not in the best of shape to tackle learning a new programming language.
Studying before work isn't much better, as about the time I'm starting to "get
it" and things are clicking into place, I have to stop, go to work, and spend
the next eight hours trying to make other people's business cards look
interesting. Fortunately, it does look like I'll be able to shift to four nine
hour days in a couple of months, then I'll be able to devote an entire day to
programming, which is something I'm much better suited for than little snippets
grabbed at random intervals.
However, even with the little snippets falling into and out of my induced-distraction mind, I'm getting a better idea of what Cocoa and object-oriented programming can do, can't do, and what it does quite well indeed. Launching straight into ALife programming and the toon chat program is much like planning how to paint the Sistine Chapel ceilings before the first day of your "Painting Basics" art class. It's good to have a goal but you've got to be realistic somewhere along the line. That's why I was thinking of a training project, something that I could focus on while learning various aspects of programming, something that can start simple and become more developed and refined as I learn new techniques in computer gaming creation. it definitely has to be a game, I want something fun to make it more creatively interesting.
Right before my massive burnout I was working on a collectable card game with Eric Hunting. It was to be open source, so anybody could come out with their own expansion, uniform in it's mechanics, so any expansion could be played evenly with any other expansion, thus Greek Mythology could fight it out with cheesy 50's sci-fi movies, and geared to accept a wide range of playing styles, so people who like playing in different ways could be on equal footing. I worked out the basics, came up with a few prototype sets, sent out playtesting decks, got back responses from the few who actually played it, and was about to launch into the revision stage to make it simpler to play when I got stressed bombed at work over a five week period and the burnout settled in for a long, long stay. Nothing was done with it ever since. Until now...
The basic framework of the game is still good, it's as expandable as your imagination; game balance is good, playing your cards right will let you overcome your opponent no matter how far behind; playing style is still flexible so a devious plotter and planner can plan and plot deviously while a hack & slasher can happily toss minions into combat with catapults and they'll both be on equal footing if they plan their decks right. The problem was complexity, there was too much to take into account and consider, too many variables to keep track of every turn, and it took up too much space on the table when playing. I had worked out a way to simplify the cards on the table before the burnout hit, but there was still the complexity of the game mechanics itself to deal with.
Well, as you can no doubt guess by now, such complexity would be easy for the computer to handle. All the computer had to do was go through each player's deck and sort out what rules applied to which cards, it could add up points and conditions at the start of each turn, and it could make the game easier for the players by only offering them the choices that apply. In fact, by turning this game into a computer game, it also allowed me the add yet another complexity that I couldn't add to the card game: critters!
There was a game out many, many years ago that I liked very much called Titan. You traveled around various circles of land types (swamps, deserts, jungles, etc) and recruited critters, which in turn allowed you to recruit more and higher-level critters with which you attacked your opponents critters and did battle on an enlarged area map. I liked this idea a lot but could not figure out how to work it into a collectable card game that was played on a table. With the computer handling everything and displaying the critters on the screen, it becomes easy. Well, easy to play, the programming is another matter entirely. With the computer handling everything, critter recruitment, interaction and combat can be standardized to the point where any expansion can play against, or even mingle with, any other expansion, while the ability to create new and different critters and expansions remains.
So now this game is at a point where it could actually be realized, maybe even playable. This game is also a good learning platform, as it starts out easy, just getting the "cards" and rules laid out. Once that's accomplished, I can move on to making it playable, where two people could play a few games of the basic concept. Then I can add the computer opponents, a first introduction into ALife, so people can play it by themselves. Then I can step up the graphics, making the crittters and terrain look good, animated even, adding special effects, sounds, etc. Then once that's at an acceptable level, I can move on to making a simple 3D engine so the critters can be like moving miniatures, where gravity is variable, and other effects can be applied based on the rules of the card being played. And of course, I'll have to work on a program that will allow people who know nothing of Cocoa or programming to make their own critters, their own cards, and if they are really ambitious, their own expansions.
Yes, it does seem like a big project, but when you break it down as learning steps, it's not all that difficult and even helpful in that it's continually building on what I program before. Best of all, Cocoa programming, with it's object-orient focus, is idea for this kind of game. Still, just wish I didn't have to do it all alone, but that's how it is.
Also, if anybody has an idea for a good name for a computerized collectable card game that can handle any genre or concept as an expansion, please suggest it. Anythings better than MMOSCCG!
However, even with the little snippets falling into and out of my induced-distraction mind, I'm getting a better idea of what Cocoa and object-oriented programming can do, can't do, and what it does quite well indeed. Launching straight into ALife programming and the toon chat program is much like planning how to paint the Sistine Chapel ceilings before the first day of your "Painting Basics" art class. It's good to have a goal but you've got to be realistic somewhere along the line. That's why I was thinking of a training project, something that I could focus on while learning various aspects of programming, something that can start simple and become more developed and refined as I learn new techniques in computer gaming creation. it definitely has to be a game, I want something fun to make it more creatively interesting.
Right before my massive burnout I was working on a collectable card game with Eric Hunting. It was to be open source, so anybody could come out with their own expansion, uniform in it's mechanics, so any expansion could be played evenly with any other expansion, thus Greek Mythology could fight it out with cheesy 50's sci-fi movies, and geared to accept a wide range of playing styles, so people who like playing in different ways could be on equal footing. I worked out the basics, came up with a few prototype sets, sent out playtesting decks, got back responses from the few who actually played it, and was about to launch into the revision stage to make it simpler to play when I got stressed bombed at work over a five week period and the burnout settled in for a long, long stay. Nothing was done with it ever since. Until now...
The basic framework of the game is still good, it's as expandable as your imagination; game balance is good, playing your cards right will let you overcome your opponent no matter how far behind; playing style is still flexible so a devious plotter and planner can plan and plot deviously while a hack & slasher can happily toss minions into combat with catapults and they'll both be on equal footing if they plan their decks right. The problem was complexity, there was too much to take into account and consider, too many variables to keep track of every turn, and it took up too much space on the table when playing. I had worked out a way to simplify the cards on the table before the burnout hit, but there was still the complexity of the game mechanics itself to deal with.
Well, as you can no doubt guess by now, such complexity would be easy for the computer to handle. All the computer had to do was go through each player's deck and sort out what rules applied to which cards, it could add up points and conditions at the start of each turn, and it could make the game easier for the players by only offering them the choices that apply. In fact, by turning this game into a computer game, it also allowed me the add yet another complexity that I couldn't add to the card game: critters!
There was a game out many, many years ago that I liked very much called Titan. You traveled around various circles of land types (swamps, deserts, jungles, etc) and recruited critters, which in turn allowed you to recruit more and higher-level critters with which you attacked your opponents critters and did battle on an enlarged area map. I liked this idea a lot but could not figure out how to work it into a collectable card game that was played on a table. With the computer handling everything and displaying the critters on the screen, it becomes easy. Well, easy to play, the programming is another matter entirely. With the computer handling everything, critter recruitment, interaction and combat can be standardized to the point where any expansion can play against, or even mingle with, any other expansion, while the ability to create new and different critters and expansions remains.
So now this game is at a point where it could actually be realized, maybe even playable. This game is also a good learning platform, as it starts out easy, just getting the "cards" and rules laid out. Once that's accomplished, I can move on to making it playable, where two people could play a few games of the basic concept. Then I can add the computer opponents, a first introduction into ALife, so people can play it by themselves. Then I can step up the graphics, making the crittters and terrain look good, animated even, adding special effects, sounds, etc. Then once that's at an acceptable level, I can move on to making a simple 3D engine so the critters can be like moving miniatures, where gravity is variable, and other effects can be applied based on the rules of the card being played. And of course, I'll have to work on a program that will allow people who know nothing of Cocoa or programming to make their own critters, their own cards, and if they are really ambitious, their own expansions.
Yes, it does seem like a big project, but when you break it down as learning steps, it's not all that difficult and even helpful in that it's continually building on what I program before. Best of all, Cocoa programming, with it's object-orient focus, is idea for this kind of game. Still, just wish I didn't have to do it all alone, but that's how it is.
Also, if anybody has an idea for a good name for a computerized collectable card game that can handle any genre or concept as an expansion, please suggest it. Anythings better than MMOSCCG!
Posted at 03:44 PM Read More
Sun - December 14, 2003
More on how I'm going to go about the programming
One of the biggest obstacles has already been
solved, and there's even books written on how to do it.
When I first thought about making virtual worlds
where virtual critters can roam about and interact in, the main problem I had
was in how to make this world have basic physics. You know, gravity, momentum,
force, contact, etc, all that stuff we take for granted in the real world, until
we fall down a flight of stairs. Fortunately, games have paved the way. In the
race to develop the most "realistic" games, programmers competed to develop the
best physics programs. After a period where everybody had their own way of
doing things, the best elements of these were shared/learned/pirated enough to
become a basic standard. Now there are books in the stores detailing how to
program a world where you can pick up things, drop them, or shoot them to blow
up other things. While these are all in different languages, the basic concepts
are explained well enough that you could convert the examples to the programming
language of your choice. Due to how the field of first person shooter games has
become so predominant, and how some of these books were very badly written the
first time around, newer and better books are in the works right now, and should
be in the stores next year after I've learned enough cocoa programming to make
full use of them.
Once a good understanding of how to make a physical virtual world is accomplished, you can alter it to fit your needs. In my case, there are two divergent fields to explore: the toon universe where physics are something you can ignore at times (like not falling as long as you don't look down) and an all-audio world where only music defines things.
For the toon chat program, I'll be fortunate in that I'm using cartoons are a medium, and not lifelike humans. Trying to make a human-like character move and react realistically is very difficult and event he slightest flaw will make it seem fake. On the other hand, a toon character that walks funny actually increases the believability rather than detracts. This allows me to simplify matters, which makes for smaller program elements and faster transfer of data. For instance, in most games where they strive for the utmost realistic modeling, the computer has to configure the skeletal structures, muscles, limiting factors, and of course the entire physics of the world, to make a character pick up a rock and throw it. This is why on-line games require a fast broadband connection, so your computer can send all this data to the server, which then computes it and sends more data back. Since I'm going for a P2P (peer to peer) capability, the data bouncing back and forth needs to be simplified. Another problem with striving with realism is the limit it places on customizing your character. You can't give your character extra arms or a really huge nose, because that would require a complete reprogramming of how that character would move. By limiting the character physiology to the basics (just joints and degrees of freedom of those joints) you can create any kind of critter you want, then the ALife programming takes it and figures out how to make it walk from point A to point B, how to dodge pies, and how to make those big eyes when it realizes it's holding a lit stick of dynamite.
However, the MAL (musical artificial life) is going to be a bit trickier. True, I won't have to deal with gravity or object contact parameters, but I will have to figure out a way to get the MAL's to communicate with each other using actual music that can be tailored to follow different genre styles, and to be recognizable as music in the first place. Don't want to spend a lot of time only to have the MAL's end up communicating like R2D2. This is why I'm thinking along the lines of using world physics as a way of modifying the communication. Like I said, tricky, but should be interesting to try.
For instance, one thing I'm considering is a food reward system. Let's say you want a certain style of swing jazz rhythm. You input the sample notes (or let the computer sample a few MP3's of your choice) then go off to do something else for a while as the computer generates a few dozen MALs, let's them play out a song, then gives MAL-icious treats to those whose beats come closest to the sample tunes. This continues for a while as those that get it end up well fed while those who are stuck playing country western elevator muzac die off from malnutrition. However, others who are kind-of close but are developing their own unique style will be getting enough food to survive long enough for the virtual orgy, where all of the survivors swap code in a free-for-all orgy of procreation. The offspring of this are then put through similar will play for food simulations, and the survivors will once more exchange data to produce another generation, and so on and so forth, until you return and shout "Computer! Entertain me... NOW!" and it lets the latest generation of MAL's play their happy little songs for you to judge (like American Idol, but a lot less shallow and vacuous). You could chose one or two as good enough for swing, and set them aside for later use/development, you could dispose of several who don't strike your fancy, and you may find one that, while not swing per se, is interesting and well worth keeping.
So, that's a rough outline of how I'm thinking right now (but without the special effects, cast of thousands and long but witty dialogue between the mad scientist, the jester and the violent barbarian with expansive vocabulary skills)
Any ideas or questions from the viewing audience? (all three of you)
Once a good understanding of how to make a physical virtual world is accomplished, you can alter it to fit your needs. In my case, there are two divergent fields to explore: the toon universe where physics are something you can ignore at times (like not falling as long as you don't look down) and an all-audio world where only music defines things.
For the toon chat program, I'll be fortunate in that I'm using cartoons are a medium, and not lifelike humans. Trying to make a human-like character move and react realistically is very difficult and event he slightest flaw will make it seem fake. On the other hand, a toon character that walks funny actually increases the believability rather than detracts. This allows me to simplify matters, which makes for smaller program elements and faster transfer of data. For instance, in most games where they strive for the utmost realistic modeling, the computer has to configure the skeletal structures, muscles, limiting factors, and of course the entire physics of the world, to make a character pick up a rock and throw it. This is why on-line games require a fast broadband connection, so your computer can send all this data to the server, which then computes it and sends more data back. Since I'm going for a P2P (peer to peer) capability, the data bouncing back and forth needs to be simplified. Another problem with striving with realism is the limit it places on customizing your character. You can't give your character extra arms or a really huge nose, because that would require a complete reprogramming of how that character would move. By limiting the character physiology to the basics (just joints and degrees of freedom of those joints) you can create any kind of critter you want, then the ALife programming takes it and figures out how to make it walk from point A to point B, how to dodge pies, and how to make those big eyes when it realizes it's holding a lit stick of dynamite.
However, the MAL (musical artificial life) is going to be a bit trickier. True, I won't have to deal with gravity or object contact parameters, but I will have to figure out a way to get the MAL's to communicate with each other using actual music that can be tailored to follow different genre styles, and to be recognizable as music in the first place. Don't want to spend a lot of time only to have the MAL's end up communicating like R2D2. This is why I'm thinking along the lines of using world physics as a way of modifying the communication. Like I said, tricky, but should be interesting to try.
For instance, one thing I'm considering is a food reward system. Let's say you want a certain style of swing jazz rhythm. You input the sample notes (or let the computer sample a few MP3's of your choice) then go off to do something else for a while as the computer generates a few dozen MALs, let's them play out a song, then gives MAL-icious treats to those whose beats come closest to the sample tunes. This continues for a while as those that get it end up well fed while those who are stuck playing country western elevator muzac die off from malnutrition. However, others who are kind-of close but are developing their own unique style will be getting enough food to survive long enough for the virtual orgy, where all of the survivors swap code in a free-for-all orgy of procreation. The offspring of this are then put through similar will play for food simulations, and the survivors will once more exchange data to produce another generation, and so on and so forth, until you return and shout "Computer! Entertain me... NOW!" and it lets the latest generation of MAL's play their happy little songs for you to judge (like American Idol, but a lot less shallow and vacuous). You could chose one or two as good enough for swing, and set them aside for later use/development, you could dispose of several who don't strike your fancy, and you may find one that, while not swing per se, is interesting and well worth keeping.
So, that's a rough outline of how I'm thinking right now (but without the special effects, cast of thousands and long but witty dialogue between the mad scientist, the jester and the violent barbarian with expansive vocabulary skills)
Any ideas or questions from the viewing audience? (all three of you)
Posted at 12:49 PM Read More
Thu - December 4, 2003
Wanted: A 3-D Printer
I could really use a device that can make tiny
gears and parts of my own design. I sure hope I don't have to make one
myself.
Anybody who knows me well enough knows how I like
Lego gears and such. I used to play with them quite a bit to try out ideas and
prototype concepts. Problem now is that I need to test out concepts that are
too small, too unique, too customized for Lego to handle. I'm starting to use
Supersculpty to fabricate various parts, but it's a skill I've long since lost
from disuse and have to learn again from scratch. Also there's the matter of
precision. I am
not a
precise kind of guy when it comes to gears and tiny
things.
What would really make a difference is a 3D printer, a device that works just like an inkjet printer but creates a three dimensional object. The print head would run over an area, laying down tiny drops of liquid in a certain pattern, followed immediately by a curing light that would solidify the liquid into a hard plastic. Then the print head is raised (or the platform lowered) and it repeats the process for another layer, and so on and so forth until you have a finished doohicky.
The problem is, the type of 3D printer I'd like is currently terribly expensive and far more technical than it needs to be. The lowest priced 3D printer that does what I want (with the end product being durable enough for my needs) costs around $8,000, and the program to run it requires a masters degree in engineering just to make a simple cube (TRUE! An engineering firm bought one, but had to return it a month later as none of their highly trained engineers could figure out the software. *Sheesh* Who runs these companies?) The cheaper 3D fabrication devices also have problems, most notably is the inability to create small, precise things like gears, the waste of material (you need to use large blocks of plastic to make a small doohicky, then dispose of a lot of plastic dust) and the program controlling the devices are clunky, limited, and windows only (yeah, that's right, Mac users could never be interested in making things). There have been somewhat reliable rumors floating around that suggest a major printer company is close to having a 3D printer ready for the consumer market (under $1,000 and easy-to-use program) but they are hesitant to release it because they don't see a large market, they figure only design engineers would want one.
Stupid, stupid, stupid executives.
Of course there's a market for it! Anybody who likes making things will want one, from the hobbyists to the professionals. I know for a fact that model hobbyists would kill to get a 3D printer to make custom parts and props, while kids would love using one to make their own toys and action figures to play with, and there are hundreds of professions that would make daily use of such a printer.
This reminds me of Syquest and why the company went down the tubes. Their engineers had designed a removable hard drive system that was cheap, durable and easy to use, a small cartridge would hold 100 megs of data and could be cheaply made. However, the top execs decided that only artsy types would need such large portable storage for their big Photoshop pictures, and since the art crowd made up only a small part of their current market share, the execs decided it wasn't worth their time to even consider. Then a year and a half later Iomega came out with the Zip drive. Almost the exact same thing (a little better designed, though) as Syquest's abandoned project. Within a few months of the Zip drive hitting the store shelves it became an industry standard. Within half a year it was a standard option on all computers being sold. Within a year it had something like 90% of the market for removable disk data storage. Everybody was using it, from all professions and most home users. When Syquest dusted off their plans for a similar drive and tried to compete, it was way too late, they had already lost. Even their big drives sales plummeted and they soon went bankrupt, only to be bought out by Iomega.
Same situation here. An affordable 3D printer would be a big hit across the whole spectrum of computer users. Make the program that runs it adaptable enough (and open source enough) and you'll have thousands of web sites full of designs people could download and print out, thus increasing the demand even more. But try telling that to the suits in charge.
The technology is here, today, to make such a printer, but nobody seems to "get it" and market one. If there isn't one in the stores by the end of next year, I'm probably going to have to make one myself, and I'd rather be building robotic pets instead.
What would really make a difference is a 3D printer, a device that works just like an inkjet printer but creates a three dimensional object. The print head would run over an area, laying down tiny drops of liquid in a certain pattern, followed immediately by a curing light that would solidify the liquid into a hard plastic. Then the print head is raised (or the platform lowered) and it repeats the process for another layer, and so on and so forth until you have a finished doohicky.
The problem is, the type of 3D printer I'd like is currently terribly expensive and far more technical than it needs to be. The lowest priced 3D printer that does what I want (with the end product being durable enough for my needs) costs around $8,000, and the program to run it requires a masters degree in engineering just to make a simple cube (TRUE! An engineering firm bought one, but had to return it a month later as none of their highly trained engineers could figure out the software. *Sheesh* Who runs these companies?) The cheaper 3D fabrication devices also have problems, most notably is the inability to create small, precise things like gears, the waste of material (you need to use large blocks of plastic to make a small doohicky, then dispose of a lot of plastic dust) and the program controlling the devices are clunky, limited, and windows only (yeah, that's right, Mac users could never be interested in making things). There have been somewhat reliable rumors floating around that suggest a major printer company is close to having a 3D printer ready for the consumer market (under $1,000 and easy-to-use program) but they are hesitant to release it because they don't see a large market, they figure only design engineers would want one.
Stupid, stupid, stupid executives.
Of course there's a market for it! Anybody who likes making things will want one, from the hobbyists to the professionals. I know for a fact that model hobbyists would kill to get a 3D printer to make custom parts and props, while kids would love using one to make their own toys and action figures to play with, and there are hundreds of professions that would make daily use of such a printer.
This reminds me of Syquest and why the company went down the tubes. Their engineers had designed a removable hard drive system that was cheap, durable and easy to use, a small cartridge would hold 100 megs of data and could be cheaply made. However, the top execs decided that only artsy types would need such large portable storage for their big Photoshop pictures, and since the art crowd made up only a small part of their current market share, the execs decided it wasn't worth their time to even consider. Then a year and a half later Iomega came out with the Zip drive. Almost the exact same thing (a little better designed, though) as Syquest's abandoned project. Within a few months of the Zip drive hitting the store shelves it became an industry standard. Within half a year it was a standard option on all computers being sold. Within a year it had something like 90% of the market for removable disk data storage. Everybody was using it, from all professions and most home users. When Syquest dusted off their plans for a similar drive and tried to compete, it was way too late, they had already lost. Even their big drives sales plummeted and they soon went bankrupt, only to be bought out by Iomega.
Same situation here. An affordable 3D printer would be a big hit across the whole spectrum of computer users. Make the program that runs it adaptable enough (and open source enough) and you'll have thousands of web sites full of designs people could download and print out, thus increasing the demand even more. But try telling that to the suits in charge.
The technology is here, today, to make such a printer, but nobody seems to "get it" and market one. If there isn't one in the stores by the end of next year, I'm probably going to have to make one myself, and I'd rather be building robotic pets instead.
Posted at 10:33 AM Read More
Robot Critters For Fun and Profit
You'd think the success of Aibo would have
spurred new developments into pet robots, but
nooooooooooooooooooooo...
I like tinkering and creating interesting
mechanisms, so I've always been interested in robots. There are many, many,
many things I'd like to try out, but the lack of a machine shop and electronics
training keeps me from doing much. The first can be solved with a 3-D
printer/fabricator, which will be covered in the next entry. The second has
always been thwarted by an unreasonable education system. When I tried to take
beginner electronics classes they were either very late at night (and hard to
get to) or very early in the morning. Of the two 6:00 am classes I took, I
remember
nothing.
Just a foggy blur of trying to make it to the class on time and report cards
that said I received a C. Fortunately, there are thousands of "how to"
electronic guides on the net, giving step-by-step instructions on how to build
anything from small one-motor BEAM
bugs to advanced neural nets, and there are many books on learning
the basics for beginners, so all I need is a lot of free time to learn
it.
I've always believed there was a market for robot pets. People have always had a tendency to emotionally bond with machines they use often. Just listen to some guy talk about a car he's had for over a decade, and people are already treating those new robot vacuum cleaners as pets. The major setbacks to robotic pets have always been computer power and battery power, both of which are no longer a problem or will soon be solved.
Price isn't that much of a concern. When Aibo first came out, with it's hefty price tag, many analysts and experts praised it's engineering but predicted it would never make a profit for who would spend so much on a robotic pet dog? Well, they sold the entire first run in a week, the entire second run in less than a week, and the entire third run before they even started the production line. Wasn't until they mass-produced the second generation that they could keep them on the shelves.
Due to this success, a few other companies came out with their own knock-offs and wanna-be's, all of which were seriously limited in the computational department. The thing that made Aibo so popular was that it could learn, develop it's own personality, and explore to learn more about it's surroundings. The copycats did none of these, except for one, the BIObug, which was based on BEAM technology, but that thing made way too much noise. After letting it run around for ten minutes you wanted to throw it off a cliff just to get away from the constant shrill beeping. As a result of these failures and not-quite-failure-but-not-successes, the toy industry as a whole decided there wasn't a market for robot pets and went back to safe things with a proven history (and some of those things are pretty good, have you seen the latest RC flying toys? Impressive!)
But still, given the success of the initial release of Aibo, you can see that there is a demand for good robot pets, even very pricey ones. So what I would like to do (someday, if I win the lottery) is make robot pets, load them up with ALife programs (and possibly a fuel cell battery) and sell them to people with tons of money to burn.
First off, I would go for fantasy or creative critters. Why recreate a dog or cat when you could never get close to an accurate simulation? I'd rather make dragons, because nobody knows what a real dragon would act like so there's no pressure to get it as accurate as possible. Except the flying part, but anybody who would be disappointed that it doesn't fly wouldn't buy one in the first place. Also dinosaurs would probably be a lot of fun.
Secondly, I'd use ALife programming to allow them to develop their own way of moving, exploring and learning. If you ever watch a video of a robot that was programmed to move a certain way around an obstacle course, then a video of a robot that learned on it's own how to move, you'd immediately notice a distinct difference. The first would make short, logical and precise moves, and if you changed the course it would get lost and ram into things all the time. The second would actually behave like a small critter or insect, scurrying around the course with what can only be described as physical personality, and if you changed the obstacle course, it would adapt and continue on. Furthermore, ALife robots have shown an amazing adaptability to mechanical malfunctions. Remove a leg or wheel, it learns to compensate.
Also, ALife would allow the pet-bot to figure out the best way for learning, storing and accessing knowledge. There was one voice recognition program at MIT that I read about which provides a good example. A group of students had a major disagreement on how to handle the computer learning to listen, so they broke up into two camps, one that told the computer how to learn, store and access the data, and the other that programmed the computer to figure it out for itself, everything else was the same. By the end of the project the top-down group had a system that required the user to spend at least ten hours repeating words into a microphone so the computer could understand him, and only him, if he spoke slowly and carefully, and required something like 40 gigs of hard drive space. The second group had a system that could recognize what nine out of ten people were saying at a normal talking speed and with various emphasis (only heavy accents needed an hour of "training") and required less than 600 megs of memory. The results of this classroom project is at the heart of the best voice recognition programs that you can buy today. So using this approach, you can program the pet-bot how to learn, move around, adapt to changing environments, then insert an iPod for tons of data storage (and music it can play and dance to when you command it to entertain you ;-)
Thirdly, the robot has to interact with it's environment, and it's owner. While a cheap little microphone takes care of spoken commands (and two will give it stereo locating ability) I'd also want to give it a camera so it can see. The good news is that digital video cameras are getting cheaper, smaller and higher resolution every day, and it's easy to set up a split optical arrangement to give a single camera stereoscopic vision. The bad news is pattern recognition is still primitive and clunky. However, the good news with that is all of the research that I've found uses the doomed-from-the-start top-down approach (imagine trying to teach a computer how to tell the difference between a TV and a microwave, then you have to teach it to deal with portable stereos) so this looks like a job for (all together now) ALIFE PROGRAMMING! (cue heroic fanfare) If you set up the program to try to figure out on it's own what it sees through the camera, then it will gradually learn much like a child does. In fact, the pet-bot has an advantage in that it's learning can take place virtually. It can take snapshots of new items that it doesn't know about, then connect wirelessly to your computer and put up a slide show for you to review and identify. Furthermore, it can learn to read, listen to music and sing along, play fetch, play chess, and many other things all virtually. For instance, reading: you can type up a lot of text into your computer, then the program can view that text as a graphic image, compare it's guesses as to what the image means to the actual text, rewarding itself for correct words it identifies and returning to the words it fails at. So while your pet-bot is roaming around exploring your home, the spiritual astral projection of it's digital soul is busy inside your computer studying Shakespeare or learning Japanese so it can sit on your shoulder and translate anime while you watch.
Fourthly, the biggest problem for all robotics is power. The more robots can do, the more power they consume. Batteries are bulky and heavy, and while many noteworthy improvements have been made in small, lightweight batteries, you're limited to a choice between a big, heavy robot that runs for an hour, or a small, light robot that runs for five minutes before needing a recharge. Fortunately, there's hope on the horizon. Fuel cells are looking mighty promising, and come in a variety of configurations. In the lab they've been able to make fuel cells that produce the same amount of power as a traditional battery but at 10% the size and weight. Furthermore, these fuel cells can run on hydrogen (that you can produce at home with a small solar-powered production unit), alcohol (a shot of vodka lasts longer than a dozen AA batteries), and even sugar (a spoonful of sugar feeds a mess of microorganisms that produce the fuel the cell uses to create electricity). With longer and lighter battery life you have a pet-bot that can run around more, which means it can learn more, which results in it getting smarter and developing it's own personality and becoming much more pet-like.
But until these fuel cells hit the stores, there's still a lot I can do. For instance, it would be fun to make desktop pet-bots. You plug them into your computer via a firewire cable (so it can exchange data and power with your computer) and it can roam around your desk, exploring every nook and cranny, reading your mail, and having playful chats with you while you're playing games... or while you're at work, actually playing your games ;-) They would also be kind of portable, as you could plug them in any outlet, carry around a laptop battery or two so you can impress friends and strangers at bars. All the while they would be developing their intelligence, personality and learning ability, so later on when a fuel cell model comes out, you can download your desktop pet's data into the new robot and have the same old pet but with more freedom. Though it might still want to play your computer games when you're gone.
So that's the plan. Now to find the time to implement it all.
I've always believed there was a market for robot pets. People have always had a tendency to emotionally bond with machines they use often. Just listen to some guy talk about a car he's had for over a decade, and people are already treating those new robot vacuum cleaners as pets. The major setbacks to robotic pets have always been computer power and battery power, both of which are no longer a problem or will soon be solved.
Price isn't that much of a concern. When Aibo first came out, with it's hefty price tag, many analysts and experts praised it's engineering but predicted it would never make a profit for who would spend so much on a robotic pet dog? Well, they sold the entire first run in a week, the entire second run in less than a week, and the entire third run before they even started the production line. Wasn't until they mass-produced the second generation that they could keep them on the shelves.
Due to this success, a few other companies came out with their own knock-offs and wanna-be's, all of which were seriously limited in the computational department. The thing that made Aibo so popular was that it could learn, develop it's own personality, and explore to learn more about it's surroundings. The copycats did none of these, except for one, the BIObug, which was based on BEAM technology, but that thing made way too much noise. After letting it run around for ten minutes you wanted to throw it off a cliff just to get away from the constant shrill beeping. As a result of these failures and not-quite-failure-but-not-successes, the toy industry as a whole decided there wasn't a market for robot pets and went back to safe things with a proven history (and some of those things are pretty good, have you seen the latest RC flying toys? Impressive!)
But still, given the success of the initial release of Aibo, you can see that there is a demand for good robot pets, even very pricey ones. So what I would like to do (someday, if I win the lottery) is make robot pets, load them up with ALife programs (and possibly a fuel cell battery) and sell them to people with tons of money to burn.
First off, I would go for fantasy or creative critters. Why recreate a dog or cat when you could never get close to an accurate simulation? I'd rather make dragons, because nobody knows what a real dragon would act like so there's no pressure to get it as accurate as possible. Except the flying part, but anybody who would be disappointed that it doesn't fly wouldn't buy one in the first place. Also dinosaurs would probably be a lot of fun.
Secondly, I'd use ALife programming to allow them to develop their own way of moving, exploring and learning. If you ever watch a video of a robot that was programmed to move a certain way around an obstacle course, then a video of a robot that learned on it's own how to move, you'd immediately notice a distinct difference. The first would make short, logical and precise moves, and if you changed the course it would get lost and ram into things all the time. The second would actually behave like a small critter or insect, scurrying around the course with what can only be described as physical personality, and if you changed the obstacle course, it would adapt and continue on. Furthermore, ALife robots have shown an amazing adaptability to mechanical malfunctions. Remove a leg or wheel, it learns to compensate.
Also, ALife would allow the pet-bot to figure out the best way for learning, storing and accessing knowledge. There was one voice recognition program at MIT that I read about which provides a good example. A group of students had a major disagreement on how to handle the computer learning to listen, so they broke up into two camps, one that told the computer how to learn, store and access the data, and the other that programmed the computer to figure it out for itself, everything else was the same. By the end of the project the top-down group had a system that required the user to spend at least ten hours repeating words into a microphone so the computer could understand him, and only him, if he spoke slowly and carefully, and required something like 40 gigs of hard drive space. The second group had a system that could recognize what nine out of ten people were saying at a normal talking speed and with various emphasis (only heavy accents needed an hour of "training") and required less than 600 megs of memory. The results of this classroom project is at the heart of the best voice recognition programs that you can buy today. So using this approach, you can program the pet-bot how to learn, move around, adapt to changing environments, then insert an iPod for tons of data storage (and music it can play and dance to when you command it to entertain you ;-)
Thirdly, the robot has to interact with it's environment, and it's owner. While a cheap little microphone takes care of spoken commands (and two will give it stereo locating ability) I'd also want to give it a camera so it can see. The good news is that digital video cameras are getting cheaper, smaller and higher resolution every day, and it's easy to set up a split optical arrangement to give a single camera stereoscopic vision. The bad news is pattern recognition is still primitive and clunky. However, the good news with that is all of the research that I've found uses the doomed-from-the-start top-down approach (imagine trying to teach a computer how to tell the difference between a TV and a microwave, then you have to teach it to deal with portable stereos) so this looks like a job for (all together now) ALIFE PROGRAMMING! (cue heroic fanfare) If you set up the program to try to figure out on it's own what it sees through the camera, then it will gradually learn much like a child does. In fact, the pet-bot has an advantage in that it's learning can take place virtually. It can take snapshots of new items that it doesn't know about, then connect wirelessly to your computer and put up a slide show for you to review and identify. Furthermore, it can learn to read, listen to music and sing along, play fetch, play chess, and many other things all virtually. For instance, reading: you can type up a lot of text into your computer, then the program can view that text as a graphic image, compare it's guesses as to what the image means to the actual text, rewarding itself for correct words it identifies and returning to the words it fails at. So while your pet-bot is roaming around exploring your home, the spiritual astral projection of it's digital soul is busy inside your computer studying Shakespeare or learning Japanese so it can sit on your shoulder and translate anime while you watch.
Fourthly, the biggest problem for all robotics is power. The more robots can do, the more power they consume. Batteries are bulky and heavy, and while many noteworthy improvements have been made in small, lightweight batteries, you're limited to a choice between a big, heavy robot that runs for an hour, or a small, light robot that runs for five minutes before needing a recharge. Fortunately, there's hope on the horizon. Fuel cells are looking mighty promising, and come in a variety of configurations. In the lab they've been able to make fuel cells that produce the same amount of power as a traditional battery but at 10% the size and weight. Furthermore, these fuel cells can run on hydrogen (that you can produce at home with a small solar-powered production unit), alcohol (a shot of vodka lasts longer than a dozen AA batteries), and even sugar (a spoonful of sugar feeds a mess of microorganisms that produce the fuel the cell uses to create electricity). With longer and lighter battery life you have a pet-bot that can run around more, which means it can learn more, which results in it getting smarter and developing it's own personality and becoming much more pet-like.
But until these fuel cells hit the stores, there's still a lot I can do. For instance, it would be fun to make desktop pet-bots. You plug them into your computer via a firewire cable (so it can exchange data and power with your computer) and it can roam around your desk, exploring every nook and cranny, reading your mail, and having playful chats with you while you're playing games... or while you're at work, actually playing your games ;-) They would also be kind of portable, as you could plug them in any outlet, carry around a laptop battery or two so you can impress friends and strangers at bars. All the while they would be developing their intelligence, personality and learning ability, so later on when a fuel cell model comes out, you can download your desktop pet's data into the new robot and have the same old pet but with more freedom. Though it might still want to play your computer games when you're gone.
So that's the plan. Now to find the time to implement it all.
Posted at 10:31 AM Read More
Sat - November 29, 2003
How I'm going to do it
Using Genetic Algorithm and Cocoa Programming to
create living code critters (insert mad scientist laughter here)
When I started to consider doing my own
experiments in Artificial Life, I looked around for which program language to
use. First thing I did was look into what others are using, which wasn't that
helpful. Most people in the field use whatever programming language they
already knew, or made up their own for security reasons so their virtual
critters wouldn't escape (imagine a Godzilla-like code creature, rising from the
mutations in an artificial life experiment gone horribly wrong, rampaging
through the university's computer network laying waste to pirated music files
with it's virtually radioactive breath).
(Actually, that would be pretty
cool.) In the formal classes of teaching
Artificial Life/Intelligence, they use programming languages that are favored by
the AInt crowd for their top-down structure, which near as I can tell, is poison
to ALife, as I've yet to see a truly impressive ALife development from these
languages, all of the good stuff is being done
elsewhere.
While I was searching for a language, OS X for the Mac came out, along with a programming language called Cocoa, which is Objective-C object-oriented, which meant nothing to me until I read a review that called it "The Lego of Programming." I decided to use Cocoa right then and there. This turned out to be a good decision for two reasons:
1) All of the piddly little details are built-in with Cocoa. Everything that makes a program look good (buttons, graphics, GUI, etc) and actually usable by others are all included in Cocoa already, so instead of taking time and effort away from my MAL programming just to figure out how to put in a slide bar of differing colors, I can drop in an already pre-made slide bar and get back to the important stuff.
2) The various parts of the program are treated like objects (think Lego blocks here) that can be added, removed, altered, exchanged, whatever, without having to recode the entire program. This is especially good for how I want to go about programming my MALs, for this way I can treat each block as a separate genetic algorithm that evolves on it's own. While it's true that any programming language can have subroutines that you can treat like blocks, the more you use them the more confusing it gets, and if they change (as I want them to change) it takes a lot of programming to keep them from messing up the main program. Cocoa (and other object-oriented languages) are made specifically for this type of programming and is much better at handling it than any other language.
For instance, let's say I have a MAL that I'm training to play Surf rock guitar. It has a tempo, chords, strings, melody and style blocks that it uses to evolve a tune that is similar to Man or Astroman's style. While it is running through numerous generations of the overall tune, each of those individual blocks are also going through numerous generations, so the strings block is evolving itself and doing a better job at picking out a tune on a string-like instrument, and can be given a banjo and used in a bluegrass MAL later on, giving it a headstart. Conversely, I can also limit the evolution of these blocks, like I can set the strings and chords to only evolve a little or not at all while instructing the melody and style to evolve greatly. This is something that's missing in most of "serious" ALife programming, where the programs are treated as whole, complete entities, thus each program has to be recreated just to change the objective or attributes of a minor part.
Now is a good time to talk a bit about Genetic Algorithm (insert dramatic organ music here)
Genetic Algorithm is a style of programming where you give the computer the basic fields and let it do the trial and error of learning. A great example of this is walking. When a person tells the computer how to make a virtual figure walk, you end up with a figure that walks way too smoothly to be natural, gliding across the virtual floor in a manner that just screams "Computer Generated." When the programmer tries to adjust the walking to make it look more natural, they end up spending oodles of time and effort studying walking in real life, inputting every tiny detail so every toe is accounted for in every step, going through the tedious motion capturing of a living person so the knees move realistically, and so on and so forth. All of which could end up looking great, but then if you wanted to add a little obstacle for the virtual walker to step around, you have to redo the entire process.
With Genetic Algorithms, you give the computer a virtual figure with legs. You tell the computer how far the joints can move, which muscles move where, give it some physics (gravity, momentum, ground, etc) then tell it to move the joints and limbs about and try to get from point A to point B. Of course it doesn't make it, just ends up falling down and flailing about, but you tell it to try 40 times, then take the six attempts that took at least one step before falling, have them mate with each other (compare code and keep the parts that made that one step) then tell the three offspring to try 30 times. This results in one to three steps before falling down, so you take the top six performers, marry them, send them to a honeymoon in Vegas, and when they get back they have three kids that you run through the process again for 20 times. You keep doing this and eventually the computer figures out how to walk from point A to point B without falling, then you can add obstacles for it to avoid or walk over, give it a crippled leg, an extra leg or two, or even rhythm so it can dance around objects, and the program will learn on its own how to do it.
If you want to see how such a walking program evolves, check this out:
http://www.naturalmotion.com/pages/technology_hiw.htm
If you're on a Mac running OS X, you can download a "Learn To Walk" screensaver that does what I'm talking about:
BreveWalker
This is an actual program, not a movie. It runs through various tests, using different lengths of legs with different ranges of motion, every time the camera angle changes, it's starting a new test run. You can watch the critter wave it's legs around as it learns how to move them, but eventually it'll figure out how to walk and run around the virtual landscape. Leave it on all night and see the difference in the morning. The virtual bug remembers, so even if it's on five minutes at a time, for 20 times, it learns as much about walking as it would if you left it on an hour.
Once you have a program that knows how to walk, and knows how to adapt to different environments, handicaps or alterations, then you can keep that "walking" as a block for use in other code critters as a basic foundation. This plays an important part in my 3D Chat and Virtual Theater projects.
More later, time to leave for work.
While I was searching for a language, OS X for the Mac came out, along with a programming language called Cocoa, which is Objective-C object-oriented, which meant nothing to me until I read a review that called it "The Lego of Programming." I decided to use Cocoa right then and there. This turned out to be a good decision for two reasons:
1) All of the piddly little details are built-in with Cocoa. Everything that makes a program look good (buttons, graphics, GUI, etc) and actually usable by others are all included in Cocoa already, so instead of taking time and effort away from my MAL programming just to figure out how to put in a slide bar of differing colors, I can drop in an already pre-made slide bar and get back to the important stuff.
2) The various parts of the program are treated like objects (think Lego blocks here) that can be added, removed, altered, exchanged, whatever, without having to recode the entire program. This is especially good for how I want to go about programming my MALs, for this way I can treat each block as a separate genetic algorithm that evolves on it's own. While it's true that any programming language can have subroutines that you can treat like blocks, the more you use them the more confusing it gets, and if they change (as I want them to change) it takes a lot of programming to keep them from messing up the main program. Cocoa (and other object-oriented languages) are made specifically for this type of programming and is much better at handling it than any other language.
For instance, let's say I have a MAL that I'm training to play Surf rock guitar. It has a tempo, chords, strings, melody and style blocks that it uses to evolve a tune that is similar to Man or Astroman's style. While it is running through numerous generations of the overall tune, each of those individual blocks are also going through numerous generations, so the strings block is evolving itself and doing a better job at picking out a tune on a string-like instrument, and can be given a banjo and used in a bluegrass MAL later on, giving it a headstart. Conversely, I can also limit the evolution of these blocks, like I can set the strings and chords to only evolve a little or not at all while instructing the melody and style to evolve greatly. This is something that's missing in most of "serious" ALife programming, where the programs are treated as whole, complete entities, thus each program has to be recreated just to change the objective or attributes of a minor part.
Now is a good time to talk a bit about Genetic Algorithm (insert dramatic organ music here)
Genetic Algorithm is a style of programming where you give the computer the basic fields and let it do the trial and error of learning. A great example of this is walking. When a person tells the computer how to make a virtual figure walk, you end up with a figure that walks way too smoothly to be natural, gliding across the virtual floor in a manner that just screams "Computer Generated." When the programmer tries to adjust the walking to make it look more natural, they end up spending oodles of time and effort studying walking in real life, inputting every tiny detail so every toe is accounted for in every step, going through the tedious motion capturing of a living person so the knees move realistically, and so on and so forth. All of which could end up looking great, but then if you wanted to add a little obstacle for the virtual walker to step around, you have to redo the entire process.
With Genetic Algorithms, you give the computer a virtual figure with legs. You tell the computer how far the joints can move, which muscles move where, give it some physics (gravity, momentum, ground, etc) then tell it to move the joints and limbs about and try to get from point A to point B. Of course it doesn't make it, just ends up falling down and flailing about, but you tell it to try 40 times, then take the six attempts that took at least one step before falling, have them mate with each other (compare code and keep the parts that made that one step) then tell the three offspring to try 30 times. This results in one to three steps before falling down, so you take the top six performers, marry them, send them to a honeymoon in Vegas, and when they get back they have three kids that you run through the process again for 20 times. You keep doing this and eventually the computer figures out how to walk from point A to point B without falling, then you can add obstacles for it to avoid or walk over, give it a crippled leg, an extra leg or two, or even rhythm so it can dance around objects, and the program will learn on its own how to do it.
If you want to see how such a walking program evolves, check this out:
http://www.naturalmotion.com/pages/technology_hiw.htm
If you're on a Mac running OS X, you can download a "Learn To Walk" screensaver that does what I'm talking about:
BreveWalker
This is an actual program, not a movie. It runs through various tests, using different lengths of legs with different ranges of motion, every time the camera angle changes, it's starting a new test run. You can watch the critter wave it's legs around as it learns how to move them, but eventually it'll figure out how to walk and run around the virtual landscape. Leave it on all night and see the difference in the morning. The virtual bug remembers, so even if it's on five minutes at a time, for 20 times, it learns as much about walking as it would if you left it on an hour.
Once you have a program that knows how to walk, and knows how to adapt to different environments, handicaps or alterations, then you can keep that "walking" as a block for use in other code critters as a basic foundation. This plays an important part in my 3D Chat and Virtual Theater projects.
More later, time to leave for work.
Posted at 12:34 PM Read More
Tue - November 25, 2003
Your computer is an actor, the internet is the stage
How to entertain friends and maybe make
an impression on total strangers
By now all of you reading this (as I expect only
close friends will ever see this) should know of my plans for making a 3D chat
room, kind of like a mix of Palace and Unreal. Indeed, there are massive
on-line games out there were member spend hours just chatting to each other,
in-between killing monsters, of course. However these cost quite a bit per
month and are geared for action, not socializing. There have been other
attempts, such as "There," "Second Life" and "Sims On Line" but they've all
failed due to money-grubbing, centralized control, or top-down mentality, not to
mention incredibly bone-headed decisions of the top people to exclude all Mac
users from joining the party (a flaw which is killing Adobe's "Atmosphere" even
before it gets started, as the most creative and attractive "worlds" seem to be
made by Mac users running windows emulation, which they can no longer use as
Adobe cracked down on "non-target" users, now it's withering away as beta
testers are losing interest)
If you look at successful social hang-outs on the net and failed ones, you can't help but notice that the winners are loose, peer-to-peer, no central authority, user controlled (to the extent they want control) and open to manipulation as a form of expression. This is why BBS, newsgroups, open forums and instant messaging flourished, and the lack of these elements is the reason commercial ventures failed.
What I hope to do is create a simple 3D chat program that is entirely peer-to-peer. Any one person can create a room and invite others inside for conversation and animated hijinks, Those joining can have their own avatar, special effects and props, which they can use, trade or ignore as they wish. Each person's computer will be used as a kind of cluster supercomputer for the computing of the 3D world and the transfer of data. For instance, if somebody joined with a spiffy special effect that turned all chairs into jello monsters dancing the tango with whoever is sitting in them, all computers connected to this room would take part in figuring out how to achieve that effect to the best results, the faster computers doing most of the work, the slower ones doing what they can. When completed, the information is sent to all visitors in pieces, and from all computers. Instead of one server sending all the data to all the computers, which is time consuming, you have all of the computers gathering the data from all the others, while simultaneously sharing it, so the more people you have in that room, the faster all of them get the data (a concept which works quite well with Bittorrent for the transfer of 300 meg files).
Also, that data would be as simplified as possible. Once everybody in the same room has the basic information (body shapes, items, physics, etc) then all you need to send is what is moving where, or the subtle changes that occur when one person throws a pie at another (although pie-throwing will be a basic element of the main program, remember who's going to be making this). Furthermore, once the basics of how things are made are settled, the data can be compressed further, so you could send your avatar's data (covering appearance, effects, physics, etc) via email if you wanted so your friends are ready to go the moment they connect.
That's when I started thinking this could be used to make 3D movies, or plays if you will. Once you have the basic program, you can stage your characters in my 3D chat program to act out a scene, with dialogue, special effects, camera angles, dramatic music, etc, then the program would break it down into the basic instructions and compress it so you could email to a friend, who would view it by double-clicking on the file, then add their own act to it and mail it back. This approach could also work for a typical forum, where you can view everybody's statements then add your own at the end (imagine My Dinner With Andre but with finnish trolls, techno-cats, sexy zebras and disgruntled wombats frolicking around a giant treehouse).
Since this is open source, the people using it can make with it what they will, and they can innovate as much as they desire. The Palace was at its most popular when users were creating their own code effects and animated avatars, and "There" isn't even getting off the ground because they refuse to let users tweak their own avatars (and in both cases, greed is killing them) People (for the most part) want to communicate with others, something overlooked by The Powers That Be in the computer world in the past, and still today, and every time a new dimension is added communication increases. With this Digital Theater format the dimensions are widened a lot.
Now comes the tricky part: how to program it...
(to be continued)
If you look at successful social hang-outs on the net and failed ones, you can't help but notice that the winners are loose, peer-to-peer, no central authority, user controlled (to the extent they want control) and open to manipulation as a form of expression. This is why BBS, newsgroups, open forums and instant messaging flourished, and the lack of these elements is the reason commercial ventures failed.
What I hope to do is create a simple 3D chat program that is entirely peer-to-peer. Any one person can create a room and invite others inside for conversation and animated hijinks, Those joining can have their own avatar, special effects and props, which they can use, trade or ignore as they wish. Each person's computer will be used as a kind of cluster supercomputer for the computing of the 3D world and the transfer of data. For instance, if somebody joined with a spiffy special effect that turned all chairs into jello monsters dancing the tango with whoever is sitting in them, all computers connected to this room would take part in figuring out how to achieve that effect to the best results, the faster computers doing most of the work, the slower ones doing what they can. When completed, the information is sent to all visitors in pieces, and from all computers. Instead of one server sending all the data to all the computers, which is time consuming, you have all of the computers gathering the data from all the others, while simultaneously sharing it, so the more people you have in that room, the faster all of them get the data (a concept which works quite well with Bittorrent for the transfer of 300 meg files).
Also, that data would be as simplified as possible. Once everybody in the same room has the basic information (body shapes, items, physics, etc) then all you need to send is what is moving where, or the subtle changes that occur when one person throws a pie at another (although pie-throwing will be a basic element of the main program, remember who's going to be making this). Furthermore, once the basics of how things are made are settled, the data can be compressed further, so you could send your avatar's data (covering appearance, effects, physics, etc) via email if you wanted so your friends are ready to go the moment they connect.
That's when I started thinking this could be used to make 3D movies, or plays if you will. Once you have the basic program, you can stage your characters in my 3D chat program to act out a scene, with dialogue, special effects, camera angles, dramatic music, etc, then the program would break it down into the basic instructions and compress it so you could email to a friend, who would view it by double-clicking on the file, then add their own act to it and mail it back. This approach could also work for a typical forum, where you can view everybody's statements then add your own at the end (imagine My Dinner With Andre but with finnish trolls, techno-cats, sexy zebras and disgruntled wombats frolicking around a giant treehouse).
Since this is open source, the people using it can make with it what they will, and they can innovate as much as they desire. The Palace was at its most popular when users were creating their own code effects and animated avatars, and "There" isn't even getting off the ground because they refuse to let users tweak their own avatars (and in both cases, greed is killing them) People (for the most part) want to communicate with others, something overlooked by The Powers That Be in the computer world in the past, and still today, and every time a new dimension is added communication increases. With this Digital Theater format the dimensions are widened a lot.
Now comes the tricky part: how to program it...
(to be continued)
Posted at 09:49 PM Read More
Wed - November 19, 2003
Artificial Life - Overview
A description of what I hope to achieve,
given enough time and a winning lottery ticket
Artificial Life
Programming: Like most people who want to
get into programming, I look at my chosen field (AL) and see everybody is doing
it wrong and that somebody needs to set them straight
;-)
But seriously, there's a lot of work being done out there that's fascinating, and some in entirely the wrong manner, but nothing being done in what I want to try (that I know of). What I hope to do is come up with a form of artificial life that uses music as a way to grow, evolve, learn and interact with the user and with other musical artificial life's (hereafter referred to as MAL).
I've always been interested in Artificial Intelligence, but the basic framework has always seemed unrealistic to me: that being the programmer tells the computer what to think and how to think it. When you break it down, that's a pretty overwhelming task, as trying to define all knowledge and social interaction into purely yes-no parameters would either be way too simplistic or get bogged down in gigs of trivia. It always struck me that what needed to be done was to program the computer to learn, and to develop it's own learning style that suits it's digital brain the best. A few pioneers in Artificial Intelligence tried this approach but blew it by trying to program the computer to learn, but only in the way they told it to, which resulted in either useless simplicity or bogged down in gigs of trivia. From what I've seen all the limitations and roadblocks in Artificial Intelligence originate in it's inherent top-down approach. You'd get the same results from a mountain goat trying to teach a fish how to swim.
Then some people started working from the bottom up. Give the computer a simple set of code with which it can build on, evolve, develop and refine on it's own, then let it run loose for a while and see what happens. This field is called Artificial Life, because you let the program live rather than micromanage it to death. As to be expected, this new approach was disparaged by the Artificial Intelligence community, and in some instances banned from certain universities as a dark mystic art and not true computer science. Eventually Artificial Life made significant breakthroughs that put the best AI efforts to shame, so it was grudgingly accepted as a viable alternative. Unfortunately, this acceptance is also causing setbacks, as the top-down school of thought appropriated the bottom-up method and screwed it up by inserting way more complexity than is needed, and rigidly defining the outcome before the program is even run. In other words, they fail to grasp the concept that makes it succeed.
So I've always wanted to dabble in Artificial Life if only to see where it could go if given the chance to explore new avenues of development. I'm fortunate in that due to the very nature of bottom-up Artificial Life, the basics are, well, basic, and can be done with a small computer and an intermediate grasp of programming. Well, okay, it also takes a slightly warped mind to grasp the concept in the first place, but I think I got that part covered right now.
When I first started thinking of actually doing something with Artificial life, I knew right away I wanted to do something with usable results. Making dots blink in interesting patterns get boring after a few minutes, and esoteric numerical calculations only appeal to hard-core mathematics types, while on the other hand evolutionary programming (where you let the program create other programs through evolution artificial life) are definitely in the advanced side of the spectrum.
But then Eric came up with an interesting idea for an audible computer, one that uses sounds instead of a screen to relay information. That got me thinking about using music as the concept for my artificial life program. With music you have a very basic framework (notes, chords, tempo, etc) from which a very wide variety of possibilities emerge. Using music, a person can train their program along the lines of music they like by feeding it through yes and no replies (yes, I like that melody, no I hate the drum solo = melody maker gets nourished, the drum code becomes extinct) and gives different programs a means of communicating without having to utilize the exact same language (a jazz MAL can jam with classical MAL by comparing melodies, even if the instruments, tempo and style are completely different).
Also, I thought it would be a hoot to mix and match MALs for jam sessions. Wouldn't it be fun to train a jazz saxophone MAL then plop it into a band made of up an classical orchestra led by a bluegrass banjo MAL?
More later.
But seriously, there's a lot of work being done out there that's fascinating, and some in entirely the wrong manner, but nothing being done in what I want to try (that I know of). What I hope to do is come up with a form of artificial life that uses music as a way to grow, evolve, learn and interact with the user and with other musical artificial life's (hereafter referred to as MAL).
I've always been interested in Artificial Intelligence, but the basic framework has always seemed unrealistic to me: that being the programmer tells the computer what to think and how to think it. When you break it down, that's a pretty overwhelming task, as trying to define all knowledge and social interaction into purely yes-no parameters would either be way too simplistic or get bogged down in gigs of trivia. It always struck me that what needed to be done was to program the computer to learn, and to develop it's own learning style that suits it's digital brain the best. A few pioneers in Artificial Intelligence tried this approach but blew it by trying to program the computer to learn, but only in the way they told it to, which resulted in either useless simplicity or bogged down in gigs of trivia. From what I've seen all the limitations and roadblocks in Artificial Intelligence originate in it's inherent top-down approach. You'd get the same results from a mountain goat trying to teach a fish how to swim.
Then some people started working from the bottom up. Give the computer a simple set of code with which it can build on, evolve, develop and refine on it's own, then let it run loose for a while and see what happens. This field is called Artificial Life, because you let the program live rather than micromanage it to death. As to be expected, this new approach was disparaged by the Artificial Intelligence community, and in some instances banned from certain universities as a dark mystic art and not true computer science. Eventually Artificial Life made significant breakthroughs that put the best AI efforts to shame, so it was grudgingly accepted as a viable alternative. Unfortunately, this acceptance is also causing setbacks, as the top-down school of thought appropriated the bottom-up method and screwed it up by inserting way more complexity than is needed, and rigidly defining the outcome before the program is even run. In other words, they fail to grasp the concept that makes it succeed.
So I've always wanted to dabble in Artificial Life if only to see where it could go if given the chance to explore new avenues of development. I'm fortunate in that due to the very nature of bottom-up Artificial Life, the basics are, well, basic, and can be done with a small computer and an intermediate grasp of programming. Well, okay, it also takes a slightly warped mind to grasp the concept in the first place, but I think I got that part covered right now.
When I first started thinking of actually doing something with Artificial life, I knew right away I wanted to do something with usable results. Making dots blink in interesting patterns get boring after a few minutes, and esoteric numerical calculations only appeal to hard-core mathematics types, while on the other hand evolutionary programming (where you let the program create other programs through evolution artificial life) are definitely in the advanced side of the spectrum.
But then Eric came up with an interesting idea for an audible computer, one that uses sounds instead of a screen to relay information. That got me thinking about using music as the concept for my artificial life program. With music you have a very basic framework (notes, chords, tempo, etc) from which a very wide variety of possibilities emerge. Using music, a person can train their program along the lines of music they like by feeding it through yes and no replies (yes, I like that melody, no I hate the drum solo = melody maker gets nourished, the drum code becomes extinct) and gives different programs a means of communicating without having to utilize the exact same language (a jazz MAL can jam with classical MAL by comparing melodies, even if the instruments, tempo and style are completely different).
Also, I thought it would be a hoot to mix and match MALs for jam sessions. Wouldn't it be fun to train a jazz saxophone MAL then plop it into a band made of up an classical orchestra led by a bluegrass banjo MAL?
More later.
Posted at 02:04 PM Read More
Not so grand opening
The first entry
Okay, here we
go.
Several people have wanted me to keep a log/diary/journal/whatever where I write down my ideas (a certain wombat in Canada being at the front of the line), while others have suggested that a blog like this one might help me define various concepts to the point they become actual projects. Kind of like going through the process of figuring out how to write my ideas out so others can understand them would develop the ideas into practical steps do-able in the real world.
My biggest concern here is that writing about my ideas would take the place of actually doing them (a problem I've seen in other people). But considering that since my big meltdown I haven't been doing anything anyway, there's not much to lose in trying.
So here goes. The big projects I want to try doing (in no particular order):
Artificial Life Programming
Tashta's Present
Robotics/Animatronics
Digital Theater
3D P2P Chat Room
Writing a fun story people like to read
These will be discussed in separate entries, in their own categories, so you can read only what you're interested in. And of course, Tashta's Present won't be discussed at all because I hope she'll read this blog and I don't want to ruin the surprise (if I should ever get it working right)
So, anything you want to talk about? Let me know.
Talk to you later
PAL
Several people have wanted me to keep a log/diary/journal/whatever where I write down my ideas (a certain wombat in Canada being at the front of the line), while others have suggested that a blog like this one might help me define various concepts to the point they become actual projects. Kind of like going through the process of figuring out how to write my ideas out so others can understand them would develop the ideas into practical steps do-able in the real world.
My biggest concern here is that writing about my ideas would take the place of actually doing them (a problem I've seen in other people). But considering that since my big meltdown I haven't been doing anything anyway, there's not much to lose in trying.
So here goes. The big projects I want to try doing (in no particular order):
Artificial Life Programming
Tashta's Present
Robotics/Animatronics
Digital Theater
3D P2P Chat Room
Writing a fun story people like to read
These will be discussed in separate entries, in their own categories, so you can read only what you're interested in. And of course, Tashta's Present won't be discussed at all because I hope she'll read this blog and I don't want to ruin the surprise (if I should ever get it working right)
So, anything you want to talk about? Let me know.
Talk to you later
PAL
Posted at 01:58 PM Read More
Calendar
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
Categories
Archives
XML/RSS Feed
Comments powered by
Statistics
Total entries in this blog:
Published On: Dec 22, 2004 11:03 AM
Published On: Dec 22, 2004 11:03 AM