• 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.
Sign in to follow this  
Followers 0
KaiserJohan

Structuring a scene

3 posts in this topic

Hello,

I have made a basic scenegraph, with a Scene and SceneNodes. The Scene has a root SceneNode and each SceneNode has a parent and a number of child nodes. Each SceneNode has a transform related to its parent aswell. 

 

 

 
    

 

/* Scene definition */
    class Scene
    {
    public:
        Scene(const std::string& sceneName);
        ~Scene();


        Camera& GetSceneCamera();
        SceneNode& GetRootNode();
        const std::string& GetSceneName() const;


        bool operator==(const Scene& s1);
        bool operator==(const std::string& sceneName);


    private:
        const std::string mName;
        size_t mHashedID;
        Camera mSceneCamera;
        SceneNode mRootNode;
    };
 

 

 

/* SceneNode definition */
    class SceneNode
    {
    public:
        SceneNode(const std::string& nodeName);
        ~SceneNode();


        SceneNode* CreateChildNode(const std::string& nodeName);
        SceneNode* FindChildNode(const std::string& nodeName);
        bool DeleteChildNode(const std::string& nodeName);
        bool DeleteChildNode(SceneNode* node);


        void Scale(const Vec3& scaleVec);
        void Translate(const Vec3& translateVec);
        void Rotate(const float angle, const Vec3& rotateVec);


        void UpdateModelMatrix(const Mat4& parentModelMatrix);


        const Mat4& GetModelMatrix() const;
        const std::string& GetNodeName() const;
        const vector<SceneNode*>& GetChildNodes() const;


        bool operator==(const SceneNode& s1);
        bool operator==(const std::string& nodeName);




    private:
        const std::string mName;
        size_t mHashedID;
        vector<SceneNode*> mChildNodes;
        IMemoryAllocator& mMemoryAllocator;


        Mat4 mModelMatrix;
        Quaternion mOrientation;
        Vec3 mScale;
        Vec3 mTranslation;
    };
 

 

 
 

Now I want to start adding things like meshes (and later lights all such things), but I'm unsure how to best structure it. For example should I add components like meshes directly into the SceneNodes themselves, or should I keep them in the Scene and have them refer to a SceneNode? What is the best practice when it comes to this?

 

Also, what is an 'entity' and how is it generally used?

0

Share this post


Link to post
Share on other sites
In the traditional sense of "scene graph" we are speaking of a "one-for-all" structure, where each and everything is pressed into this one structure. You may gather from this wording already that I'm not a fan of scene graphs ;)

An "entity" is even less well defined. An entity on the sense of the nowadays somewhat popular "component based entity system" (CES for short) is just a placeholder or identifier or sometimes a container of components, perhaps with message distribution functionality. The is no standard, and a best practice does not exist IMHO.

So, if you mean those both concepts, you are already speaking of very different things. Furthermore, in a traditional scene graph a mesh would be an own node inside the graph. When you say "storing the mesh anywhere outside the graph but in the scene and letting them refer to the scene node" it sounds to me that this is just another kind of concept. I.e. it sounds that what you call the scene graph is just a tree of FK ("parenting") dependencies, while the meshes may be organized in another way, perhaps in a spatial structure.

Being confused of what you are actually doing, I recommend to not follow the traditional scene graph but to use a couple of specialized structures to organize the scene. I personally prefer CES as one of the aforementioned specializations when it comes to structuring game entities. I further prefer the entity not being explicit, and the components being managed in sub-systems. However, it makes no sense to program a (highly) complex solution for a game with low scene complexity; so you still have to decide... Edited by haegarr
1

Share this post


Link to post
Share on other sites

I'm thinking of making the Scene somwhat like Ogre3ds SceneManager, i.e it manages the entities/lights/meshes etc alongside the scenenodes. Is there any good alternative?

0

Share this post


Link to post
Share on other sites

I'm thinking of making the Scene somwhat like Ogre3ds SceneManager, i.e it manages the entities/lights/meshes etc alongside the scenenodes. Is there any good alternative?


Yes. The scene graph doesn't need to be explicit. All you need is the ability to set parent transformations and this can be handled by the entity system. All the renderer needs is the final transformation of the mesh. It shouldn't care about relationships between game objects.

The renderer can use whatever structure you like internally, but there's no need to expose it because what's most efficient for rendering is not necessarily the best for scene management.
1

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0