Revisit

This morning for some odd reason I decided to work on this again. Now JOGL is dead. So switched over to LWJGL and began a rewrite.

I figure most people would rather avoid 3D rotations if they could help it. So I am considering a redesign that does away with almost all the rotations. Meaning you can move in any direction. There would be no forward or backward.

Would that be more interesting?

In general, I think anything that simplifies the 3Dness is a good idea. I feel like even the trig required for Robocode-like games is a barrier to entry for many folks, and 3D makes that even tougher.

I was actually just thinking about this re: Roboflight the other day. For instance, Quake brought "true 3D", but the gameplay was not dominated by it. Something like Descent was totally 3D, which was pretty cool, but also a bit jarring.

Glad to hear it. It actually simplifies the engine a bit too. Of course I still had to muck about in rotations for the camera. But I see no reason why I should force quaternions on anyone else.

Here is a small sample I did using the current (revised) api. It is basically the RF version of walls. What is more, not a 3d rotation in sight.

https://gist.github.com/Chase-san/4132e0696156d64ca7c5

Saw Roboflight for the first time now. Interesting concept.

I would like if robots mimic some kind of air/space vehicle people are familiar with. Like Robocode robots mimic tanks.

It is kind of shocking how many programming games stick with tanks. I can appreciate keeping it simple - manually controlling a real aircraft in 3D would be pretty challenging, before even getting to any strategy or learning. But I'm sure controlling a real tank would be challenging too.

Maybe helicopters? But I don't know where thrust would fit.

Something I realized in hindsight with BerryBots is that a simpler API doesn't necessarily mean that it's simpler for the client of the API. In many cases, even the opposite. Consider that the "API" (instruction set) of a CPU is a hell of a lot simpler than the Java API, but for any real application I'd much rather be working with the latter. I kept the movement API in BerryBots to a single method to fire a thruster that alters your trajectory, but as a consequence you have to kind of understand vectors to make full use of it.

I'm not saying that you should make a user deal with complex 3-D physics or anything, just that there's a sweet spot.

Well I think vectors is the simplest way to approach 3D movement unfortunately. Though I could make it more like Robocodes movement, where you only move the distance you specify (in a vector).