General Game Logic

[gauo]

Hi,
Just as i have already in another newb thread stated, iam currently trying to program a strategie game on
java.

I started out to implement the game logic but dont know what kind of implementation would be preferable
when it comes to the reasearch and build tree, and the Map of the Galaxy.

My General Idea is an customizable interstelar strategie game.
The values of the ships, the buildings, and the researchable stuff, should be written in an file(current xml)
and should allow even customizing the build tree.

The graphics should also be interchangable, but thats low priority since it will not animate most
actions, and there will just be planets, the galaxy background, and maybe icons for the races and sprites
for their fleets.

I would love such customizability, since iam a fan of most science fiction films an series and
it should not be limited to Star Trek(my current data)

Now to my problem.

1. I dont know how to Implement my Galactic view and even if its recomandable.
   
   http://www.abload.de/thumb/milkywayblack2_coordsysc4l.jpg
   
   The Space within one System, will not have any in game relevance, only the distance between two systems
   will matter for the calculation of Jumptimes, but that will be easily calculated with some Trigometrics (x,y) koordinates,
   will give me the radius and arc.
   These Systems, will be SolarSystems, containing the planets and Fleets.

I created an abstract class Buildable, with costs and Buildable[] requirments.
Ships, Buildings, Research Items all inherit from this class.
Planets will have a collection of all builded items on this planet, in order
to determin, if some other items, are buildable on it.
Is this aproach recommandable?. Within the xml, every item will get an id,
and an list of ids, so i will maybe change it to int[].

2,3.
Recources, There will be 4 main recourses, metal, silicate, anti-matter
(the names should also be custamizable later on)
Especially for Ships, there will also be Troops as costs.
So i have know Troops, wich can be Recruited(so Buildable) but
in the same time i have them in my costs…is this recomandable, or should
i split between those normal recourcess and Troops?.
within my implementation, there are also two times these Troops,
within Costs(my Ressourcess as an int for its quantity) and each type of Troop has its own Class.
My Idea was to have these Troop Classes as an Type of Troop (its fighting capabilitys and for the requirements of Ships)
and its quantity on the planet (+Costs) or needed for the building of Buildable(its -costs).

Damn , iam confused know and my bad english doesnt help neither ^^.

I hope you can give me some hints or maybe a tutorial for strategy games XD.
Thx for your time ^^.

[Demonpants]

From what I understand, your ideas seem good and you’re definitely thinking in the right direction. As far as I know, there are no “better” ways to design when you’re at this level, because your game is unique and is therefore going to need a unique design. As such, your best course of action is to keep thinking like you’ve already been doing and then try different stuff out to see what works. You seem to have a solid enough understanding of inheritance and Java in order to do this.

As for direct answers to your questions…

Your Buildable class seems right. The question over whether you should use Buildable[] or int[] for the tech tree really is not a question of what’s easier for people who are using your customization options, but more where you want to do computation. Because if you have Buildable[], people obviously aren’t going to be able to directly reference objects within the XML file; they’ll have to type in integers or string identifiers. In that case, you’re going to have to create an algorithm that makes instantiations of the Buildable object once the level is loaded in order to populate your Buildable array. Whereas if you use int[], then every time a Buildable checks its tech tree ingame it’s going to have to figure out which actual Buildable objects those integers match.

So in the above case, it’s preferable to use Buildable because you’re only doing the computation once, on the level load. However, there are other things to consider. Because this is a tech tree, your object references probably only should be singletons in the first place. It sort of depends on what functionality you’re looking for, of course, but if all you want is to say, “if I have this and this and this, then I can be built,” then in fact it makes much more sense to link to something that is only instantiated once. To do this, I would sort of combine the int[] and Buildable[], like so:

public abstract class Buildable
{
     private int[] requirements;

     ...

     private static Buildable[] buildables;
}

Then you populate the buildables array once on level load from some XML list, and the requirements are index values from the buildables array. That way you still have very fast ingame access but you’re still not making a bunch of redundant instantiations.

And Troops make sense as both Buildable and Resource, except that you want to avoid multiple inheritance. In order to do so, make Resource an interface. You probably don’t need any more information than an interface can give you, so it should get the job done. This method is also preferable because Resource and Buildable should not be mutually exclusive. It’s not logical that something you can build also can’t be used to build something else. In fact it might even make sense to have Buildable as an interface as well; it doesn’t seem as if it needs much functionality outside of the tech tree.

[gauo]

thx, for the reply though i think you overate me ^^.

public abstract class Buyable {

    private String name;
    private Costs costs;
    private int id;
    private int[] requirements;   

    private static Buyable[] buildables;
    
    public boolean buyable(List<Buyable> aquired) {
        boolean buyable = true;
        for(int i=0;i<requirements.length;i++){
            buyable=buyable&&aquired.contains(buildables[requirements[i]]);
        }
        return buyable;
    }

This is my try for the implementation of your advises, though i dont think i got it right.
I will have a static list of buildables,( i think this might also make sense to it be assoziated to the race
since they will have the same buildables(sry in my code its buyable, dont know why ).
Each buildable now, will have an array of indeces of the required buildables within this static list.
I will also have it, that the id of the buildable will possible be the index of the buildable within the race.
But now to my problem.
static?, did this mean there will only be one instance of it?,so after instantiation, all references will point to one object,
even when my race class will get it and every buildable?.
Wont it be problematic for the initation, that the buildable will need an array with buildables it itself is part of?
If not, i maybe got it ^^ sing my god she got it!sing

[Demonpants]

Yeah, there will only be one list of buildables if you make it static, which is the point. You may want it to be somewhere that you can always access it, or even make it constant. It’s more something that everything else will reference via indices.

[gauo]

Hokay thx again for the comment, though there is again one thing i dont understand how to do it.

If i read the xml with all the buildables during runtime, how am i supposed to make these
constant?(final?).
Or did you mean it another way?

thx for the reply, though iam currently not getting any thing done, except creating
ideas on how to implement stuff on a clipboad ^^(kinda frustrating -_-).

[Demonpants]

Basically you’ve got separate things happening.

1. In some place you’ve got a constant array of Buildables representing each type.
2. In each Buildable you’ve got an integer array representing the indices in the constant array.
3. In the XML file you’ve got information stored that allows you to make new Buildables, like String name, int hitPoints, int cost, etc. Then its int array will be stored in the XML file as references to the static Buildables.

The point here is that the static array is used purely for comparison and maybe for duplication (i.e. Buildable myBuildable = (Buildable) staticBuildables[5].clone()). Just keep in mind that this is not the only way to do this and may not be the best for your methods. It might make sense just to give every Buildable a unique String name or integer id or something that you can reference. There are a lot of possibilities.