• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
    59
  • comments
    74
  • views
    43744

Design Flaw

Sign in to follow this  
Followers 0
yckx

366 views

I've realized a design flaw in my entity/component system: I don't have a good way to actually initialize component data! Looky here:
[source lang="cpp"]
Entity e = entity_system.CreateNewEntity();
entity_system.AttachComponent( e, COMPONENT_XFORM );
/* e can now have position, scale and rotation, but how to initialize it? It
* feels kludgy to dispatch a message or fire an event *after*
* creating/attaching the component to initialize it, so I'm thinking of adding
* a parameter to AttachComponent() to pass a struct of initialization data.
* I don't really want to derive all component data structs from a base type,
* but templates don't feel right either. Le sigh...
*/
[/source]I guess I'll spend some time pondering my approach.

Edit:
For the moment, I've changed my approach somewhat, to this:
[source lang="cpp"]
Entity entity = entity_system.CreateNewEntity();
BaseComponent* bc = entity_system.CreateComponent( COMPONENT_RENDERABLE );
dynamic_cast< RenderableComponent* >( bc )->SetData( data );
entity_system.AttachComponent( test_entity, bc );
[/source]I don't really like the idea of handing out pointers to components, but it is workable enough for me to move forward until I can come up with a cleaner solution. I guess what I really need to do is something like [font="Lucida Sans Unicode"]entity_system.CreateAndAttachComponent( entity, COMPONENT_TYPE, component_type_data_struct )[/font]. After thinking about it, it really seems the cleanest way from an interface perspective. Unless someone has a better idea.

But it's 1a.m. and I really need to try to resume a more normal sleep schedule or I'm going to sleep through my early morning Important Doctor's Appointment on Monday. So no more coding for me tonight :(

0
Sign in to follow this  
Followers 0


5 Comments


Wouldn't the initialization be a part of the COMPONENT_XFORM struct? Or is that an enumeration value???

Where is the actual structure that holds the position, scale, and rotation being held?
0

Share this comment


Link to comment
In my system, the AttachComponent (equivalent) call will call the constructor of a new instance of the component and pass e to it. The component is then responsible for initialising itself in the context of entity e, which may require loading it from disk or deriving it from other data.

Arguably, my system isn't without problems - my components can see each other (through indirection via e to e's components), so my 'movable' component can get and modify the 'position' component. I wonder how brittle that's going to end up later...
0

Share this comment


Link to comment
One requirement for my entity-component system was that it had to work with .NET serialization, which was actually pretty tricky. When instantiating an object from disk, the deserializer calls the class's zero-argument constructor (throwing an exception if one does not exist) and then sets all the property values one by one.

I basically made another initialization function that I call after getting the object out from the deserializer. Then you can write your components under the assumption that all your properties have been initialized.

The advantage of this approach is that you can code your factories the same way. Create a new component, assign some properties, then call your custom initialization function. It's not the most elegant approach, but it works.
0

Share this comment


Link to comment
[quote name='Jason Z' timestamp='1316636270']
Wouldn't the initialization be a part of the COMPONENT_XFORM struct? Or is that an enumeration value???

Where is the actual structure that holds the position, scale, and rotation being held?
[/quote]
AttachComponent() creates a new component and attaches it to the entity. COMPONENT_XFORM is an enum, letting entity_system know what component type to create and attach. What I'm struggling with is how best to set component data at the time of entity creation--what it's position and orientation are for the Xform component, or what mesh to reference for a Renderable component. Defaults just don't make sense, so I need to find a good and elegant way of passing these params to the component. If it requires a complete overhaul of the entity/component system then so be it, but I'd like to avoid that if I can ;)

These are the kinds of things that come with experience, and experience is what I'm developing now, I guess ;)
0

Share this comment


Link to comment
The solution our engine took,. which I proposed, was to remove entity ownership of components completely. Each system (or subsystem) such as graphics, physics, etc maintains its components rather than the entity. This reduces the need to pass around a large entity structure, if you use a separate thread or dynamically loaded library for example, and it also increases encapsulation. At the core I gave each Entity the same basic information: location, rotation, scale, and id. This is a simple struct that is passed around to each system to process. When a component is created it is given a pointer to its owner entity, not the other way around like most entity-component designs suggest. Each system stores the components is an array mapped to each entity id. This allows us to process all graphical components for entity n at the same time.
0

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now