Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (121)
games submitted by our members
Games in WIP (577)
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  Game Development / Game Play & Game Design / Re: Game Object Component System on: 2009-09-01 03:00:30
I dig this idea but I'm confused about a few things.  The post linked to here from T=Machine mentions that the Flyweight pattern should be used for components (he said this in the context of adding functions to components but since functions are not relevant to Flyweight I assume that he meant the statement to be general).  Right below that it says "all data lives in Components; ALL data"...

So I've got a component for "Position".  It holds my Entities' 3D position.  For it to be flyweight wouldn't make sense since it updates its data to what is basically a random value constantly (creating a bunch of instances!).  Maybe he was mentioning Flyweight as only for cases where its useful?  I would not expect it to be normally useful but I might have confused the whole thing.

I'm also not sure how I could have, say, a Physics component/system, an Animation component/system and a Collision handling component/system and have them coexist safely.  I assume that individual systems need to synchronize with one another but aren't they supposed to be completely distinct?  Or is this an "as distinct as possible -- suffer through the synchronization" kind of deal.  How can three systems (potentially with order dependencies) update/utilize the same entity's position value?

( Is this similar to categories in Objective-C?  Or mix-ins in other languages?  Also see Groovy DOM-Categories : http://groovy.codehaus.org/Groovy+Categories )

Finally, the analogy to RDBMS is spot-on.  I see the entity idea less as declarative-programming than procedural-programming (which undeservedly got a bad name after its popularity faded).  Of course, an OODBMS isn't usually a bad thing either.  If they work for your games needs then switching to db4o or something is smart.  I find it hard to use because of its object activation policy and I don't have serialization bottlenecks so I haven't bothered but if I did I'd switch DBMS in a heartbeat.

- Handyman
Pages: [1]
 

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

The first screenshot will be displayed as a thumbnail.

theagentd (20 views)
2014-10-25 15:46:29

Longarmx (53 views)
2014-10-17 03:59:02

Norakomi (47 views)
2014-10-16 15:22:06

Norakomi (35 views)
2014-10-16 15:20:20

lcass (39 views)
2014-10-15 16:18:58

TehJavaDev (69 views)
2014-10-14 00:39:48

TehJavaDev (69 views)
2014-10-14 00:35:47

TehJavaDev (61 views)
2014-10-14 00:32:37

BurntPizza (74 views)
2014-10-11 23:24:42

BurntPizza (46 views)
2014-10-11 23:10:45
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!