Archar

[paulscode]

Background

I have been playing around with an AI concept for years (one of several "cool idea" projects I'm working on).  It is a text-based contextual learning engine which is capable of picking up grammatical sentence structures very quickly, and using that information to generate random grammatically-correct sentences in response to input sentences.  The context of the sentences it produces is randomly related to the words contained in the input sentence (so if a user types a sentence about cats, the engine might respond with a sentence about cats, animals, fur, etc).  I've decided the engine has reached a high enough level of stability that I can start using it in projects.


Project Concept

Archar (an acronym for Artificial Character) will be my first project utilizing the engine.  It will be an applet consisting of a 3D character which you can talk to through the microphone and it will talk back to you through the speakers.  I will accomplish this through speech recognition to convert what the user says into text, and then speech synthesis to convert the engine's output into audio.  This audio will need to be synced with the facial animations of the head.  jPCT is perfect for the 3D applet piece, and I've written some synchronization methods into my sound system which should be useful for this project as well.

[fireside]

Wow, sounds kind of complicated.  I'll be interested in seeing how that works out.  Were you planning on using it for games eventually, or something else?

[paulscode]

Were you planning on using it for games eventually, or something else?

My ultimate goal is to put it into a toy which children could have a real conversation with.  The idea first came to me after being utterly disappointed with a toy called Furbie back in Christmas of 1998.  There was a huge hype about how kids could teach it to talk and have real conversations with it.  This turned out to be a total crock of ****.  In reality it was merely capable of fake learning - i.e. it learned exactly the same things at exactly the same time regardless of what the kid playing with it said or did.  He could be talking in Japanese, and the damn thing would still "learn" English.  I vowed to one day make a toy that could ACTUALLY learn to talk by listening to the child..

In the mean time, I want to use it in a few projects to get people interacting with it and hopefully address any problems before trying to pitch the technology to a toy company at some point in the future.

[raft]

sounds like quite an interesting and challenging project..

just for curiosity, are there any toys out there which can run a JVM?

[paulscode]

Not sure, but I think Leap Frog would be a pretty good place to start researching, though.  Their products are starting to become pretty advanced.  I recently bought a toy dog called "Scout"  for my son.  It has a USB port to allow customization like programming the child's name, favorite things, songs, etc.  And their hand-held devices are also pretty advanced.

[raft]

in near future android may also be an option for those devices. i've read android is expected to spread to non mobile/telephone devices.

[paulscode]

Speaking of Java, that brings me to an important question.  I have started porting the engine from c++ to Java, firstly because jPCT is Java, but secondly because that is the most likely environment it will ultimately be running on in future projects as well.  My question is about preventing people from stealing the engine for use in their own projects.  Despite the fact that my recent projects have all been free and open source, I am not one of those anti-intellectual-property zealots.  I would like to maintain sole control of the technology, at least for now.  My initial thought is to hide interfaces to the engine in internal private classes and methods.  Does anyone know how secure this is?  How difficult is it to partially reverse-engineer Java byte-code to access internal methods?  The program would not have to be completely reverse-engineered - merely changing the interfaces from private to public would give someone the ability to utilize the engine in any project.

I suppose if I was completely paranoid, I could interface with the engine via a Perl script server-side, and have the applet communicate with it over a secure encrypted connection.  Of course, that would be a lot more work, and perhaps a bit of overkill.

[EgonOlsen]

Almost all byte code can be decompiled unless you run an obfuscator on it. The obfuscated byte code can be decompiled too, but it will look messy enough to scare people away. The downside is, that some vms may have problems to run it.
To be honest, i wouldn't worry too much about this. Just keep the sources closed and maybe add some simple license key stuff or similar.

[paulscode]

After some additional thought, I've decided to leave the engine in c++ code for now, and modify LWJGL's Applet Loader so it also deploys the native engine libraries along with all the other native libraries that it already has.  That way I can access the engine from the Java applet, without actually having it deployed as Java byte code.  Once I get the applet working at some point in the distant future, I'm planning to port the project to the Android which will also let me deploy the engine as a native library.

[Disastorm]

wow this sounds amazing, is there any demo of this yet?

[paulscode]

Not yet, I've been a bit obsessed with another project I'm working on (a Nintendo 64 emulator for Android).  I tend to cycle through my projects as I get burned out on them so I'll eventually get back around to this one.