I realize my past attempt at a new programming game was a pretty big flop (due to the lack of its options).
Rotation currently has no acceleration or limits, meaning right now you can flip and spin on a dime, however the physics inertia, this meaning if the robot suddenly does a 180 about one of its axes and was moving at full speed it will have to work against its own momentum to start to move in the new direction. I hope to change this and make rotation be dynamic as well as have limitations, I think this will make a more interesting game, as the environment is more realistic in its emulation of physics.
Also making the rotations rotate around the robots local axis instead of around the world axis is a bit confounding at this point.
Sounds like it'll be Space-like physics. Makes for a very large PhaseSpace? - targeting using bullets will be near futile especially in OneOnOne with the current way we do things (shoot a bullet almost always when you can) - bots'll need more EnergyManagement to win. I'd prefer to have acceleration with inertia, meaning you could practically boost your way into a high-speed spin, but will need an equivalent amount time to decelerate. (Assuming no limits.) Missiles can be implemented, me thinks, but with limitations on thrust, turning angle, speed and maximum possible travel distance. Makes for interesting dog-fight-like scenarios in some Flying MMOs I've seen. =P --Nfwu
Imagining a null-g fight leads to an interesting thought: a version of Robocode with thruster-based movement. Accuracy would go way up, since reversing direction and such becomes much more difficult. I imagine in a 3D fight the thruster maneuvering would partially mitigate the loss of accuracy from adding a dimension. The direct analog of Robocode as a 3D game would be more like a bunch of guns in a box, being manipulated by tractor beams or the like. --Synapse
Currently, I do have plans for missiles, and I did tests showing at the very least, linear targeting in 3D is possible (thought its a bit more complex than 2D). The missiles would be user scripted and not premade, they cannot tell friend from foe and shouldn't be able to communicate with the main robot, allowing all sorts of 'smart' missiles, thier targeting 'radar' would be about 20 degrees ahead from them. Robots are really what i'm working on right now. Right now there is drag so if you stop thrusting or such eventually the robot will come to a stop, per force that was acting upon it. This basically means there can also be kickback and impact forces from bullets, missiles, bombs and ramming. I did have plans for some simplistic obstacles, but asking an AI to navigate around even basic geometric shapes (spheres, cubes, and so on) is asking alot.
I didn't think about tractor beams, its an interesting idea indeed, the forces they produce would probably decay as distance increases, I think I wouldn't have specific tractor beams (repel, pull, hold), but ones where you hav to define the forces you want to apply to the other ship, such as in a 3d vector, such as appling the velocity <5,1,1> to it, however due to the decaying nature of the beams it would be normalized internally and the force reapplied.. Also the problem of targeting the beam itself, meaning you would need an end point, a force vector and a total magnitude you want to apply to the beam.
If such a feature was included, obstacles could be more of a weapon themselves, assuming you can excert enough force to move thier mass. Flinging obsticles or pushing other robots into them could produce some rather nasty damage. However the collision physics will be interesting to do, which revolves around finding when two objects intercept, getting each of thier advancing velocities towards on another, thier mass and applying each others force to the other divided by ther mass using some arbitrary multiplier, and then applying damage (damagable and fragmenting geometry? at best probably asteroids style), also his means I need to apply forces for stationary objects intersecting each other. I wasn't planning to make such a complex physics engine.
Anyway, I need to get ready for class, i'm more interested in how to rid the game of the half-turn advantage and how to make it so I don't need to use a loading system simular to robocode that requires you to extend a certain internal class, I was considering some sort of port communication (meaning robots made in other programming languages could compete).
--Chase
Small extra thought, if there are obstacles, espcially massive objects should have gravity (actually all objects should have gravity, but most of them are so small its pointless to actually calculate). If I do include gravity on everything, means you could hit a enemy robot by taking advantage of gravity wells, and basically bending the trajectory of the bullets. Also bullets will probably be a bit more mindless, being able to fire more, faster and with a much larger variation of aim. but I want to hear your thoughts on this, because I want the game to be fun to program for, and not so realistically complex that its annoying or just plain impossible to program for. --Chase
For an idea of how to display, how about providing a top, front, and side view? It would be easy, you just paint using the xy, xz and yz coordinates. Additionally, I think adding missiles/tractor beams/gravity is getting way too complicated. Just having a 'drag' component that limits your maximum velocity, and causes you to come to a rest (in space, that is) when you stop applying thrust. Also, how about only being able to detect the enemy's life only within a +-10% accuracy, ie. it fluctuates from reading to reading; I think it would be much more fun (and realistic) to do 'bubble-surfing' by detecting kickback from the gun. And another idea: how about a sort of 'cumulative rolling average' gunheat, so you can wait a long time then fire a whole bunch of bullets, or just fire continuously at a medium tempo. I still think it's a good idea for bots to lose life when they fire bullets, but adding the kickback makes it so that if you are desperate you can temporarily increase your velocity by firing behind you, until you run out of life, that is. Another gripe I have with robocode is being able to detect when/if your bullets hit the enemy via events. That's not very realistic. Rather give them a kickback. Anyways, just my take on it =) -- Skilgannon
Just thinking, you could do a sort of isometric projection to get the 3D into 2D. There's a fairly simple double-matrix operation on [Wikipedia] for this, but I derived it myself and got a simple single-matrix operation which should work to transform a 3-space point into an isometric 2-space point: {{-0.866,0.866,0},{-0.5,-0.5,1}} Perhaps by drawing the outline of the 'cube' in which the bots fight, and showing using crosshairs where the bots are on each axis, you could position the bots using this@ Even painting would work, you just need to transform every single point using this matrix. -- Skilgannon
[Java 3D] - I've never used it, but I'm guessing they use system calls & such for speed. -- Simonton
I am already using Java3D, so no worries. Its vecmath library is very useful. --Chase
About the rotational inertia, how about just using a setRotateRight?(angle) setRotateUp?(angle) setRotateClockwise?(angle), and like robocode, limiting the amount they can move on each axis per tick. About the 1/2 tick advantage, how about randomly determining each tick who gets processed first? Or copying any dead bots into a 'dead' list and only removing them when all bots have been processed. -- Skilgannon
I like the dead-list idea, as for the first bit, its not the limiting that is the problem it is the rotation itself, as I want to rotate the robot locally, meaning setRotateRight?(5.0*(Math.PI/180.0)) would rotate it 5 degrees around the robots z axis and not the global z axis. Local axis, the X points from the back of the robot towards the front and is the direction in which the main engine functions, rotation around the x axis is the roll. The Z axis goes from the bottom of the robot to the top and rotation around it is its yaw (turning left and right). Finally the Y axis goes from the right side of the robot to the left, and rotation along it is the pitch. --Chase
Ah, gotcha. And how about using the airplane terms you mentioned for the method calls, ie. pitch, roll and yaw? It could clear up a lot of the confusion =)
Yeah! Wikipedia has a section on nested dimensions on their Rotation Matrix page:
![[Home]](/images/RoboWiki.png)
c = cosA
s = sinA
C = 1 - c
rotated around unit vector U(x,y,z)
the rotation vector would be:
{
{x*x*C + c, x*y*C - z*s, x*z*C + y*s},
{x*y*C + z*s, y*y*C + c, y*z*C - x*s},
{x*z*C - y*s, y*z*C + x*s, z*z*C + c}
}
Glad I didn't have to derive that myself =) Wikis are too cool =) -- Skilgannon
Sorry I haven't commented, I was very surprised to find that college was bogging me down, but I have some time now. I all work on making a demo version of this for you to look at, unfortunately I don't understand how the 3D rendering works in Java 3D so i'll have to take some time out to figure that out then to draw some wireframe boxes and such to represent the robots so you can actually see the battles. Currently I have it coded to work on a 1000m cubed field and when you fly over a boarder or simular you warp over to the other side of the field (I am a little lazy and don't want to come up with the collision equations), the bonus of this is that the bullets fired at a linear tajectory will hit the robot if it continues on its current path no matter what (since it warps over perfectly).
Currently you have to hard code robots into the code and it has no protection on the internal functions, at this point my concern is getting everything to work, and at such point I can do the fancy stuff like class loaders, internal security, robot timer (so it doesn't take to long on its turns, ergo infinite loops), and simular.
-- Chase
Still working on getting Java3D to cooperate with me, however I think the time is well spent since I learn something new. --Chase
Yeah, this is actually on the back burner. The actual battle engine doesn't work right now due to a fun NaN error I haven't gotten around to tracking down. Java3D is a bit confusing to me so I will spend more time on learning it later, but right now I am focusing on 2D graphics so I have a better grounding. I have built a basic 3D Engine from scratch before, if it comes to pass I can't figure out Java3D I might pull up the old code I used in that project. But in that case it would be limited to wireframe. I can't even imagine full 3D rendering and texture mapping over software.
If anyone is genuinely interested in this I will make a sourceforge so that if someone feels up to the task they can work out the Java3D.
--Chase