Introducing nanite_fight

I'm trying some new things.  I'm trying to get out of my object-oriented comfort zone.  I'm trying to implement a kind of proto-language whose elements are all first-order functions.  Learning new things is good.

I'm trying to constrain everything in nines: nine nanites, nine instructions per function, 9 * 4 instructions (9 function calls, 9 actions, 9 control structures, 9 sensor inputs).  The game has three nine by nine grids, each kinda broken into nine three by three grids.  The goal is to take over all nine nanites, at which point all your code will be running nine times.  So I think I meet the theme.  That's good.

I think that this can be fun with really simple graphics, which will save a lot of time, which is good.

I'm paying a lot of attention to the idea of "emergent complexity".  36 commands is a lot, but really all you can do is drag an instruction onto a square.  If there are multiple nanites following the instructions, that's a lot of multiplication.  So that's good.

I got a lot of the framework done pretty fast today, and have a pretty good idea of how to do everything, so it's feasible, and that's good.

I'm not sure how long the control side of the model-view-controller setup will take.  In the past I've struggled slowly with building drag-and-drop interfaces, so I could fall behind there and not finish.  That'd be bad.

I'm not really sure that nine nine-instruction functions will be enough to do anything interesting.  If not, that's a clear way this game could suck.

-Shanti Pothapragada