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

Underlying structure of a game

5 posts in this topic

Hi I'm trying to figure out how to structure my game. My plan is to have objects that consists of several children that could be separated from the parent, like a human losing an arm etc. But my problem seems to be how to do with the meshes. My meshes can consist of several sub meshes and for a humanoid each part needs to be associated with a sub mesh, because my humanoid models are built as such. So how would be a good idea to go about accomplishing this? Should I split the mesh into several meshes consisting of a sub mesh each and associate the limb objects with this or do I associate each limb with a sub mesh?

If I split the full mesh into several other new meshes consisting of one limb each it feels useless to have a sub mesh class since I'd need to split most multiple-submesh-meshes up into their own individual meshes anyway. I also need to associate some objects with meshes (consisting of an arbitrary number of sub meshes) that are not supposed to be split or anything fancy like that.

I don't know if there are some obvious errors with my suggestions or if there's a good solution but I'd like to hear you guys' thoughts on this.

Thanks in advance!
1

Share this post


Link to post
Share on other sites
Is what you're trying to do anything like this?: [url="http://laserbrainstudios.com/2011/02/image-optimizations/"]http://laserbrainstudios.com/2011/02/image-optimizations/[/url]
0

Share this post


Link to post
Share on other sites
[quote name='Splinter of Chaos' timestamp='1304179417' post='4804774']
Is what you're trying to do anything like this?: [url="http://laserbrainstudios.com/2011/02/image-optimizations/"]http://laserbrainstu...-optimizations/[/url]
[/quote]

No, the problem is how the Object class will relate to the Mesh class. I have some requirements I can't seem to fulfill without feeling it's a cheap hack.

- Some objects will logically be treated as a single object though consisting of several meshes/submeshes (like a house with windows and walls etc). So this could be satisfied with an Object class related to a Mesh class in turn consisting of several Submeshes.

- Some other (like humanoids) are supposed to be destructible, as in limbs detached and then treated as individual objects. If I had a Mesh class consisting of a number of Submeshes this could be solved by having each child object of the humanoid connected to a submesh each. But then if it's destroyed how is this handled with the mesh? Would I create a new Mesh instance with a single subset, the submesh it's connected to? And it would also require each child object of the whole humanoid object (the limbs) to be of a special kind to be connected to Submeshes instead of Meshes as in the other cases.

I've only come up with 2 solutions I don't like, which are that every Submesh of every Mesh (as they are created) are really their own Mesh so there would be no Submeshes at all, but this would produce the problem with having an object consisting of several Meshes/Submeshes. The other is that a Mesh consists of a number of Submeshes and if a destructible object with several parts would then create more and more instances of Meshes with a single Submesh (which comes from another Mesh consisting of all related Submeshes) when detached from each other.

How is this generally handled? Is there even a general solution? What are your opinions?
1

Share this post


Link to post
Share on other sites
I'm relatively uninformed compared to the other members of this forum, but i have an idea (might be completely useless) and hopefully someone will give you a better one. [img]http://public.gamedev.net/public/style_emoticons/default/smile.gif[/img] Also, when you said mesh, i thought texture, but i googled and found you probably meant the 3D set of vertices.

I'd think you'd want to draw each submesh as if it was its own object. That way, if a limb gets detached, none of the other limbs/whatever are affected and the affected limb can keep its mesh without modification. Actually, i'd make the class (Human, for example) not worry about the mesh at all, but rather have the class hold a member called body, leftArm, rightArm, etc., and have those handle the meshes/submeshes. Again, this way, if a limb gets detached, no other limb is affected and the detached member wouldn't need modification, except that it would no longer be linked to the body.

The other option you mentioned i'd think would be a lot harder. The basic problem you seem to have is: should i make simple components in a complex system, or a complex system with simple components? I don't know that one is better than the other, but i hope you find an elegant solution with a simple system and simple components.
0

Share this post


Link to post
Share on other sites
I would suggest something like the following:
1) build your skinned humanoid mesh as one solid mesh.
2) break up the mesh's index buffers based on materials as usual.
3) Now, separate all the index buffers into your "sub mesh" groups.
4) Next, make new meshes for each "gib" that you want to spawn. These could be skinned meshes of an upper and lower arm, or just pieces of the arm, or both in a recursive fashion.
5) Add in some attachpoint information to your models so that you can specify where on each parrent mesh the appropriate gib spawns from (and what bone).

Now, to draw each human, you render only the index buffers for active meshes on the human. When you shoot off an arm, spawn the new child mesh "gib" (and copy over position / bone information). Then turn off the appropriate sub mesh on the parent. THe "gib", being its own object can now repeat the same process as the human it spawned from, allowing it to break into more pieces.

This approach will let you keep all the proper skinning on a model (as it remains a single mesh), while letting your disable parts of the mesh (by not rendering those index buffers). The severed arm is it's own seperate mesh / object, as it no longer has anything to do with the main model.
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