Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (482)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
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  
  Article #2: Managing Game Entities (gameprogblog) - uses Java 2D  (Read 2579 times)
0 Members and 1 Guest are viewing this topic.
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Posted 2013-01-13 21:11:05 »

Here's my second article, it's on managing game entities!
 
http://www.gameprogb...aging-entities/
 
Thanks for any input!

Online HeroesGraveDev

JGO Kernel


Medals: 245
Projects: 11
Exp: 2 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #1 - Posted 2013-01-13 21:20:59 »

Your link is broken.

Offline Rorkien
« Reply #2 - Posted 2013-01-13 21:56:01 »

Your link is broken.

http://www.gameprogblog.com/managing-entities/

ftfy

Also, nice tut  Shocked
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #3 - Posted 2013-01-14 00:24:44 »

Ah, thanks!

Online HeroesGraveDev

JGO Kernel


Medals: 245
Projects: 11
Exp: 2 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #4 - Posted 2013-01-14 00:33:31 »

Nice tutorial. Nice ideas. Basically the same as my implementation, so I have nothing to add.
The problem is that managing entities is a trivial task that depends on basic programming skills. If you can't do it, you either shouldn't be programming, or you should learn things in the correct order.
So writing a tutorial attracts n00bs of which some may even fail to follow this and start complaining.
It shouldn't matter though. Do what you feel like.

Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #5 - Posted 2013-01-14 00:40:29 »

So writing a tutorial attracts n00bs of which some may even fail to follow this and start complaining.

Hence why I include source code and an applet  Grin

Thanks for the input.

Offline 65K
« Reply #6 - Posted 2013-01-14 18:02:13 »

Some thoughts:
Less and more common colors would make the code more readable.

To me, class responsibilities are not clearly defined but mixed up a bit:
EntityLayer should not inherit from EntityList, but use one
Describe the benefit of classes EntityLayer and EntityLayers, why can't single entities be invisible or disabled ?
Why does EntityList has methods like draw and update, instead of just iterating through the list and calling those methods on entities ?

Offline sproingie

JGO Kernel


Medals: 202



« Reply #7 - Posted 2013-01-14 21:25:49 »

EntityLayers looks pretty well-designed where it's using an enum type parameter as an ordering trait.  Making it an Entity itself however, does seem rather off.

Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #8 - Posted 2013-01-16 04:26:33 »

Less and more common colors would make the code more readable.

Thanks!

To me, class responsibilities are not clearly defined but mixed up a bit:
EntityLayer should not inherit from EntityList, but use one

What don't you like about this?

Describe the benefit of classes EntityLayer and EntityLayers, why can't single entities be invisible or disabled ?

They can, it's up to the Entity implementations whether they have a visible/enabled flag. I used to have setters/getters in Entity for those properties but realized not every entity needs these.

Why does EntityList has methods like draw and update, instead of just iterating through the list and calling those methods on entities ?

That's exactly what it does.

Making it an Entity itself however, does seem rather off.

What don't you like about that?

Offline 65K
« Reply #9 - Posted 2013-01-17 18:11:12 »

To me, class responsibilities are not clearly defined but mixed up a bit:
EntityLayer should not inherit from EntityList, but use one

What don't you like about this?
Old story of inheritance vs. composition.
Single responsibility principle.
It is inflexible, exposes implementation details (stuff is always stored in a list). List is rather, or should be, a collection class, layer is part of the entity domain. To me, looking further to Entitylayers (an entity itself) makes it quiet confusing.

Furthermore, EntityList has a dependency to Graphics2D, all in all making it homeless child of three application responsibilities / tasks:
- utilities, collection classes
- model (the game entities)
- visualization (hard bound to Java2d graphics stuff)


Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #10 - Posted 2013-01-18 04:04:34 »

To me, class responsibilities are not clearly defined but mixed up a bit:
EntityLayer should not inherit from EntityList, but use one

What don't you like about this?
Old story of inheritance vs. composition.
Single responsibility principle.
It is inflexible, exposes implementation details (stuff is always stored in a list). List is rather, or should be, a collection class, layer is part of the entity domain. To me, looking further to Entitylayers (an entity itself) makes it quiet confusing.

Furthermore, EntityList has a dependency to Graphics2D, all in all making it homeless child of three application responsibilities / tasks:
- utilities, collection classes
- model (the game entities)
- visualization (hard bound to Java2d graphics stuff)

I guess it depends on what you define as a responsibility, I consider "managing entities" the responsibility of EntityList, I think breaking it up just to break it up is silly and a more separated design uses more memory and is less efficient.

Having said that, I would remove EntityLayer and have EntityLayers just maintain an array of EntityLists directly. EntityLayer is a pointless class.

Also, this is a code example and not a game engine. In my game engine I don't have dependencies on specific graphics libraries and everything is well decoupled compared to the article's code.

Perhaps I don't understand how you would structure your game, how would you do it and what parts of your structure do you feel are superior? I have always had this sort of design, and I haven't seen anything else, so I'm having problems thinking of alternative architectures.

Thanks again for your input, I enjoy the back and forth - I am always up for learning new things.


Offline Roquen
« Reply #11 - Posted 2013-01-18 09:52:27 »

Like with game-loops (and everything else) there is no one-design-that-fits-all scenarios.  I won't attempt to address 65K's views, but all toss out a small subset of issues:

1) composition can lead to cleaner and/or more flexiable design...given certain game design requirements and how the principle programmers brains work.  For instance some folks like the prototype based notion of "component-based" (one method of data-oriented) and I'm a fan of the hybrid prototype/open-class based notions that I poorly & half heartedly attempt to explain here: ArchTypes, composition and code is data.  A combination of the game-design and how the main programmer's "see" code should partially dictate how the entity-system is constructed.  And this is somewhat ignoring using a DSL and/or an actor/continuation model.
2) Multi-threading: depending on how task are segregated between threads (should) effect how the entities are composed.  Basically data that is manipulated together ideally should live together.
3) Queries:  The raw number of "active" entities and how they are distributed through-out the game world should heavy impact how the runtime entity database in constructed...some linear list like, spatial partitioning, etc.
4) Memory accesses: Similar to the multi-threading issue & coupled with queries - if the number of active entities is high enough, it can be important to segregate data into (say) a flattened list inside some spatial partitioning for instance.
Offline 65K
« Reply #12 - Posted 2013-01-18 16:52:46 »


I guess it depends on what you define as a responsibility, I consider "managing entities" the responsibility of EntityList, I think breaking it up just to break it up is silly and a more separated design uses more memory and is less efficient.
If you want to "manage" something, alarm lights should start blinking, as that is a common starting point for multi-purpose almighty god-classes.

Let's say you implement a super-clever highly efficient entity list class. One day, you decide to develop a little game for Android. As the dalvik engine is not as good as a real Java VM, you think that the entity list stuff comes in handy... too bad only, that Android has no Java2d package.

Who cares, you say, lets hack together a multiplayer client/server game instead. But that entity list has a dependency to the graphics sub system, does it make sense for the server backend ?
You break things up to develop more efficiently, to reuse stuff, to ease testing, to get more stable programs. There is no (relevant) impact on memory usage just from doing so.

Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #13 - Posted 2013-01-19 18:58:04 »

Like with game-loops (and everything else) there is no one-design-that-fits-all scenarios.  I won't attempt to address 65K's views, but all toss out a small subset of issues:

1) composition can lead to cleaner and/or more flexiable design...given certain game design requirements and how the principle programmers brains work.  For instance some folks like the prototype based notion of "component-based" (one method of data-oriented) and I'm a fan of the hybrid prototype/open-class based notions that I poorly & half heartedly attempt to explain here: ArchTypes, composition and code is data.  A combination of the game-design and how the main programmer's "see" code should partially dictate how the entity-system is constructed.  And this is somewhat ignoring using a DSL and/or an actor/continuation model.
My game engine is designed this way, I have simple state data in my entities and I have several components that can be used for an entity... one for attaching particle effects, one for steering behaviors, one for pathfinding, one for spatial databases, etc.
2) Multi-threading: depending on how task are segregated between threads (should) effect how the entities are composed.  Basically data that is manipulated together ideally should live together.
I don't think the design of the tutorial's code is anti-multi-threading whatsoever, it all depends on how you use multi-threading in games. The most I've personally used is a thread to load data in the background. Even if I used threading in games, it would be a simple "pop request on queue" and the thread would listen to the queue, solve the problem, and put a response on a queue for the main game thread to pick up.
3) Queries:  The raw number of "active" entities and how they are distributed through-out the game world should heavy impact how the runtime entity database in constructed...some linear list like, spatial partitioning, etc.
I use a component for this
4) Memory accesses: Similar to the multi-threading issue & coupled with queries - if the number of active entities is high enough, it can be important to segregate data into (say) a flattened list inside some spatial partitioning for instance.
Not quite sure exactly what your talking about.

If you want to provide code examples if you still disagree with me, it's far easier to understand code examples then read someones explanation... words have too many meanings, code is the best means of communication :-P

I guess it depends on what you define as a responsibility, I consider "managing entities" the responsibility of EntityList, I think breaking it up just to break it up is silly and a more separated design uses more memory and is less efficient.
If you want to "manage" something, alarm lights should start blinking, as that is a common starting point for multi-purpose almighty god-classes.
I have no idea how else I would structure entities other than a list or linked structure, maybe a code example on how you do this?
Let's say you implement a super-clever highly efficient entity list class. One day, you decide to develop a little game for Android. As the dalvik engine is not as good as a real Java VM, you think that the entity list stuff comes in handy... too bad only, that Android has no Java2d package.
The code is easy enough in the tutorial for you to break out Graphics2D yourself, my game engine follows with what your saying, I have no dependencies on anything in Java, and no dependencies on graphcis libraries, I've pulled out the dependency by creating a simple MVC framework.
Who cares, you say, lets hack together a multiplayer client/server game instead. But that entity list has a dependency to the graphics sub system, does it make sense for the server backend ?
Completely agree!
You break things up to develop more efficiently, to reuse stuff, to ease testing, to get more stable programs. There is no (relevant) impact on memory usage just from doing so.

Thanks for the reply!

Offline Roquen
« Reply #14 - Posted 2013-01-19 19:26:56 »

My commentary was a generalized play on 65K's comment and not directed at your tutorial.
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #15 - Posted 2013-01-19 19:27:23 »

Ah okay, thank you.

Offline 65K
« Reply #16 - Posted 2013-01-20 12:42:44 »

I guess it depends on what you define as a responsibility, I consider "managing entities" the responsibility of EntityList, I think breaking it up just to break it up is silly and a more separated design uses more memory and is less efficient.
If you want to "manage" something, alarm lights should start blinking, as that is a common starting point for multi-purpose almighty god-classes.
I have no idea how else I would structure entities other than a list or linked structure, maybe a code example on how you do this?
My point was that problems could start if "manage" gets a too broad definition.

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.

CopyableCougar4 (14 views)
2014-08-22 19:31:30

atombrot (28 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (61 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38
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!