The basic approach I have in mind is to generate a bunch of random controller sequences, see which ones fare best, mutate/crossover/etc, and repeat. I know there’s a lot of parameters and strategies to choose from in there, and I haven’t yet decided just how I’ll approach it.

Right now, my fitness functions are going to be pretty simple. From a purely implementation point of view, it wouldn’t be hard to make it a lot more sophisticated. However, I have no idea how to put a GUI in front of something like that without making it completely arcane.

Besides, I’m curious how far I can go with even a simple approach.

Also, I am doing primarily screen-scraping to evaluate how well a controller sequence does. What would be cheating would be giving it access to the game’s internal memory and variables and anything else you as a human sitting in front of the TV don’t have available to you. (Plus, it’d be a nightmare from a usability standpoint — just how is the user going to figure out where and how the score is stored?)

Why not just make it “win” vs. “die”? I mean, sure, your’e restricting the project to finding a solution from a more restricted solution domain, but it would make defining the fitness function more manageable (I would think)…

I don’t know… maybe not… just figured I’d ask “why not?”…

There are many other things you might want to consider during implementation, that while not definatively necessary decrease the likelihood of getting stuck in local minima/maxima. As an example, you might consider the use of automatically defined functions (with the only downside being the potential complication of crossover and mutation) or reinsertion (though here you need avoid problems with what Excel terms ‘circular references’; not to mention the same crossover / mutation problems when nodes changes). Also, there’s some debate (since its completely up to the programmer) as to how to select individuals (one ranked based on fitness) for crossover / mutation / inclusion from generation to generation.

Are you going to try to find a ’solution’ for the entire game during a single run? I would imagine that it would be more reasonable to break it into multiple (and independent) solutions for each ‘level,’ with recombination at the end. This might also aid in the application of a fitness function.

Admittedly, I’m not sure the best way to determine the fitness function. But could you be more specific on why you think screen-scraping (I admit I had to look up what that meant… where’s my wikipedia link?!) would be ‘cheating’? Also, while it would include getting back into the code, could you not simply include ‘markers’ in each level to use, well, as markers (i.e. milestones) and include that in the fitness function?

Look at the bright side of this application. Depending on how you look at it, either your function set or your terminal set is already provided (*cough* exclude start&select for god’s sake *cough*), and there doesn’t appear to be much need for the other. And at least your termination decision is easy, so you don’t have to worry about generation limitations.

Are you going to try and analytically determine a sufficient population size, or are you just going to start with a fairly large yet arbitrary number? Some ‘experts’ (or whatever you want to call them… writers at the least) think that the benefit of a large population diminishes as populations grow, though I haven’t spent the time to see if anyone empiracally support any estimation as to when this occurs… theory bastards…

I look forward to when you write about progress with the program, even if it’s only utilizing a temporary fitness function. Get to work!

Koza would be intrigued I’m sure…

Addendum: both http://www.domoariga.to and http://www.mrrobo.to are available… yeah… i went there… i do have to say i’m a fan of capt. derivative… he’s not cool unless he has postulates, though…

Long answer: You’re right, my approach is more along the lines of the weasel program, although here there’s not necessarily only one “ideal” solution, and even if there is, it certainly isn’t known ahead of time.

Or, in other words, my approach is searching for a rote solution, whereas a strategy more in the spirit of true GA would be to find an algorithm or heuristic for choosing inputs in response to changing game state — finding something that knows how to play well, rather than stumbling across a series of moves that happens to work.

I’m really not even sure how you’d go about doing that. What would the organisms look like? Something like neural nets, I guess? I’d definitely need to do some reading to even figure out where to begin with something like that.

I suppose the organism could also learn about the game state by screen-scraping, just like a human player does. In theory you could point it to the emulator’s internal state instead, but (a) that lets it cheat, and (b) that requires deciphering a lot more of FCEU’s guts than I care to do.

Interestingly, though, I don’t think this has any impact on how you define a fitness function! The fitness function only really cares about the end result, not how you happen to get there. My current implementation just watches whatever’s playing, after all — it doesn’t care who’s providing the controller inputs.

Now I have the urge to pit a population of rote-learners and a population of neural nets against each other, and see if one drives the other to extinction. Curses, you just found a way to make this little project even more interesting!