Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (754)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Games Center / Showcase / Re: DuelTanks - A two player strategy-tank game. on: 2014-04-20 01:32:28
Running on Windows 8.1 and it worked fine.  There's only one of me, so I wasn't able to give it a proper workout, but I checked it out.  Seems to work well.  Some fine points:

  • The clicks on the opening window did not always work.  Sometimes one click would start the game or take me to the instructions, but sometimes it took two.  No big deal once you're used to it, but it can throw a first time player off.
  • The life and bullet numbers are too dark.  Brightening them would be the simplest and biggest improvement you could make.
  • The bullet counts are a bit hard to follow.  I'm not even sure they're working right.  (Do some of the ammo markers actually take ammunition away?  The X numbers go up and down when I run over the markers.  Is that a bug?)  If the bullets are different, you might want a clearer way to show what types of ammo the tank is using at the moment.  (Mind, in a real game the players would be focused on shooting rather than worrying about what they're shooting.)
  • You might want to add some flashes or something when things are hit or ammunition picked up.  The color and intensity could be a clue as to what happened to a player frantically maneuvering a tank so he doesn't have to think, "The enemy had 15 life points and now has 11 life points, so I must have hit him with something that took 4 life points."  Instead, he he can think, while doing five other things, "Medium red flash--pretty good hit."
  • Finally, for extreme beginners, you might want some way to get to the instructions from the game.  I read the instructions, then started the game, then asked, "What button was it that moves forward?"  (But I have a really bad memory.)
2  Games Center / Showcase / Re: DuelTanks - A two player strategy-tank game. on: 2014-04-18 23:37:53
Just tried to download.  Got a file "Gasoline Row Cast.Sims3Pack".  What do I do with it?  Or did I pick a bad time to download?
3  Discussions / General Discussions / Re: Yet another transputer-like experiment on: 2013-11-10 00:33:21
My question is what happens when all these cores hit the same word in memory at the same time.  We're going to get diminishing returns after a while just adding cores.  This article does talk as if it might be multiple computers on a chip rather than cores, meaning more than one memory.

Java could be useful here.  Unlike in C# (don't know about C or C++), a Java thread has to lock the same monitor to be sure of seeing changes in another thread's synch block.  This could let Java run a lot faster on such a system, because data only has to be copied from one memory to another rather than to all memories.  (Of course, it could just break the code of millions of programmers who did not pay attention to the fine points of Java multithreading, or just never imagined their code would run on such a machine.)
4  Game Development / Newbie & Debugging Questions / Re: Best way to save data securely on: 2013-09-24 00:44:31
I think ObjectOutputStream is the best way to save data.  (I never found XML all that readable, to be honest.)  But you have to be careful with it.

For starters, when you write out one object, it writes out all the other objects that first object references directly or indirectly--the whole "object graph".  Theoretically, one write will save your whole game.  But if you're not prepared for it things can get crazy. And if you change an object and write it out again to the same stream, OOS will note that it's already written it and just reference the previous write.  So when you read it in, you won't see the changes--the first and second versions will be identical.  (This gets really interesting if you're using OOS over a socket.)

Next, use Externalizable rather Serializable.  This lets you control exactly what gets written and read.  If class A contains class B, whose data is just 3 integers, Externalizable lets you write out the 3 ints rather than the object.  When you read A back in, you can recreate B from the 3 ints.  Generally, you can avoid writing out data that you don't want to save anyway.  (Yeah, you can do this with Serializable via "transient", but with Externalizable you have more control.)  And you could encrypt data you didn't want people looking at: passwords or names or pictures or critical numbers.

Be careful when reading data back in.  If class A has data that derives from several objects it references, you might want to save space in your file by not saving that data but recreating it from the referenced objects.  However, ven when you are done reading in A, the referenced objects may not have their data yet, so you shouldn't try to get values from them.  You need to do this by reading in the whole file, then going back and recalculating the derived data.  (Or just save it normally in the first place.)

A big benefit to Externalizable is you can include a version number at the start of each class's write.  Should you change the class's writeExternal output, increment this number.  readExternal can check it and read the correct format every time, even if it changes twice a day.  And it can handle big changes too: whole new lists and intricate calculations present no problem at all
5  Game Development / Newbie & Debugging Questions / Re: How to implement game objects? on: 2013-09-23 00:54:30
@Stein102:  I'd go with GameObject>Consumable>HealthItem, then pull a healing value from somewhere.  Keep it simple.  When making it more complicated, take care.  You do have only single inheritance.  And as you subclass, you want to keep the subclass hidden as much as you can.

For instance, here you might have Consumable have a "getEffects" method that returns a class that's just a bunch of numbers (an array would work as well).  One for life points, one for strength points, one for visibility points, etc.  Someone drinks your Consumable, and you see, via getEffects, that they gain life points, become a bit weaker, become slightly invisible, etc.  You don't even know, or care, that the Consumable is a HealthItem.  HealthItem is just where the code is to make this type of Consumable work.  The HealthItem in turn can just be a set of numbers, really.  And you can create each HealthItem instance with it's own set of numbers.  (Presumably it has some code that's not in Consumable or you could ditch HealthItem completely.)

Sometimes numbers won't be enough.  The HealthItem may do different things to different races or classes of characters.  Then you need new methods.  Now you may want to extend HealthItem to get a class that makes characters whose name begins with "A" turn invisible, gives super strength to thieves, and gives extra life to half-elves.  It's created as a new WeirdPotion, but from then on you can treat it as another Consumable and forget its origins.

Alternatively, HealthItem might contain another object, and use that object to get all its values; an Effects class, say.  It's a little bit awkward as all the HI methods have to be set up to call the contained Effects object to get return values and make things happen.  However, you can change the HealthItem's effects completely by swapping out the old Effects object and dropping in a new one.

(And, as I suggested in my previous reply, a HealthItem might contain several such classes.  One for effects.  Maybe one for taste (makes some characters gag).  One for intoxication (makes gnomes drunk).  One for addictive qualities.)

What you're looking for is a HealthItem that, once you get it set up, goes through your game doing it's job as a Consumable without any further bother on your part.  If a character consumes it, it know what to to do to the character and how to do it without any work on your part beyond a method call like:  "character.consumes( consumable );".  Or maybe "consumable.drunkBy( character );"--needs some thought.

(I'm putting out ideas here.  In real life, you want to keep your game as simple and as bare-bones as you can manage.)

XML:  I call my feelings a phobia because they're not really rational, and you probably know more about it than I do.  However, since you asked, I like Java objects.  Once something's a Java object I can work with it.  I serialize them for files and I/O with ObjectOutput, or sometimes my own code, but always in binary format.  It wouldn't really be hard to serialize them to XML or JSON, but I like binary and I'm starting to appreciate that ObjectInput can figure out what a class is without me telling it.  And is XML really human readable?  It's wordy, and if there are a lot of numbers there's a lot of conversions going on--it's slow.  (I know the speed doesn't really matter, especially in this case, but....)  Of course, Java objects are not human readable (by most of us) at all, so you need an editor.  But my thinking is if you have something like a HealthItem class set up for your game, use the same class in your editor.  Serialize it as necessary to save it or move it from editor to game and back again.

Of course, with XML you can skip the editor and write it in XML at first.  When you write an editor you can check what the editor's doing easily.  Every other programmer in the universe will tell you to use XML.  And you need to do what works for your.
6  Game Development / Newbie & Debugging Questions / Re: How to implement game objects? on: 2013-09-21 23:31:53
I'd start with a base class or interface called something like GameObject.  Extend it or implement it to get all your game objects.  You need to put a lot of thought into this over time, but you might have Weapon class extending GameObject.  Then Sword extending Weapon.  Try to keep your method definitions as low down the hierarchy as possible.  Ideally you would want to deal with a Weapon as a Weapon (or even GameObject) rather than have to check to see if it's a 22FootPike which extends Pike which extends Weapon.

(I usually start with GameObject as an interface, then find that all implementations have common code so I change it to a class with the common code in it.  Then I come up with a new game object that already extends a class and can't extend GameObject, so I have to use an interface after all--maybe GameItem.)

GameObject should have (abstract) methods to read and write XML to aid in generating objects from an XML file.  (Personally I have a phobia about XML, and would be more inclined to write an editor in Java.  I did that with my tank game.)

Don't get too carried away with subclassing.  With my tanks, I had one Tank class (extending GameObject).  To make various types of tanks, I'd drop different Turret, Gun, Engine, Transmission, etc. objects into it to make all the various types.  Of course, then you've got to worry about all the weapon parts in addition to the weapon itself.  (I think this is called "Dependency Injection", but I've seen the term used in some funny ways, so I tend not to use the term myself.)

Ideally, you'd want to be able to write a lot of code that only has to deal with GameObject instances, and not care what they are.  This is probably impractical, but you might come close with Weapon instances.  This simplifies complex code and is known as "Polymorphism".

Hope this helps.  (You did ask for "Any suggestions at all".)
7  Discussions / General Discussions / Re: Why is java not like heaven for AAA game companies? on: 2013-08-27 23:58:20
  • Java still has a 'bad rep' to some people, however its improving.
Thanks, that cleared up the major questions. But can you elaborate on what 'rep' that java has and how it is improving?

This is ancient history, back to the 20th century, but Java was originally intended as a browser language.  Applets were going to rule the Web.  Java was going to be what Javascript is today.

Unfortunately, Java needed Swing and was a megabyte download--at a time when most people had dial-up.  HTML worked much better.  You couldn't write programs in HTML, but the bosses didn't care, they only knew that HTML was fast and Java was ssslllooowwwww.  So Java became a laughing stock, and this persists in a lot of (older?) minds today.

I did work briefly on an Applet web app in the late 90's.  It's still going strong without maintenance 15 years later.  People who choose HTML have bounced around from Active X to Silverlight to Flash to immense Javascript atrocities at great expense, but Java is still a joke (to the older crowd) except to those in the back rooms who have been using it.  Its rep's been improving lately; it's 5 times better than anything else (except maybe C++ for high frame-rate games), and it's getting hard for people to overlook that.[/list]
8  Games Center / Showcase / Re: Square Attack on: 2013-08-21 01:38:51
Works fine on an antique XP PC.  Not my kind of game at all, but I found it hard to stop playing.  If I was stuck somewhere with nothing to do and an Android phone, I'd play it all day.

You might want some way for the player to get back to the start screen.  Once you've played it, you start looking for instructions.  I played it once, then had to restart to learn how to play.

For what it's worth, I just used the left and right arrow keys.  I don't even know what they did, I just banged on them till the center squares were in the right positions.  I think my subconscious figured it out because I could usually get the change I wanted with one button press.

I'd suggest reducing the number of control buttons, but I'm neither a big player of these games nor a psychologist.  Maybe different people play it differently.
9  Game Development / Newbie & Debugging Questions / Re: I want to use Inheritance in a static way on: 2013-08-13 00:18:13
Just get something running.  You can junk the statics later when (A) you can see that you have to and (B) you've got a better idea how to junk them.  Doing a lot of work that doesn't immediately get your game going is a drag.  Doing a lot of work that, in the end, doesn't do what you want is typical big business IT, but not something you want to do when you're not middle management.

There's a lot to be said for doing it right, but don't get ahead of yourself.
10  Game Development / Newbie & Debugging Questions / Re: I want to use Inheritance in a static way on: 2013-08-11 18:20:32
I'd create a MetaSkill class and put the static stuff in there as non-static.  Create an instance of MetaSkill and use it instead of Skill for the formerly static methods.  MetaSkill can inherit from another class and implement interfaces.  It can also be inherited from.  Your Skill subclasses can all work with one MetaSkill instance, or you can create several MetaSkill instances with different data.  You could even have your different Skill subclasses reference different MetaSkill subclasses.  You might even find it handy to have MetaSkill itself be an interface.  (You'll probably find it handy to have a Skill method that returns the relevant MetaSkill instance.)

Anyway, you get the idea.  Do what works for you.  Trying to make statics work here just doesn't work; I've tried it.
11  Game Development / Newbie & Debugging Questions / Re: GC causing massive delay on: 2013-08-10 19:38:23
@Riven:  You're right.  I have seen big-array problems;whether that was an old GC or whether I need a fancier test to reproduce it I don't know.

I ran the thing on an antique machine with a 250MB heap and a single core.  I added an actual object (an 8 character string, created with "new"--just using quotes gave me the same results as using null).  Using the object slows down the ArrayList so it's only about half again as fast as the linked list and can only hold twice as much before the out-of-memory error.  (Without it, my results were like yours, scaled down by a factor of 8.  I printed a message and time every 131072 (1024X128) lines.

The results between the two lists were amazingly similar.  The ArrayList needed 20 milliseconds between rows and the LinkedList 30.  (Its a slow machine, and the smallest measurable time interval is 10 milliseconds.)  About every ten to 12 messages, the time needed spiked to 500 to 2000 ms, getting larger as the program ran.  I looked to me like the program was doing repeated garbage collections.  These would be needed for the ArrayList, but in the case of the LinkedList, until the last one there was plenty of free memory and, at no point, was any memory freed!

As you noted, arrays take less time in gc, even when there is array space to be collected and no LinkedList space to be collected.

I'm not sure what to make of all this.  It seems to slow down code that doesn't free large arrays without helping those that do.  But it is interesting.
12  Game Development / Newbie & Debugging Questions / Re: GC causing massive delay on: 2013-08-08 03:21:43

I haven't tried this recently, and when I last had the problem I was trying to do something else completely.  Still, I've heard of enough other people with the problem that I doubt it's gone away.  I am beginning to wonder if my ArrayList Add test does much to demonstrate it.

I would suggest adding a new object rather than null to the array.  What you've got will, if I still understand ArrayList, fill memory consecutively with arrays, each 50% larger than the previous.  All but the last two will be freed, and the next to last one will usually be freed.  When allocations hits the end of available memory, they can easily go back to the start and reuse what's there.  Adding actual objects will put those objects between each array.  Now the GC has some real work to do.  I can't guarantee a proper out-of-memory exception with 90% of memory still free, but you should see something of interest.

It seems to me that fragmentation still must be an issue.  To allocate space for a large array, you need a bunch of contiguous memory blocks with nothing in them.  With allocated bits of memory scatter through them, that means a lot of copying.

LinkedLists are slow memory hogs, but they only ask the GC to do a tiny amount of work at a time.

And its probably time for me to go read the tuning doc.... Smiley
13  Game Development / Newbie & Debugging Questions / Re: GC causing massive delay on: 2013-08-07 00:42:53
The problem I was referring to--whether or not the OP's problem is another matter--is the too-rapid allocation and deallocation of large blocks of memory; it's got little to do with using a lot of memory or wasting memory.  The most typical symptom is getting an out-of-memory exception with 90% of memory free.  The simplest way to do it is with something like:
    ArrayList  array = new ArrayList();
    while (true)  { array.add( something ); }

If the optimizers don't interfere, this will, of course, throw an out-of-memory exception.  What is unusual is that when it does a lot of memory will still be free.  (There must be a dozen questions about this on StackOverflow.)  The reason for the OOME is not that there's no memory left, but that the GC is taking too long to merge free blocks and gives up rather than slow down too much.

Most people see the OOME and wonder why.  I think game writers are more apt to see the slowdown and wonder why.

Reducing the size of allocated memory helps a lot.  Reusing big arrays helps a lot.  Doing lots of other work between allocations (giving the GC thread time to do it's job) helps, too.
14  Game Development / Newbie & Debugging Questions / Re: GC causing massive delay on: 2013-08-03 19:00:43
I don't do the fast graphics like you do; I tend more towards the turn-based, and my problems tend to be more about checking who's near whom and what's the shortest path to somewhere.  (And I write business software too.)  And the GC problem usually shows ups as an out-of-memory exception (despite lots of free memory) rather than a slowdown.  But your problems and mine are likely related, so:

The key word is Fragmentation.  It's been a long time since I've had a program hesitate while the GC runs.  The GC that comes from Oracle with the JVM does a superb and invisible job.  I don't think even you should notice that it's running, no matter how many new objects you create.  But if you create large objects (arrays), then the GC has to look harder to find the contiguous space for them.  When you've created--and freed--a bunch, your free memory is mostly large-object-sized chunks with, perhaps, pieces taken out for small new allocations.  Now if you try to allocate a new large object, there's no space quite big enough or contiguous enough.  Your memory is fragmented.

The GC will work frantically to move allocated memory around to turn smaller free chunks into bigger chunks.  If your program used memory at a leisurely pace (if your game ran 10 times slower), you'd never notice a problem.  As it is, you are most likely seeing the resultant slowdown.

If you ignored it and let it get worse, eventually the GC would prefer throwing an exception to embarrassing itself with such abysmal performance.  (That's what usually happens to me.)

My solution is to avoid arrays and things that use them like HashMaps and ArrayLists and use TreeMaps and LinkedLists instead.  This would, most often, not work for you; arrays really are much faster than, say LinkedLists, even for sequential reading.  So my answer to your problem is, like most of the other ones:  keep your arrays as small as you can and reuse them.  The new arrays are the problem.  (I'm putting this answer here to explain why this is happening; the solution's been given several times over.)

(Also, making all your arrays the same size might help.  The classic way to get this problem is to add millions of items to an ArrayList.  Each time the ArrayList resizes, it needs a bigger array.  Once the original memory is used up, free memory is fragmented into many large blocks, but none of them big enough for the next allocation.)
15  Game Development / Newbie & Debugging Questions / Re: Drawing images in Jpanel, JFrame and game loop on: 2013-07-22 00:36:38
You should declare "running" with the "volatile" keyword.  It's the only variable used by both threads, so having done that you can remove "synchronized" from "start" and "stop".  The alternative would be to synchronize the check on "running" in the "run" method, which would be doable but a bit awkward; you don't want to synchronize the whole method or the "stop" method will be unable to execute.

In my experience, leaving out the "volatile" usually works okay.  But sometimes it takes a few tenths of a second before the watching thread notices the change, and your game can get annyoingly sluggish.  Much less often, the thread never sees the change at all and you're wondering why the stupid button won't work all of a sudden.  (Without "volatile" or without all references "synchronized", the JVM is under no obligations to do or not do anything, nor is it under any obligations to be fast or slow about it.
16  Games Center / Showcase / Re: Tracks, Turrets, Armor, & Attitude on: 2013-07-18 00:31:01
Hi CommanderKeith,

Thanks.  The tanks do get a lot bigger, but you have to zoom way in.  They're to scale, and each of those squares is a kilometer on a side.  So unless you design and build a VERY big tank, it's hard to keep an eye on the battle and on a tank at the same time.  (But check out the unit tray.)  I'm thinking of using oversized tank images, but until I come up with better visuals for the tanks that's not a big improvement on the dots.  On the other hand, it shouldn't be difficult to click on them; tactical skill is what's supposed to matter here, not eye-hand coordination.
I actually did multiplayer first.  A friend pointed out that a first time player would not want to fire up a host session, an AI session, and a player session before starting his first game, so I mashed them all together.
17  Games Center / Showcase / Re: Tracks, Turrets, Armor, & Attitude on: 2013-07-17 01:03:11
Thanks for your concern.  I will, however, take whatever comments I can get.  Destructive criticism is welcome.  In particular, if something doesn't work, or is unintelligible, I need to know.  All other comments welcome too.

Visual pizazz is important, and I regret the lack.  Unfortunately, it takes time and ability and knowledge, all lacking, so it got a lower priority.  The business app look is probably as much my fault (I've written a lot of business software) as swing's--to be fair to swing.  I'd like to blame it on the nature of the game, but I've seen a bunch of games that ought to have the same problem--lots of little dots running around simple terrain--almost all spaceship games, come to think of it, with absolutely featureless terrain--at least I've got woods, roads, and a river-- (ah hem) --anyway, they manage at least a little bit of pizazz, so I can't claim that excuse.
18  Game Development / Newbie & Debugging Questions / Re: A lot of ArrayLists. Is this good style? on: 2013-07-14 19:43:47
Interesting.  I've spent my life writing software that was a bit too big for the computers it ran on; I've always been running out memory even when I had a lot of it.  For some reason, when I started writing a game, I felt I had to be ready to handle seriously oversized game maps and lots of players, so I'm still overloading my computers.  (Admittedly, they're still 32 bit computers.)

Since getting on Java-Gaming, I've read a bit about LibGDX (and plan on reading more), and some of those collections look useful in a big desktop program, IntMap especially.

The oversized ArrayList is only a problem if there are a lot (100,000+) of them, or if it is a very large list.  The poster probably has a lot more memory than needed, but with lots of memory people often squander it, and I thought it would be worth noting the problems that arise when free memory does become scarce.
19  Games Center / Showcase / Re: Tracks, Turrets, Armor, & Attitude on: 2013-07-14 19:08:36
If it can do what TTA&A does then yes, definitely.  It would be way beyond "highly organized".  I could never have done it.  In fact, I could never have written this thing in anything but Java.
20  Game Development / Newbie & Debugging Questions / Re: A lot of ArrayLists. Is this good style? on: 2013-07-14 17:14:49
I don't use ArrayLists much, but I may be concerned about things you're not.

I think linking all the parts of a game together will some sort of Collection is pretty much standard.  ArrayLists are simple, basic and they are very, very fast.  And they use memory efficiently.  So if the problems I list below don't threaten you, stick with them.

The first thing is they're often not the fastest solution.  Specifically, a Map of some sort can find an object by key, such as a name or an index (where there are odd gaps in the index numbering).  Linked lists ought to be faster if you want to scan a list and add or remove objects at certain points, but ArrayLists keep beating my linked lists in my benchmarks no matter how much I cheat.  I think the Array concept just fits in too well with modern CPU and cache design.  But you may want to use Maps  (HashMap and TreeMap, for starters).

However, if you are making heavy use of memory you can get memory fragmentation from anything based on large arrays.  Using arrays directly, or ArrayList, or HashMap can trigger this problem.  For example, consider creating an ArrayList and adding random value to it in an infinite loop.  It will, of course, run out of memory.  However, you will get the memory exception while there is still plenty of free memory.  Why?

As an array list grows, it runs out of space, creates a bigger array, copies the old array to it, and frees the old one.  As the arrays get large, each freed one takes up a big chuck of free memory.  The next array can't use that space because it is bigger.  So you end up filling free memory with more and more, larger and larger unusable blocks of memory.  You can end up running out of memory when 90% is still free.

The GC will work frantically to combine all these blocks into free memory, and if it has time it will merge them into big enough blocks to allocate the new, bigger arrays.  But in this example we're creating new ones too rapidly.  The GC could put the program on hold while it does this, but it in my experience it would rather throw an exception than stop a program for a second or two.

So collections that use small bits of memory can be better than collections that use arrays.  I tend to use LinkedList over ArrayList, and TreeMap over HashMap.  But do note:  if you create a large array and then leave it alone, sizewise, for the duration of a session, it won't cause this problem and will outperform anything else.

The second problem with array-based collections is that they don't shrink.  Say you have 1 million characters in your game, and each one has a list of possessions.  In 5 or 6 cases, the list may contain over 100 entries.  Often it is empty.  Usually it contains 1, 2, or 3 entries.  But the characters swap so much that each one, over the course of a game, is apt to have 100 entries at some point.  Most of your characters will end up with 100+ element arrays with 1 or 2 entries in each.  You have a huge waste of memory.  A linked list would work a lot better, even with the overhead for pointers.

So for dynamic lists, you might want something else.  I tend to use linked lists of some sort and TreeMaps most of the time.  But if your memory use is under control, stick with ArrayList and maybe HashMap.

21  Games Center / Showcase / Re: Tracks, Turrets, Armor, & Attitude on: 2013-07-14 16:23:15
Comments on the comments so far (another one came in as I'm writing this):

UIManger.SetLookAndFeel:  Thanks a lot!  I may not have asked, but only because I didn't know enough to ask.  Looks simple and painless.

Highly Organized is not all that subjective.  The code works, which is an pretty objective measure.  Particularly when it's doing the job this code has to do.

Source Code:  Must be decompiled code, which I expect must be somewhat confusing.  You'd need the Javadoc to get a quick (or even slow) sense of how it all fits together.
22  Games Center / Showcase / Re: Tracks, Turrets, Armor, & Attitude on: 2013-07-13 19:42:07
The idea to to hold a majority (3 with 2 players) of the control points for a few minutes.  Then you win.  Or exterminate the enemy.  Tanks shoot automatically, but go where you tell them to.  Drop the green question mark anywhere that looks interesting and you'll get an explanation.

The source code is complicated, but it is highly organized.  The entry point doesn't do anything except create the main window.  There's no main loop.  I suspect the castings you see are objects being retrieved from collections.
23  Games Center / Showcase / [Java] Tracks, Turrets, Armor, & Attitude on: 2013-07-13 00:20:59
Tracks, Turrets, Armor, and Attitude is half board game and half RTS.  It's a tactical, realistic war game (relatively speaking) with each player commanding 10 or more (or less) tanks.  Intended for network play, it has good AI so it works for single players also.  Available on, and described more fully by,

This game is somewhat involved because of the multi-player aspect and because it allows you to design your own tanks and build your own army, but you can play a simple game very quickly.  On the website menu,  just go to Real Quick Start for the fastest look.

I put this game together over several years, targeting a small group of people.  I'm now interested in seeing if it interests anybody else.

24  Game Development / Game Play & Game Design / Re: Intuitive Interface Design on: 2013-07-12 02:42:05
I liked C best.  As some others mentioned, nothing on the screen is best.  C seems to do the best at keeping the junk out of the way.  It gives the most uninterrupted view of the screen.
25  Discussions / General Discussions / Re: Making a Static Free Engine on: 2013-07-11 21:25:21
I try to avoid static hell so I'm not that familiar with it close up.  The usual problem I encounter is trying to stuff static methods into interfaces.  I pass an object that implements an interface to a method, and that method needs static (class) data.  The method to get it, in all classes that implement the interface, is, of course, static.  At that point, I rework the code.  If I kludged it, I imagine I'd be in "static hell", which I suspect is something like writing in Fortran or C, which I do not want to do ever again.

I have recently come across code where the data for 1000 "objects" is stored in a set of 1000 element arrays.  Game characters, for instance, with values for location, speed, health, etc..  This is no doubt faster than have a GameChar class with instances in one 1000 element array, but as the game gets more complex, the lack of GameChar instances to pass around gets awkward.  And the locking problems if multiple threads try to access individual characters will bring game execution and development to a halt.

There's nothing wrong with any of this.  Lot's of people frame nice houses with pine 2X4's.  But they know they're not going to put another 60 stories on top.  The problem happens when people come up with a simple solution for a simple problem, then try to stick with it when the problem becomes complex.

26  Discussions / General Discussions / Re: Making a Static Free Engine on: 2013-07-11 19:42:25
I use static all the time and it's great.  The problem is, it doesn't scale--in terms of numbers of classes and interfaces and the relationships between them.  As your program becomes more complicated, in the parts of the program that become more complicated, the static methods and fields start to get really awkward.

What I'm saying is use statics.  But when they start to get awkward in code you intend to enhance, pay the price to get rid of them rather than pile kludge on top of kludge.

This theoretically applies to any programing language, but Java handles complexity so well you're more likely to notice the problem there.  Everywhere else, when you hit static hell you'll be in so many other hells it will be the least of your worries.

And you can stick to simple programs, even in Java, and forget all this.
27  Discussions / General Discussions / Re: Making a Static Free Engine on: 2013-07-11 14:33:10
Static isn't OO.  You can't use static methods in interfaces and can't override them.  Static fields are globals: you're asking one value to work for every single member of the class.  All this is rather theoretical, of course.  Where you get into trouble in real life is when you make your program more complicated; when a simple stand-alone object becomes part of a complex structure.

Basically, you find a subclass needs to override one of the superclass's static classes.  Or there's a global value that doesn't apply to one particular class instance.

However, most of the time statics are easy, avoiding them is difficult, your code is not going to get more complicated, and you'd be nuts to pay a big price to avoid them.  If you do get into trouble, you can fix it when you do.  But when it is time to fix it, fix it or you will be in Static Hell.

Note: a class defined as "static" in Java is something else completely and not a part of this discussion.  (Though sometimes people do use the word to mean a class containing only static methods and fields--which is a part of this discussion.)
Pages: [1]
DesertCoockie (33 views)
2018-05-13 18:23:11

nelsongames (75 views)
2018-04-24 18:15:36

nelsongames (70 views)
2018-04-24 18:14:32

ivj94 (752 views)
2018-03-24 14:47:39

ivj94 (82 views)
2018-03-24 14:46:31

ivj94 (623 views)
2018-03-24 14:43:53

Solater (98 views)
2018-03-17 05:04:08

nelsongames (179 views)
2018-03-05 17:56:34

Gornova (405 views)
2018-03-02 22:15:33

buddyBro (1065 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!