Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  General Game Logic  (Read 2112 times)
0 Members and 1 Guest are viewing this topic.
Offline gauo

Junior Newbie





« Posted 2008-10-19 14:25:19 »

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.

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.
2.
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 ^^.


Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #1 - Posted 2008-10-19 17:30:09 »

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:

1  
2  
3  
4  
5  
6  
7  
8  
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.

See my work:
OTC Software
Offline gauo

Junior Newbie





« Reply #2 - Posted 2008-10-20 15:53:23 »

thx, for the reply though i think you overate me ^^.
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
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 Smiley ).
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*
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #3 - Posted 2008-10-20 19:34:06 »

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.

See my work:
OTC Software
Offline gauo

Junior Newbie





« Reply #4 - Posted 2008-10-29 12:14:06 »

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 -_-).
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #5 - Posted 2008-10-29 16:23:28 »

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.

See my work:
OTC Software
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (22 views)
2014-09-19 03:14:18

Dwinin (35 views)
2014-09-12 09:08:26

Norakomi (62 views)
2014-09-10 13:57:51

TehJavaDev (89 views)
2014-09-10 06:39:09

Tekkerue (44 views)
2014-09-09 02:24:56

mitcheeb (65 views)
2014-09-08 06:06:29

BurntPizza (47 views)
2014-09-07 01:13:42

Longarmx (35 views)
2014-09-07 01:12:14

Longarmx (40 views)
2014-09-07 01:11:22

Longarmx (36 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org 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‑gaming.org
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!