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

"Mesh" should be an interface or an abstract class?

32 posts in this topic

[code]
class IMesh
{
public:
virtual void update(float dt) = 0;
virtual void render() = 0;
};

or

class AMesh
{
public:
virtual void update(float dt) = 0;
virtual void render() = 0;
public:
D3DXFRAME *m_Root;
};
[/code]
Any advices please?
Thanks
Jack
0

Share this post


Link to post
Share on other sites
rnlf: Yes, all classes derived from it need a hierarchy of frames/meshcontainers
Hodgman: CCBMesh, CVNAMesh, COperatorMesh etc
swiftcoder: I think I should use aggregation here, comprises of a MeshRenderer and a MeshAnimator?

Represntation == mesh

I've got a diagram here

[attachment=11117:PerfectSim_ClassDiagram3.jpg]


BTW, should I add a class called RigidRepresentation, under it, there are Warehouse, VNA, CB and handtrolley? Edited by lucky6969b
0

Share this post


Link to post
Share on other sites
Hello Aressera,
Could you please recommend a good book on game design techniques based on OOP concepts?
What is a data-driven design anyway? Could you please give an example?

[url="http://www.amazon.com/s?ie=UTF8&page=1&rh=n%3A283155%2Ck%3ACOMPUTERS%20%2F%20Computer%20Graphics%20%2F%20Game%20Programming%20%26%20Design"]http://www.amazon.co...amming & Design[/url]

Yes, I also notice different meshes exhibit similar or common behaviours, they should be in the same "mesh" class.


Thanks
Jack Edited by lucky6969b
0

Share this post


Link to post
Share on other sites
[quote name='Aressera' timestamp='1346921866' post='4977121']
When this strategy is applied to software design, I have noticed that certain patterns of classes emerge. First, I tend to have pure-data classes that just store and manage some data (i.e. the Mesh class). These pure data classes can then be aggregated into larger, more complex data models, or operated on by functions or classes that act as simple operations with some object state (MeshRenderer, MeshAnimator).
[/quote]
This also implies that Mesh is going to be a single, concrete class (every mesh, regardless of what it represents, where it is used, how it is loaded, how it is rendered etc. is a bundle of various vertex and index buffers as Swiftcoder suggests, or more generally a geometry representation that is cheap to render) while MeshRenderer, MeshAnimator and the like might have interfaces, multiple genuinely different implementations and [i]possibly [/i]inheritance hierarchies: unlike meshes, such classes are going to have very few instances and, if they process whole Mesh collections, very few virtual function calls.
0

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1346924791' post='4977129']
[quote name='Aressera' timestamp='1346921866' post='4977121']
Data-oriented design is basically the process of describing the function of a program in data
[/quote]N.B. this is "[i]data-driven design[/i]", not "[i]data-oriented design[/i]". The former is about making data more in control of behaviour rather than code, and the latter is a methodology for writing code that has optimal memory access patterns.
[/quote]

Oops, my mistake. I knew there was a distinction in there but I couldn't put my finger on it.
0

Share this post


Link to post
Share on other sites
Lucky, your hierachy is far too deep and complicated imho. I've tried designs like that before over the years, and they always turn into an unsustainable mess. Swiftcoder finally helped me understand how to implement a good data-driven Renderer design, and I haven't looked back since. Listen to his wisdom and it will help you greatly indeed. ;-)
0

Share this post


Link to post
Share on other sites
Thanks ATC, I listen to the experts too. I'd like to see some diagrams on how a data-driven system is designed.
:) Yes, I am trying to conform to the standards.
Thanks
Jack
0

Share this post


Link to post
Share on other sites
In my engine I first made "Mesh" an abstract class. However, I changed it to an interface, "IMesh", a couple weeks ago and it works out better. I just implement new Mesh classes for DirectX10, 11 and OpenGL and let the engine pass around IMesh and IMeshIndexed references... the underlying rendering API and its bindings don't matter, keeping the code weakly/loosely (or not at all) coupled and engine components tidy, clean and easily maintainable. So I say go with an interface-type design. Interfaces are most often badly underused or terribly abused. But find a happy medium and your code will be excellent and almost pain-free to work with!
0

Share this post


Link to post
Share on other sites
[quote name='lucky6969b' timestamp='1347954159' post='4981169']
Is this you guys talking about?
[url="http://dundee.cs.queensu.ca/wiki/index.php/CAX_Game_Architecture"]http://dundee.cs.que...me_Architecture[/url][/quote]
A word to the wise: your life doesn't have to be ruled by UML diagrams and class hierarchies. Formal design process has a place, but it's generally not necessary to be so formal.

A lot of the beauty of data-driven design is in how it simplifies designs:
[code]struct Mesh
{
VertexBuffer *vertices;
IndexBuffer *indices;
};

struct Camera
{
Matrix4 viewMatrix;
Matrix4 projectionMatrix;
};

class IMeshAnimator
{
IMeshAnimator(const Mesh &mesh);
virtual void update(float deltaTime) = 0;
};

class IRenderer // Has OpenGLRenderer and D3DRenderer as subclasses
{
virtual void render(const Mesh &mesh, Matrix4 modelMatrix, const Camera &camera) = 0;
};
[/code]

Take a look at how conceptually clean this is:
- The Mesh and Camera classes are just pure data containers.
- The MeshAnimator uses composition, instead of inheritance.
- The Renderer just deals with individual render operations.
2

Share this post


Link to post
Share on other sites
[quote name='lucky6969b' timestamp='1348026747' post='4981528']
That's beauty. Thanks
[/quote]

Indeed it is. I hadn't ever been properly exposed to those ideas until I ran into swiftcoder and had a very interesting conversation. The data-driven design really [i]is[/i] amazing. Since then I've started reading technical articles on the subject from nVidia, and my questions are becoming less and less frequent/necessary. Have a look at [URL="http://http.developer.nvidia.com/GPUGems/gpugems_ch36.html"]this article[/URL] when you begin working shaders and materials into your engine/app.
0

Share this post


Link to post
Share on other sites
Swiftcoder's example is almost exactly how I started out with my first graphics engine. Only I wasn't using interfaces for rendering, since the engine was targeted only for DirectX 9.

Some other challenges you may plan for in the future: After you get your basic renderer working, figure out how to cull objects. Maybe sort your objects in different containers and pool for the ones you need to render.
0

Share this post


Link to post
Share on other sites
[quote name='CC Ricers' timestamp='1348068607' post='4981715']
Some other challenges you may plan for in the future: After you get your basic renderer working, figure out how to cull objects. Maybe sort your objects in different containers and pool for the ones you need to render.
[/quote]

I'd also suggest culling in a "chain", of sorts:

Scene Node >> Object >> Model >> Mesh

For instance, a large model made up of many individual meshes or an "object" made up of several models might only be partially on camera. You would not want to cull that entire object/model, nor would you want to draw the entire thing and waste "GPU juice" (lol). So you test in sequence... first make sure the scene node is visible at all, then checks its object groups, then the models of each object group and the meshes of each model.

If your game is very small and simple then this broad testing can be a bottleneck. But in large game worlds populated with tons of geometry it can indeed save a lot of time; especially when individual models and their meshes are required to use multiple textures with complex shaders and dynamic lighting parameters.
0

Share this post


Link to post
Share on other sites
Can you point me to that conversation you had with swiftcoder perhaps please?

I've done about half the DX11 rastertek tutes, and I'd like to start building something more sensible, and what you've suggested here makes a lot of sense.

I've got a vague idea of what I want, but I've only three years C++ / UML. I've bought two books from Amazon about C++/DX11, they look like the most recommended but they haven't been delivered yet. That conversation would make beautiful reading!
0

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1347998187' post='4981380']
[quote name='lucky6969b' timestamp='1347954159' post='4981169']
Is this you guys talking about?
[url="http://dundee.cs.queensu.ca/wiki/index.php/CAX_Game_Architecture"]http://dundee.cs.que...me_Architecture[/url][/quote]
A word to the wise: your life doesn't have to be ruled by UML diagrams and class hierarchies. Formal design process has a place, but it's generally not necessary to be so formal.

A lot of the beauty of data-driven design is in how it simplifies designs:
[code]struct Mesh
{
VertexBuffer *vertices;
IndexBuffer *indices;
};

struct Camera
{
Matrix4 viewMatrix;
Matrix4 projectionMatrix;
};

class IMeshAnimator
{
IMeshAnimator(const Mesh &mesh);
virtual void update(float deltaTime) = 0;
};

class IRenderer // Has OpenGLRenderer and D3DRenderer as subclasses
{
virtual void render(const Mesh &mesh, Matrix4 modelMatrix, const Camera &camera) = 0;
};
[/code]

Take a look at how conceptually clean this is:
- The Mesh and Camera classes are just pure data containers.
- The MeshAnimator uses composition, instead of inheritance.
- The Renderer just deals with individual render operations.
[/quote]

I can't understand this, if the Renderer is responsible for updating its children, I expect to use a pointer like this
[code]
class IRenderer
{
virtual void render(const Mesh &mesh, Matrix4 modelMatrix, const Camera &camera) = 0;
};

class CD3DRenderer : public IRenderer
{
void render(const Mesh &mesh,....);
bool UpdateFrame (Mesh *mesh, Matrix4 world);
};

bool CD3DRenderer::UpdateFrame(Mesh *mesh, Matrix4 world)
{

UpdateAllChildren((D3DXFRAME_DERIVED*)m_mesh.m_Root, world);
}

void CD3DRenderer::UpdateAllChildren(D3DXFRAME_DERIVED* pFrame, D3DXMATRIX* pMat)
{
if (pFrame == NULL) return;

D3DXMatrixMultiply(&pFrame->CombinedTransformationMatrix,
&pFrame->TransformationMatrix,
pMat);
if(pFrame->pFrameSibling)UpdateAllChildren((D3DXFRAME_DERIVED*)pFrame->pFrameSibling, pMat);
if(pFrame->pFrameFirstChild)UpdateAllChildren((D3DXFRAME_DERIVED*)pFrame->pFrameFirstChild, &pFrame->CombinedTransformationMatrix);
}

[/code]
The problem is when I pass in the mesh as const&, the mesh cannot be modified, I have integrated the knowledge of swiftcoder and Aressera.
Thanks
Jack Edited by lucky6969b
0

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