Building and programming robots! Despite all the things I list below, how cool the concept is almost makes up for all of the 'not-fun' bits. Total freedom to build a robot in whatever configuration I want, with none of the things that make me not able to do it IRL (costs, fabrication difficulties, part availability, blah blah blah)

Not Fun

Poor 'complexity' management with coding: Working on bots for the ACL (and other similar challenges) really makes you realise how poorly complexity of the code scales, or to be more accurate "Well that escalated quickly." And that's not even taking into account how the code for autonomous control is significantly more complex than 'simple manual control.'

And that code is only 'shoot near the target most of the time, also try not to slam into walls too much.' There's no part collision avoidance, leading the target or any 'sophisticated behaviors like that. But all that is easy, and relatively simplistic compared to what most people would consider the bread and butter of programming a robot, sequential tasks. Even a simple "Go to a place, do a thing, go to another place" becomes very complicated very quickly, try adding in "if X happens at any point, do Y" and things will spiral out of control.

Poor optimisation: Applies across the board really. Add more stuff, the game slows down. Playing around with small bots on small levels has it's moments, but having a construction sandbox where you can't build big things or play on large/detailed maps does start to feel unnecessarily restrictive once you have caught the hang of how to build and code.

Wonky physics: Probably not 100% avoidable, but there's no reason it has to be as wonky as it is. Supposedly solid connections bend and stretch, making large constructions wobbly (even if said construction doesn't hit the optimisation/FPS wall) and generally impractical

Bot code portability: Couples with the 'complexity' point I made above, it is often relatively easy to make a useful little code snippet. Grafting it into another bot's code however can be a different story, it's often easier to 're-invent the wheel' and create all new code each time.

It's one of the contributing factors (the complexity scaling issue being one of the others) that makes Rawbots occupy an uncomfortable middle ground: It is too complex for beginners or people who want to 'pick up and play' while at the same time making it needlessly complex and fiddly for experienced players who want to do more than make "It's a robot* tank!"

*actually not a robot, more like an odd-looking RC car

I've also been playing a neat little game called Colobot recently, and I think that the programming aspects of the game work really well. While the complexity of the code gets trimmed down a lot by the fact that all of the robots are essentially the same chassis, and perhaps a few too many 'single instruction' commands in the API (like the goto(x,y,z) command, which for over 90% of situations works as-well-as or better-than a scripted movement and pathfinding function would) that do too much, it is perfect for automating those annoying or tedious tasks (like resource gathering, power cell recharging and the like) while you get on with the business of siting buildings or frying alien bugs. But the real brilliance of it is that it is possible to complete the game without writing any code, because every bot you build comes pre-loaded with all the basic control schema to be able to assume direct control of your robots and complete whatever task is required. While not 100% appropriate for a game with freeform robot building, the same concept can be applied. By including a simple way to load code snippets, with an easy method of defining (for example) left- and right-hand side drive motors, even someone with virtually no 'coding' skill (being able to type: #define rhsdrivemotors motor01, motor02; would be sufficient) could get almost any bot with a 'common' configuration drivable within seconds.

Then perhaps you could write a simple 'go to' function that can take a waypoint, or the raycast result of a mouse-click on a map or in the 'game world' and have the bot drive to the point by the shortest route, then as your skills progress you can add terrain-collision avoidance or powercell monitoring to the function, save it and then use it on any bot you have that uses the basic 'GoTo' function by simply reloading the script file.

Of course, all of that isn't really possible with Rawbots VP code, with it's 'hard' links between the physical objects and the code itself, so I don't know how much that can change without making Rawbots not really be Rawbots anymore.

Logged

"Never assume that anything you've never seen before is benign. Most particularly not something that says 'MARINES' on it."

The hardware style VP code does have its advantages, making it fairly easy to construct and understand the low level systems. That is particularly useful for dealing with actuator positioning and logic. However, if I had to pick one, a conventional sequential programming language would let you do more complex things more easily, but some hybrid would be preferred.

Other than the difficulty of implementing complex functions, the wobbly physics is the main problem. In many cases a large part of the control system is there purely to hold various parts of a bot in the correct position.

An autonomous fighter jet is probably a good example. You can build one, but the structure will warp all over the place at high speeds, the control system has no hope of keeping it straight and level, it'll cross the entire map in a matter of seconds, anything the weapons system hits will be pure luck, and anything resembling a strategical control system would take enough code to fill the entire screen.

well crap guys, I think you've literally broken down every aspect of the game right here. I've got nothing left to talk about that hasn't been said, unless I want to start talking about things we don't have / don't exist or comparing to other games!

well crap guys, I think you've literally broken down every aspect of the game right here. I've got nothing left to talk about that hasn't been said

But it is important to get the perspective of different players at different levels of ability. What me or MarvinMan finds fun/not-fun isn't necessarily the same as what you or DrVirus finds fun/not-fun.

Logged

"Never assume that anything you've never seen before is benign. Most particularly not something that says 'MARINES' on it."

To be honest the only thing I have to add is that calling this crude Alpha a "game" is generous by FAAAR. Hell, if I got this as a demo It would still be pretty shallow.

(off topic, but does anybody remeber that D-day style "storming the beach" scene from the original rawbots trailer? I have a theory that was made in ADOBE After Effects, because there is no way they got that to run smooth!)

Considering the game is still in pre-alpha, which I assume translates to proof or concept/technical demo, it is surprisingly stable, especially when you think about how complex the physics and programming systems are.

I think the fundamental problem many of us are facing is that we've run out of interesting things to do. Each new project becomes more complex and tedious, often re-using many of the basic systems that we've build dozens of times before, to the point where it doesn't really feel worth doing. I doubt this is possible to avoid entirely, even Minecraft with its hundreds of blocks and continued development gets boring after a while.

Regarding not entirely in game footage trailers, a threaded physics engine would have been nice to have, as I would assume that the physics calculations scale very well.

It's not a game, but the visual programming system that Labview uses is very good. It's got rawbots style parallel execution of math/logic, but it can also handle looping and branching structures, as well as some more complex timing functions.

Good game : Flexibility and possibilities as well as opportunities it therefore offersBad game : No user friendly interface yet - No goal that makes it more like a sandbox than a game at this stage (One could think of challenges such as the old mindrover game)

The user interface isn't too bad, especially when you consider the complexity of some of the things you can do in the game. The problem is the lack of documentation (although I don't remember ever seeing anything resembling a manual for Minecraft, and that has a massive user base).