User talk:Chase-san/Roboflight

Well if anyone has any suggestions, I am open to them. My classes are finished up. --Chase 21:34, 21 May 2010 (UTC)

It is still missing a lot, the rules here don't exactly cover it perfectly. I have some of the missile system written. and a lot of the robot api. (I in fact moved my robots outside of this to use the api). I included the source as well. It is probably getting a little messy, but I have javadoc and comments (many wasteful ones in older classes) in there. JOGL Libraries Core Test 3. For those who cannot get it to run (for whatever reason). It currently looks like this.

http://www.csdgn.org/files/images/rfscreen.gif

--Chase 19:07, 9 June 2010 (UTC)

It seems that you forget to pack the resource/sphere32.obj. I got FileNotFoundException! --Nat Pavasant 11:49, 10 June 2010 (UTC)

Whoops, those are important. Added, they are in the same place. Sorry about that. Other news, I am currently writing the collision system (Fun!). --Chase 16:29, 10 June 2010 (UTC)

I noticed I had a lot of dead code, poorly designed classes, and things that cannot possibly work strewn through the code. Basically a great deal of my laziness is showing in the code. So, I am refactoring it a bit. After I am done with that I might make a source forge repository for it. --Chase 14:41, 12 June 2010 (UTC)

Please no SourceForge -- it is REALLY slow =) Google Code, BitBucket or GitHub is around 10x faster than SF.net --Nat Pavasant 14:59, 12 June 2010 (UTC)

I might have a look at Google Code. I don't feel like dealing with GitHub's SSH key insanity. BitBucket I don't have Mercurial built into eclipse (yet). Anyway I have done away with the old object rendering method (which is really slow) and replaced it with vertex lists (but not VBO, JOGL doesn't seem to like to play nice). I decreased the near clipping plane. Rewrote the peer system and the way the missiles work. I also (finally) added a texture to the robot model. I may yet replace the current model with a better one however. Though I am trying to avoid using too many polies. If someone else wants to make a 3D model for it, all it needs to be is obj and under say.. 1600 polygons (current ones are around 800ish). --Chase 20:37, 12 June 2010 (UTC)

After a bit of poking, I decided to use BitBucket. Mercurial doesn't seem that bad, and has an Eclipse Plugin. http://bitbucket.org/chasesan/roboflight --Chase 20:08, 14 June 2010 (UTC)

Well, I have a working version here. Whats new, off the top of my head... Classloader (that surprisingly works), basic collisions, missiles, bullets, battle start (you can only start one yet). Selection pane, and you can even include try your own robots in it now (see classloader above). Many of the core bits of the robot are still not in, or rather not back in (as I removed them for refactoring). Random starting locations are also, not in yet. (no real battling can be done due to this and lack of robot/bullet robot/missile collisions).

On the subject of collisions, the sphere sphere collisions I am using are nice, neat, and fast. However sphere box collisions are not as much so. So this leaves three options. Make robots have a spherical bounding box, change the bullets and missiles to use Orientated Bounding Boxes, or Find a more efficient collision system for them. (a sphere oriented ellipsoid would work, if I could figure out the math).

Core Test 4 JOGL Libraries

--Chase 06:23, 21 June 2010 (UTC)

A new core build is done, all collisions but robot/robot collision is done. I finally got around to refactoring the text, it is much better now. The program suffers a few lags here and there, not sure why yet (at least it does on windows). Missiles don't yet have an explosion radius, but they do damage when they hit. As do bullets. Bullets and missiles can collide. With each other and others of their own, they die when they hit. You cannot yet collide with the edge of the outer sphere, this will be simple to fix. Energy doesn't regenerate yet, but it will soon. There are so many TODO's in the source code, which still need to get done. So forgive me for not getting all the 'most important' things done yet. Actual rounds and how scoring will be done needs to be decided soon. I also need help in figuring out how to load multiple instances of the same robot.

For the most part the game is nearing the 'usable' stage, and thus alpha. The next build will probably be Alpha. I am still using bitbucket, and I have been updating it.

Please tell me what you think so far.

Core Test 5 JOGL Libraries

— Chase-san 21:49, 25 June 2010 (UTC)

I think that the lag you mentioned is caused by Java GC. I think it is quite good, but I'm not sure how to hit each other (your samples can't hit each other =)). But I think I found some bugs. When I start first battle, I choose two Simplex. Only one is put in the battle. So I start new battle with one Simplex and one Rotator, but two each appeared (4 robots) in the battlefield. Cheer! --Nat Pavasant 04:47, 26 June 2010 (UTC)

Yeah, I knew about that bug. Two of the same robot cannot be entered, when I get that fixed it should also fix the problem with the new game. As for the samples hitting each other, Simplex actually can, and will hit a stationary target. However, Rotator isn't stationary, so it usually misses. Rotator just shoots randomly and it sometimes gets lucky and lands a hit on Simplex with a bullet. I suppose I should make a sitting duck like sample. — Chase-san 15:41, 26 June 2010 (UTC)

I'm pretty sure the lag is not the Java GC.... I just tried it and ran into memory used by the system memory use exploding out of control and for some reason it wasn't being freed for program memory, then forcing the machine to swap wildly and nearly lock up. I'm pretty sure the cause of that here is the same as the cause of the lag there. Given how I wouldn't expect this from normal Java code and that it was not normal program memory, I'd suspect something is going terribly terribly wrong in the opengl code. Note, this doesn't occur here in Core Test 3. --Rednaxela 16:47, 26 June 2010 (UTC)

That is very informative, I completely ignored memory usage since I was using Java. Usually resolving memory leaks is only something I need to do in C/C++. Though there might have so memory that is being held onto for some reason in the Java sections. Core 3 was before I refactored. So I will examine the difference between Core 3 and Core 4/5. See if I can figure out where the leak is. — Chase-san 17:37, 26 June 2010 (UTC)

Well just to clarify, it wasn't memory held by the java process, it was memory held by the kernel or something I think, thus I'm pretty sure isn't a Java memory leak, but more like some opengl resources that aren't being disposed of properly or something. --Rednaxela 17:52, 26 June 2010 (UTC)

Yeah I just noticed that, while monitoring the Memory used by the runtime. I will take a look at the GL code, it might be the vertex lists that are causing the problem. (which I didn't use in core 3, but are only in core 4 and 5). Strangely the runtime only uses 16 mb when run from Eclipse, and about 60 mb, when run standalone. — Chase-san 18:01, 26 June 2010 (UTC)

I figured I should try and get some input from other robocoder on this game.

I was wondering about thrust. Should be constant: If you set it to [1,0,0] it will remain that until you change it. Should it zero out: If you set it to [1,0,0] it will apply that thrust and then zero out the next turn. Should it deplete: If you set it to [1,0,0] it will apply that thrust and be reduced by however much was used (based on maximum thrust).

Currently it zero's out, and depleting thrust would be more similar to robocode, and would also allow you to set it to the inverse of your velocity to have your robot come to a stop without having to set it again.

That is assuming of course I do not add some kind of drag. I kind of like the frictionless feel of the current simulation, but that doesn't mean everyout has to agree with me on that front.

The missiles are the most difficult. I want to make them versatile but not too versatile/dangerous.

I figure there are two things, Yield and (possibly) Fuel. Unlike bullets, I would want them to be detectable by radar. But I also want the robot to be able to control them (this is simple enough). But I want them to possibly be able to stop and act as mines (and disappear from radar). But they would be easy enough to avoid in theory if the enemy just memorizes the position they were last at. But I also want them to possibly just disappear at some random point in the field (to the robots) without that area being considered dangerous. I think bullet missile collision might be the best way to achieve this. But that would only work if there were more then 2 opponents (since if you didn't shoot it, and your enemy definitely didn't then it must still be there). Etc ad nauseam

So any thoughts?

I like zeroing out thrust every turn. My feeling is this is both the simplest model and the one that any moderately advanced bot will use anyway (most Robocode bots recalculate movement every tick), so why not keep your API simple and make it the only model.

My first thought is that drag sounds not fun and not that interesting a problem either, but there are good reasons you might want it - e.g., to keep max speeds in check, if you think that would be good for gameplay.

Your thoughts on missile behavior sound interesting and like a big change from Robocode, which is cool. Will there be any limit to what you can see on radar - e.g., walls obstructing it, distance, etc? That would play interestingly into the invisible mine thing, like being able to move your stuff around when you think the enemy can't see it. Incomplete information is a pretty powerful gameplay dynamic, and without it you risk creating a "solvable" game, especially with computer players.

I think my biggest advice is to be vigilant about only adding complexity that really multiplies the gameplay depth. I posted a bunch of thoughts about this in BerryBots vs Robocode game rules.

Chess is a good example of a game that probably gets it just right. Each type of piece multiplies the complexity, and the result is a game where the greatest human minds, with tons of practice, can almost play it perfectly. Any more pieces and it would become too complex and even less approachable, and any fewer pieces and it probably would have become uninteresting ages ago.

I was only referring to only one kind of movement, I was asking an opinion on which one in particular.

You have an interesting point. The 3D by itself already makes the game fairly complex. However compared to the original version it has been greatly simplified.

Currently the radar is an 'all seeing eye'. It can't see bullets, but I could see it being blocked by a robot, since missiles are 1/3 the size of the robots that fire them. So an enemy could fire a missile opposite of the enemy, cover it till it stops and then lure the enemy towards it, or wait for them to approach it, and reactivate it, or possibly several to flank an enemy with mines.

That actually sounds awesome, and as long as missiles/mines are not one hit wonders, it should work wonderfully. I think 8-16 damage (4-8 to fire), with a limited fuel supply is best. I don't want it to overlap with bullets, which at the moment cost 0.5, and do 2 damage.

Though I think limiting the number of active missile a robot can have might also be an good idea. But that requires a way to disable them, or rather remove them from your control so you can fire another. But perhaps they could still work as passive mines.

On the note of missiles, since they can navigate. I think you should be able to hit yourself with them (after a few ticks to activate).

After much consideration I decided to go with depleting thrust, so that you can do things like this.

//Lay a mine
Missile m = setFireMissile(new Vector(1,0,0));
if(m != null)
	m.setThrust(m.getVelocity().scale(-1));

or this

//thrust towards center for 4 turns
setThrust(getPosition().normalize().scale(-4));

This will allow smaller robots by making the thrust system easier for robot creators to use, while not impacting those who want to change it every turn. If you set a thrust, it replaces the current thrust, just like calling setAhead(-100) replaces the previous setAhead(100) call.

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.

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.

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).

I threw this up on GitHub (finally), so if your interested you can browse the code at your leisure. I know I can't usually be bothered to download things to look at the source, so why would anyone else?

Enjoy, I may continue working on this soonish.

Haven't browsed much yet, but wanted to say congrats on the milestone anyway. :-)

There isn't much there yet. But in a few milestones people might be more interested.