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?
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:User talk:Chase-san/Roboflight/Revisit/reply.
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.
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.
Actually I sort of made it kind of a zero-g 3D based system. The old version was going to be an actual flight based system, I even had front-back, rotation and so forth.
But I decided for a game that is suppose to be fun to play, that it wouldn't be with that. I removed all concept of front, back, top, bottom, left and right to simplify things.
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.