So skimming this other thread gave me a related idea:
I didn't want to hijack that thread since this seems like it'd be a different idea.
It's AI related, but also would be a fun project like Chess++ for a team to develop something fun.
When I was a kid, one of the things that got me into programming was this game "RoboWar" I had for my old mac. It basically involved a square area where you'd put in several robots. Each robot had to be programmed in "Robotalk" which was this simplistic stack-based language:
AIM 5 + AIM' STORE
to rotate the turret 5 degrees.
Robots would attempt to locate and fire bullets/missiles at other robots. Last surviving robot would win.
I'm sure there's probably a bunch of similar programs out now. We could probably find/use an existing one... but I think that would take a lot of the fun out of this.
Here's what I'm envisioning:
Robots get a certain amount of "money" to buy their parts. Better parts cost more money. But in the end, all robots cannot spend more than the amount (so if you want to invest in better weaponry, you'll suffer in other areas. It's a tradeoff).
Some ideas for parts would be:
- Wheels/Motor. Better parts would let you move/brake faster
- Cameras. Better parts would let you see further and/or wider angle.
- Guns. Better parts shoot faster bullets
- Alternative weaponry (lasers? mines?)
- Chaff/Fog - something to hide you from other robot's cameras. (would have to be limited use)
Anything that is directional (cameras/weapons) would be turret based, so you'd have to orient it with the robot. Rotating/orientating would take time (doesn't move instantaneously) so maybe higher quality parts could rotate faster?
You could also have multiple guns/cameras that rotate independently.
The robots themselves would be "plugins". I'm thinking dlls (although this wouldn't be portable for those chumps on Linux... maybe they could run in Wine?). The interface would be a small set of functions:
- 1 to do the "shopping" for the robot. It would call back public functions to "purchase" items (obtaining a pointer to a Camera object, or the like)
- 1 called every "tick" in the battle to do a step of AI logic.
That'd be it. Most of the work would be done through the items the robots purchased. So if the logic wanted to rotate the gun to a certain angle, then fire a bullet, it could do something like this in its logic:
if(maingun->getAngle() == desiredAngle)
Where 'maingun' was the object obtained during the shopping step. As this illustrates, rotation is not immediate, and the robot has to poll the current angle of the gun to know if it's pointing where it wants it to point or not.
This makes it impossible to have "illegal moves" like you'd have in a chess or something game, because the only thing the AI here has control over is the parts its using. And if you try to do something illegal with the parts (like fire 2 bullets in the same logic update), the part can simply ignore it and/or return some kind of error.
To prevent robots from "deadlocking", we could run the logic in a separate thread and have it 'timeout' after a certain length of time. If the robot times out, the driving code could just kill the thread and then that robot would just be dead.
The modularity would allow anyone to submit robots by sending a dll (though that would be a security risk, so maybe we don't want to do that?). And in the main program we could match up whatever robots we wanted and pit them in battle! mwahahaha.
If we want to get really fancy we can add obstacles and stuff. or maybe have different "classes" of robots. So high class robots can spend more money, but get matched up against other higher class robots.
I think this would be awesome and would persist among members of this forum for a while. The problem is it's a reasonably large project for a forum where people can only contribute in their spare time... so I don't know if we'll be able to pull it off.
What do you guys think?