Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
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  
  [RESOLVED] Entities, and how should I handle them?  (Read 1426 times)
0 Members and 1 Guest are viewing this topic.
Offline TheCodingUniverse

Senior Newbie





« Posted 2011-11-15 08:37:02 »

So, I made the choice of purely using the LWJGL for creating my games. After a week or so, I stumbled across 'Entities' – or game objects. After about half an hour I came up with an interface called Entity. The interface declares the following methods:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public interface Entity {
   public void draw();
   public void update(int delta);
   public void setLocation(double x, double y);
   public void setX(double x);
   public void setY(double y);
   public double getX();
   public double getY();
   public double getWidth();
   public double getHeight();
   public void setWidth(double w);
   public void setHeight(double h);
   public boolean intersects(Entity e);
}


After I made this I created an abstract class called AbstractEntity, which basically implements everything but the draw method. For the intersects method I used the class java.awt.Rectangle, lazily initialized as a private instance variable using the width, height, x, and y variables.

My question is: will this code suffice for real use?

Thanks in advance,
TheCodingUniverse

EDIT: Please close this thread – my question has been answered.

Oskar Veerhoek, founder of TheCodingUniverse.
Offline tberthel
« Reply #1 - Posted 2011-11-15 09:09:02 »

I would just use an existing GameObject or Layer class as your template.  However it does look like you included what is needed for most 2D games.

What I noticed:

- You might include z in the setLocation just in case you add 3d.
- Using interfaces and abstract classes can impose a small performance penalty on some VMs.
- You should actually use a composite for most of the methods.  (Sadly my own game development kit has this fault as well.)

So, yes you could use it.  Although, you should read the threads on Entity systems from this site first.  Some really amazing stuff in them.

Offline TheCodingUniverse

Senior Newbie





« Reply #2 - Posted 2011-11-15 09:42:24 »

Thanks, I'll check the other Entity systems out for sure.

By the way, what's a composite?

Oskar Veerhoek, founder of TheCodingUniverse.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cylab

JGO Ninja


Medals: 38



« Reply #3 - Posted 2011-11-15 09:47:14 »

http://en.wikipedia.org/wiki/Composite_pattern

Mathias - I Know What [you] Did Last Summer!
Offline theagentd
« Reply #4 - Posted 2011-11-15 10:35:58 »

I made a thread about entities a while ago, and ended up using Artemis. Now, I'm not going to say a component based system solves all your problems instantly, but you might want to consider using it depending on what you're planning to do.

The problem with inheritance is that you might want many different combinations of properties in many different object types. Consider this strategy game example:

 - You have a worker unit. He has no weapon, but he can move.
 - You have a turret unit. It has a weapon, but it cannot move.

This is easy to implement. Just create a Worker class and a Turret class and have them both extend AbstractEntity. The problem arises when you want to implement a warrior unit. He has a weapon, AND he can walk. Now, you cannot have him extend both Worker and Turret, so you can either make the Warrior class a "attacking Worker", a "moving Turret" or a whole new class. All 3 possibilities are introduce lots of problems. The first two simply go against the definition of their super classes + other problems, while the last one requires lots of duplicate code from both Turret and Worker. One solution to the problem is to restructure the whole object hierarchy, and make a MovingEntity class that extends AbstractEntity.

1  
2  
3  
Entity - AbstractEntity - MovingEntity - Worker
                        |              + Warrior
                        + Turret


This doesn't solve the duplicate attack code between the Turret and the Warrior though, but the real problem is that it is extremely time consuming to do this restructure every time you want to add a new object type that shares some properties with other classes. What about an Archer class? A Mage class? It got extremely hard to keep it all manageable for me.

Component based systems differ a lot from hierarchical systems. Instead of having a base class which all objects extend, you have a single Entity class. This Entity class basically only keeps a list of "components" which are properties that the object has. The logic code can either be inside the Components (every Component has an update(delta) function) or in a separate class.

The idea is then to define the different components and compose different object types. To continue the above example, we could use the following components:

 - Position: Keeps the position of the object as doubles (double x, y;). All objects will probably have this.
 - Movement: Keeps the data needed for movement. This is highly dependent on the game type. In a physics simulation, you could keep the x and y velocity. You could also keep a target position and move towards it.
 - Attacking: The ability to attack other units. Can contain damage, attack range, attack type, which targets it can attack, e.t.c.

With only these 3 components, we can easily implement the first 2 objects above:

 - Worker = Position + Movement
 - Turret = Position + Attacking

The final Warrior objects actually becomes just as simple and doesn't require any restructuring:

 - Warrior = Position + Movement + Attacking

Now you might obviously need custom AI for each unit type, but it's easier to reuse components between unit types in my opinion. I am not saying that component based systems are better for every single situation, but I've found it easier and most importantly faster to work with. The choice is definitely up to you, though. You could go for either a hierarchical or a composition system, or even a hybrid solution, where some things are kept in components and other in classes extending Entity. You could remove the dynamic list from the Entity and instead add a little composition to solve a problem in a hierarchical system. A new example then: You have an infantry unit and a tank unit. Both have weapons, armor and the ability to move, but they move very differently as one is a vehicle. You could have a CombatUnit which extends AbstractEntity with all the stuff that is common over these units, but have a Movement component field that controls the unit's movement. It works just as well as a pure component system, but might be easier and faster to implement than a pure component based system.

Composition systems obviously have problems that hierarchical systems do not have. The biggest problem is probably the insane dependencies you might end up with. Maybe your Movement component's update() function needs to know where to go, and this depends on which components the object has. If it has an Attacking component too, it should run towards the nearest unit, but if it has an X component, it should do Y, e.t.c. Just like a hierarchical system has problems with getting the right combination of properties for a specific object type, component systems have the problem of spaghetti-like component structure where every component depends on every other component. This is obviously something you want to avoid at all cost.

Like I wrote above, I still decided to use Artemis (a component based system) for my strategy game. It has a last little quirk though; the logic is not inside the components. They only store data. I then have separate EntitySystem (as they are called in Artemis) which provide a list of matching Entities given certain component requirements. This obviously doesn't remove component dependencies, but it makes them a lot more manageable. Personally I think the code is more understandable and elegant.

TL;DR: Some tips/rambling on pros and cons of a hierarchical system and a composition based system.

Myomyomyo.
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2011-11-15 10:56:52 »

I'd say that the very fact the OP is even asking this question means you should not be talking about entity systems to him Wink

Cas Smiley

Offline theagentd
« Reply #6 - Posted 2011-11-15 11:53:51 »

I'd say that the very fact the OP is even asking this question means you should not be talking about entity systems to him Wink

Cas Smiley
Huh

Myomyomyo.
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2011-11-15 12:13:06 »

<quick edit>I do realise you're trying to help sincerely here, but...

I think that the level of expertise the OP is at does not merit such an intensely technical in-depth discourse on the vagaries of object oriented designs.

I forget the exact story but allow me to draw an allegory:

Once upon a time there was a kingdom, and the king was miserable because he kept burning his toast by the royal hearth. So he sent forth for an electrical engineer and a software engineer and asked them each to come up with a machine to make his toast for him in the morning without burning it. A month later the two engineers returned.

The electrical engineer brought with him a prototype toaster, which he demonstrated to the king. "See, it has a dial on the front that you can set to adjust the length of time that the bread stays in the toaster for. After you've used it once or twice you can get the position just right for how toasted you want your toast, and leave it there!" And out popped a slice of toast, toasted more or less to perfection.

The software engineer brought with him a selection of diagrams. "My toast-o-matic design uses a four-bit microcontroller, which is programmed from a set of dipswitches on the front of the device. Using four bits of information allows us to specify 16 shades of toast, from completely untoasted - well, you never know when you might just want bread! - to burned to a crisp - well, you never know when you might want to start a fire! The controller looks up the value of the switch settings into an array of timer values to determine the length of time that the bread should remain in the toaster. It then sends an asyncrhonous message to the toast popping mechanism, which uses an event queue to process messages without interrupting the toast timer for any reason."

The king wisely had the software engineer beheaded, and the kingdom was once again a happy place.

TL;DR: I don't teach my 2 year old about sentence construction and grammar because she is still learning her letters.

Cas Smiley

Offline sproingie

JGO Kernel


Medals: 201



« Reply #8 - Posted 2011-11-15 18:05:55 »

The funny thing is, all the software engineer really did wrong was the UI.  Use a rotary encoder instead of DIPs, constrain the range to something sensible, and presto.  I remember the old toasters where I had to wait for them to cool down before I used them again.  Modern ones, I can toast ten slices in a row, all perfectly timed.  Then again my old toaster lasted almost my whole childhood, whereas I'm on my third toaster in two years...

BTW, you're teaching your 2-year-old sentence construction and grammar by example.  Kids that young just happen to have really amazing inference skills and in a couple years will put those examples together and figure everything out.  This is what design frameworks like Entity Systems need for their explanations to actually take and mean something to their intended users: non-trivial examples with full working code.
Offline Gudradain
« Reply #9 - Posted 2011-11-15 18:16:45 »

So, I made the choice of purely using the LWJGL for creating my games. After a week or so, I stumbled across 'Entities' – or game objects. After about half an hour I came up with an interface called Entity. The interface declares the following methods:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public interface Entity {
   public void draw();
   public void update(int delta);
   public void setLocation(double x, double y);
   public void setX(double x);
   public void setY(double y);
   public double getX();
   public double getY();
   public double getWidth();
   public double getHeight();
   public void setWidth(double w);
   public void setHeight(double h);
   public boolean intersects(Entity e);
}


After I made this I created an abstract class called AbstractEntity, which basically implements everything but the draw method. For the intersects method I used the class java.awt.Rectangle, lazily initialized as a private instance variable using the width, height, x, and y variables.

My question is: will this code suffice for real use?

Thanks in advance,
TheCodingUniverse

Sorry to be harsh but that suck. You will never be able to put method for every scenario in that class so it's kinda useless.

Just learn aggregation. It solves all your problems... With aggregation you can do anything theagentd mention about EntitySystem with the bonus that your code will be simpler, cleaner and you will have more control over it. Wikipedia should tell you what aggregation is.

Also, you are making a game so it will be hackish for sure. Don't try to make the perfect design and don't try to reuse the same code at the most place possible. The first reason for that is that it takes a lot more time to write general code than to write hackish code. The second is that is also takes way more time to refactor general code than hackish one. If you have a module that is integrated into a bunch of object you will need to make sure that it still behave correctly for all the object when you just want to make a small change for 1 object.

So my 2 advices :
1. Use aggregation - separate all functionality in it's own class
2. Write redundant and hackish code - just do it the easiest way, don't overthink things and refactor when you need

So start coding
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #10 - Posted 2011-11-15 19:32:52 »

The king wisely had the software engineer beheaded, and the kingdom was once again a happy place.
*Grabs neck* My neck! Don't come close!!!


Myomyomyo.
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2011-11-16 13:08:23 »

The funny thing is, all the software engineer really did wrong was the UI.  Use a rotary encoder instead of DIPs, constrain the range to something sensible, and presto.  I remember the old toasters where I had to wait for them to cool down before I used them again.  Modern ones, I can toast ten slices in a row, all perfectly timed.  Then again my old toaster lasted almost my whole childhood, whereas I'm on my third toaster in two years...

BTW, you're teaching your 2-year-old sentence construction and grammar by example.  Kids that young just happen to have really amazing inference skills and in a couple years will put those examples together and figure everything out.  This is what design frameworks like Entity Systems need for their explanations to actually take and mean something to their intended users: non-trivial examples with full working code.
Bah! What is it with engineers they always manage to miss the point of a story because they're concentrating on the details? The software engineer brought with him to the king's audience only a set of plans and no working toaster.

Cas Smiley

Offline lhkbob

JGO Knight


Medals: 32



« Reply #12 - Posted 2011-11-16 18:00:25 »

But it was a set of plans that could have kept him on the payroll doing support for years to come

Offline sproingie

JGO Kernel


Medals: 201



« Reply #13 - Posted 2011-11-16 18:19:04 »

Building an actual toaster?  Pfft, that's a hardware problem Wink

But anyway my point about entity systems still stands: working examples needed.
Offline theagentd
« Reply #14 - Posted 2011-11-16 18:43:37 »

Building an actual toaster?  Pfft, that's a hardware problem Wink

But anyway my point about entity systems still stands: working examples needed.
I did link to Artemis... >_<

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

pw (25 views)
2014-07-24 01:59:36

Riven (25 views)
2014-07-23 21:16:32

Riven (19 views)
2014-07-23 21:07:15

Riven (22 views)
2014-07-23 20:56:16

ctomni231 (51 views)
2014-07-18 06:55:21

Zero Volt (46 views)
2014-07-17 23:47:54

danieldean (37 views)
2014-07-17 23:41:23

MustardPeter (40 views)
2014-07-16 23:30:00

Cero (56 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!