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

TwoD

Members
  • Content count

    2
  • Joined

  • Last visited

Community Reputation

122 Neutral

About TwoD

  • Rank
    Newbie
  1. Quote:Original post by wild_pointer I've been thinking of moving to "outboard" component storage and find myself with a pretty much 1:1 ratio of subsystems to component types. I can see myself having many, many component types. How do you manage all these? Also, this seems to make it a lot more difficult to create new components, especially from a script. I see this too in a way. I'm currently sketching out an engine design based on what's been said in this thread and other places, and there does seem to become a 1:1 (or near) relation between components and subsystems. Of course you could allow a subsystem to add more components to an Entity (or just associate them with the Entity and store them in the system itself), depending on which behavior it should have. I guess this depends on how exactly you define your components. On the Engine-level (no game specific components here) I see few occasions where I would need more than one component at a time from each subsystem. It might be a different component depending on type of animation needed from the Animation subsystem and such, but I don't think one would need more than one component from that specific system. On this level subsystems seem to become very strongly associated with their own components. So if you want to add a new behavior to your Entity, you might need to write a new subsystem to take care of that specific task. (Especially since components here seem more like data containers as I've understood it.) #1 I'm going for a subsystem interface, so I can add new subsystems at any time and know that the engine knows how to pass it an Entity if told to (from script perhaps). This could also mean some game specific (above engine level to be clear) subsystems are implemented in script, utilizing script implemented components. The subsystem could of course also be dynamically linked if one so wishes. In "Dungeon Siege" they had a Component Database to manage the components. Each component had a unique id (Siege Component ID) and each Component "template" also had one if I'm not mistaken. When they needed a new component they just asked the DB for it using the template id. Since they had a continous world, they also had to load and unload a whole bunch of components all the time. They solved the problem with maintaining unloded components state using "SCIDBits", 32 bits stored together with the SCID even after the component was unloaded. That way a Chest Component could remember if it had been opened before etc even right at the moment it was loaded back into the world. EDIT: #1) Hmm, what if one would stretch the component "pattern" further and include "plug-and-play behavioral components" in say the animation system? If I want a different type of animation behaviour (skeleton instead of frame based), but would like to keep the framework of the animations subsystem, I could make a new behavior component for the subsystem, and a data component for the Entity. I'm not sure if this would be practical at all, it just hit me it might be worth a thought or two... it's probably more work than replacing the whole animations subsystem with one that does all you want to tho. [Edited by - TwoD on November 1, 2007 10:30:30 AM]
  2. Quote:Original post by Emmanuel Deloget Question: how do you manage 1) data duplication (the bounding box can be of interest to various components; should all components have an embedded bounding box)? 2) components requirements (because I have this component, I shall also have this other one)? Maybe these both questions could be answered by the same mechanism, when adding a component to an Entity? A subsystem which depends on/Observes a different subsystem will most likely know which component(s) the other/Subject subsystem has, say a bounding box. It would not be much point for a subsystem to depend on another one unless it knows what the other one has/does, right? Atleast to some degree... Thus, if subsystems try to intitialize or add its component to an Entity, before it has another component it depends on, it should know which component needs to be added by the missing component's owning subsystem. So it could simply (maybe recursively) tell that other subsystem to init the Entity before it does so itself. To avoid duplicated data, a subsystem could also obtain direct references to other components of that Entity, or perhaps even members in those components, during the add-component/init phase. The references would be relayed to (and stored in) the component which needs them to function by its owning subsystem. There should be little problem as long as subsystems which rely on components from other subsystems make sure they are added before their own. This hopefully also avoids having to "manually" update all members in a component which relies on other component's members, as they would automatically point to updated data at all times. To avoid making these "couplings" so hard that there'll be trouble when changing members of a component/subsystem which are relied upon by other subsystems/components, one could use ideas from Game Programming Gems 2, "A Property Class for Generic C++ Member Access" so exposed component or subsystem members could be referenced indirectly by a more descriptive name such as "Bounding Box" istead of m_aabb. Of course, this "property lookup" between components should all be done during Entity init to avoid performance drops due to having to go through a bunch of indirect couplingd. What do you all think?