The Ur-Quan Masters Discussion Forum

Hi guys,

After starting to learn Java this year in my first year of Uni, I've been working on a number of small projects. I've previously worked in VB and C, so coding for Java hasn't been too much of a stretch for me.

One of my projects was the result of a few minutes idle chat with one of my fellow course members. I've previously tried to make a Super Melee clone in C before a few years ago (which was an absolute disaster, as I had no game experience at the time and used far too many abstraction libraries), but my latest project is slightly different.

It's a space game *similar* to Super Melee, but as basic as you can get. All ships are represented as circles, no collisions between ships (yet), etc - but it does allow for different teams, health, etc.

However, the real point of the project is for AI development. Unlike all the games out there, this one's designed for all ships to be entirely under AI control - so you can pit your own AI against others to make it a programming skill test rather than a piloting skill test.

I've only just started on my own AI, but I thought I'd post it here just in case anyone else wants to give it a go - it's quite simple. Also, by all means critique my code.

Before anyone yells, the "IM" (Immutable, without mutator methods) versions of the classes are there to seal off the AI from the game logic. It could of course have been done with inheritance, but using seperate classes created at runtime prevents any cheating. As it's all AI controlled, real-time speed is irrelevant anyway.

Download: http://www.fourwalledcubicle.com/files/Space.zip
Screenshot: http://www.fourwalledcubicle.com/img/Blog/Space.gif

- Dean

D'ya hear that? Listen carefully. It's the sound of nobody responding.

See, the folks on this board aren't, generally speeking, programmers. Mostly we just glom onto the talent of others, groupies as it were. Now, don't get me wrong, being a groupie is fine. But when you visit the forums for a web-comic for another series of games and see people making tons of original, fan made, playable, polished games... well, you tend to realize that there's something about star control that just doesn't inspire.

It's sad, but seriously, move along, pal. Move along.

Ouch. Well, ok, guess I'll just go back into lurking.

- Dean

And those of us who are, suffer from a lack of spare time. I've been toying with the idea of writing an AI for UQM, but there's so much else to code. :D

I don't think that was very nice of guesst. A new person comes out of lurking, and the response is basically "go away".

I think it's a nice project, though I don't have the time to play with it myself.

I also think it's a fine idea for a project. Sadly, I have three full-time projects myself
outside of work which take up any spare time.

I also think it’s an interesting project, and think guest is out of line, but don’t be shocked by anyone’s apparent lack of interest. Back when I was still actively working on my clone I couldn’t even get my friends interested in playing it, let alone their help in making it.

Don’t give up on the project just because of a lack of interest. Any kind of project is a great learning experience and in some cases looks really good on a resume.  Sometimes they don't but they are good for avoiding bad jobs, like I was once asked why I didn’t give any information on the 'open source' company in my resume.

Guesst, at least let it fall off the front page before saying something like that... you did it in 38 hours. These boards are not fast-paced.

I think it's interesting. Reminds me of RoboWar, which is cool. I might even write up an AI to fight yours. Maybe. I have another programming project. The problem is finding anyone who's decent at programming who doesn't.

Yeah, despite being about a million times larger than the SCDB, this is still a fairly small and slow board. But it's nice to never have to go looking for interesting threads from yesterday at page 2.

I've had a course in C, but this looks much to complex for me, sorry. Though if you want me to organize the project for you according to ISO standards I suppose I could help :(

Aw, man. Jerky guesst has been making a comeback. Sorry about that.

Listen, you want people who can kick your can at super-melee, you're in the right place. We'll gladly discuss the finer points of the Utwig mask tradition and Lovecraftian references in Star Control's history.

But as for responding too quickly, hey, prove me wrong. So far nobody's stepped up. I seriously doubt anyone on these forums will. If you want actual programmers who could do this sort of project I'd say check out www.retroremakes.com/forum2 or the forums at www.tigsource.com . Those forums have been awesome in my trying to modivate myself to get back into programming. (I haven't yet, but it's coming soon, I'm sure).

I finally got around to downloading this and checking it out.

I'm not going to write an AI for it because it doesn't seem like an interesting game at all. Because the ships have complete knowledge, the game should degenerate into a stalemate at long range, where each ship could dodge all the shots of the other. At short range, it should degenerate into a contest of who can hit first. Close range is hard to achieve in the first place, since the non-relativistic shots reward the ship that sits back and waits for the opponent to approach.

Ok, I'll just continue versing my fellow CS students. No problem.

Elvish Pillager: The AI's don't have *complete* info on the other players, but they do have a reasonably good picture of the others. What knowledge exactly do you suggest I expose about targets to the AIs? Currently you can only see their team, heading, velocity, position and ID number - all the things (with the exception of the last, which is used to keep track of the same ship across multiple AI calls) that would be visible to a human player.

I'm working on getting planets (and associated gravity wells) up and running now. From then on I'll add in asteroid collisions, etc to bring it more in-line with the SC2 melee to make it more interesting.

- Dean

Uh, what can't they see?

Not a whole lot else, but that's not an argument for removing any of the parameters. Can you suggest any of those I should hide from the AI routines, without removing the ability for the AIs to actually function?

The only one I can think of would be to remove the velocity and force the AI routines to calculate it themselves. That won't make too much of a difference however as the same values would be returned.


Quite honestly I'm suprised not at the lack of interest, but the amount of hostility here. This is my first attempt at a real game (if not in the conventional sense due to the fact that it's deliberatly AI-only) and I was hoping for a little guidance from what I *though* was a nice community.

Uh, doesn't UQM also give the AI player essentially complete knowledge? In any case, allowing teamplay could address these concerns by giving a co-ordinated attacker an advantage again.

I've played several AI-programming games before, most notably RoboWar (http://robowar.sourceforge.net/) - a game where your robot never gets to execute more than 50 instructions each frame and isn't completely guaranteed to be able to tell where the opponent is at all.

Such a game is defined by the limits on the AI. Another example: In principle, I could write an AI that calculates every possible series of moves for the rest of the game and uses game theory to determine the best possible move. It'd take forever, but in principle, it would always win at least 50% of the time. Sure, that's an extreme, but with the relatively naive processor-sharing system your game uses, part of the game is a contest of willingness to use more processor time.

Yes, and it also gives the AI player free rein to cheat as much as it wants to. :P

For the purposes of this comment, two factors differentiate UQM from this game: First, AI writing is not the point of UQM, and second, UQM's melee is much more strategic - while this game would probably degenerate in much the same ways I described if human players were playing, either.

Ah well, it's at least helping me learn how to code in Java properly, and learn how to write a working game. Perhaps after this I'll go for a more interesting (human-playable) game.

Adding game elements is pretty easy - I already have code for an arbitrary number of planets with different masses in my latest working version code. However, I've run into a small problem that perhaps the UQM coders could help me out with.

My planets each have a mass (and radius, which is used for collision detection), as do each of my ships. I've tried using the "true" gravitational equation for force exerted on an orbiting object by a planet:

    F = (GMm)/R^2

Where G is the gravitational constant, M is planet mass, m is ship mass and R is radius (distance from the planet).

To save on computation time, each planet also has a maximum "field of influence", inside which the gravity attraction is calculated, and outside it is not.

However, I can't seem to find values that give a good play experience - it ends up with either almost no attraction until the ships get in very close, or far too much and they're accelerated by phenomenal amounts. Any suggestions on how to make it more playable?

- Dean

One thing you could do to fix the processor stealing would be to give the physics and each AI its own thread, each of which has lower priority than a master thread.
Each of the AI threads is a nontrivial class with member fields corresponding to the instructions the AI can give to the ship.
The master thread divides each frame into two parts which are for the two AI's, and one for the physics.  It lets each AI run for an equal amount of time, then yields its thread.
When both sides have gotten their processing done, the physics takes over, advances a frame, with each AI's instructions being whatever it left in its member fields.
Rinse and repeat, but next time make them think in the other order.
Not perfect, but at least subjects each side to the same random influences.

As for gravity, crank up MG to keep the force nice and big, and crank up the radius of the planet to keep ships out of the region with high tides (i.e. regions of rapidly changing gravity force).

Once you have decent gravity, that may add enough strategy for it to be interesting.

if not, one thing you could do to fix it would be to have each ship be able to get into one of a few modes. The mode would be secret information. Changing mode would prevent firing for a while.
Modes would be hard-coded into the rules. They could exchange range, speed of shot, power, and flexibility in aiming. These would make the game less symmetrical, and enable some moment-to-moment asymmetry with a minimum of programming effort.

Would you be willing to  post some pseudocode  or a very general outline of some AI ideas you have in mind?

Thank you, that's the sort of help I was looking for. I'll have to play with the parameters to get it realistic.

I've done a bit of code rework, to make it easier to code for. Now all "collidable" objects implement a simple ICollidable interface, so that two objects can be passed to Collisions.HasColided to test for a collision. Both IMVector and Vector also implement an IVector interface allowing the utility functions in Vector (Cross Product, Dot Product, Angle, etc) to work on either type.

As for the time slicing - it's pretty much irrelevant. For each game cycle, the system takes a snapshot of the game field and passes it to each AI in turn. Since it's all AI controlled the time taken to process each frame doesn't matter, as each AI gets the same informatio per cycle - that is, the second AI cannot see the action just taken by the first for the current frame, etc.

The one problem I do have, is with the passing of the data to the AIs. I was going for making it uncheatable by making seperate IM (Immutable) versions of the ship/bullet/team/etc objects, so that the actual game data couldn't be altered. Using subclassing would have worked just fine, but doesn't prevent the user from just casting back to the main supertype and fiddling with the data.

However, while the current solution works mostly, great, there's nothing stopping the AIs from messing with the IM arrays, and preventing the following AIs from seeing the correct data. Can anyone think of a solution to this? I could clone the IM array for each AI, but that seems rather crude.

- Dean

I've updated the zip on my site with the latest source code. I've added in vector operations (damn Java and it's lack of operator overloading!) as well as planets, gravity, collisions, etc.

Also added is scaling for the graphical viewer - you can specify a playing field size in Constants.java, as well as an applet (screen) size, and it will scale the graphics to fit.

Still need to figure out a better system than all the copying of data over to the IMx versions of the data types.

- Dean

Eh, that works until someone comes up with a way to make the AI better by spending a very large amount of processor time.


And not only that, but you have the problem that even if it's private, the AI's can use reflection to rip out the data.
But don't give up hope. There are two solutions. Both are ugly as hell, but there you go.

First: insulate the data from the AI's using the stack

public abstract class GameData {
  //  lots of get methods, but no implementations
}

public class ModifiableGameData extends GameData {
  // this class actually contains data; its get methods act 'normal'
  // and it actually has set methods and stuff. This is what the physics engine sees.
}

public class DataWrapper extends GameData implements Runnable {
  private String requestedData;
  private Object ret;
// 'get' methods set the requestedData to some value, then yield.
// The thread has the ModifiableGameData the physics engine is using in its stack.
// This thread is an infinite loop which looks at the requested data to find what aspect of its bullet it should put into ret.
// Having done so, it yields.
// Then the get method resumes and reads off the value in ret, then sets ret to null.
}

Second: insulate the data from the AI's using RMI.

if you understand RMI, this should be fairly self-explanatory.

If you care about security, that's what you need. Anything less is trusting that the AI writer is being honest.

Note, if this is for a class project, actually implementing either of these schema could be good for bonus points.


(edited to fix spelling)

Wow, this thread has drawn the programmers out of the woodworks.

I stand corrected.

guesst, you should try programming if you haven't. Programming computers is at least as cool as playing the tuba in high school band. And we all know what babe magnents they were! ;)

Hmmm, that is an ugly solution. I'll probably keep it the way it is for this prototype, and keep the "correct" way in mind for when I make a proper game. This has been a great exercise - now I feel a little more confident in making real games such as (yet another) Super Melee clone. Thanks for all your help so far.

The reflections thing is interesting, and a little annoying. While I realize that the "private" attribute isn't designed for real module security, having an interface to extract the private data from a class negates the reason for including the darn keyword in the first place. They need a new "GoddamitSuperPrivateNoTouchingYouUrQuanJerks" attribute ;).

No, not a class project, purely for my own benefit. I like to make simple projects on the side to keep myself busy in the downtime at Uni, and to expand my abilities beyond my comfort zone. My last project was a very simple pure-software Java 3D model renderer (http://www.fourwalledcubicle.com/J3D.php), before that a failed Logic Simulator, etc.

- Dean

The point of the keyword is to establish that it is not a part of the class's interface. That is all.

Reflection is really necessary for serialization.

~~~~

I realized recently that those extreme solutions are not necessary in this case. It'd only be necessary if you needed to call methods on an object which must hide data (e.g. a crypto key); but the AI's don't need to do that.
If you only want them not to be able to change it, you can pass each AI its own copy.
If you want to obscure information, give the copy incomplete information.

Way to go, death, making things more complicated than necessary. ::)

It's been a while since I programmed ina Java and I don't miss it one bit. However, if it's true
that Java does not support operator/function overloading, that might be the best thing
it has going over C++. Reading other people's C++ code might one day send
me to the funny house.

I program. I've programed for years. first with BASIC on the C64 and the Apple IIe, then Pascal on the Apple first, then PC. Then C and C++. Finally I dabbled in Java before my life got so busy that I don't do much of it anymore. However, I am posting my last project (http://www.retroremakes.com/forum2/showthread.php?t=9923) on another board. I'm a little more than halfway through it right now.

And I played the Tuba in the school band for a while too. Yeah, I was a giggalo.

Yet to upload the new code, but I've added in a setting to make bullets affected by Planet gravity. That should make it quite challenging to code a good AI for - it's possible to shoot bullets around a planet if the gravity is strong enough.

- Dean

Operators are what they are; you can't do anything to them.

I'm not sure what you mean by function overloading.

If you mean polymorphism, it is central to object-oriented programming and is included.

If you mean the simplest expansion from operator overloading, which is taking an existing function name and defining a new function with that name but taking different types as arguments and giving it additional behavior... such a problem cannot arise in Java because, technically speaking, there are no functions; there are static methods.
Every static method you call is attached to a class, and can be traced back to it very simply. Even if someone is abusing the 'import static foo *'  lines, those lines narrow the possibilities of where that static method is hiding a lot.

Is Java expensive coding language? I thought I could start learning it.

Expensive in what sense? Assuming you mean cash for the development environment, the price is €0 for Java Standard Edition (http://java.sun.com/javase/). Just grab the latest development kit. If you like your programming languages with point-and-click development environments, Eclipse (http://www.eclipse.org/downloads/moreinfo/java.php) is the way to go.

Thank you very much Novus!

I think that was the point -- you can overload them in C++ (unlike Java), and it's a shame.

There is no rolleyes icon strong enough to properly respond to your post.

I guess I misunderstood you then. It seemed like you repeated exactly what he said.

If you think so, reread more carefully. In particular, the first word of what I quoted of his post.

He made a conditional value judgement.

I filled in the value of the conditional.

To recap, I wasn't sure if operators and functions could be over-loaded in Java.
Deadth999 confirmed that they cannot be overloaded.

Which confirms that Java (from a structure point of view) is more sane than C++,
even if it is a more-wordy, bloated mess to code in.

Discovering someone has changed the meaning of the + sign in C++ is
the begining of a heacache.

Oh, sorry,  I thought the "if" was just a figure of speech, not an actual uncertainty... Thanks for claryifying. :P Heh, we've made six posts about this silliness. :-[