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

Unique ID for every objects using reinterpret_cast

15 posts in this topic

I want my objects to have unique ids, but I heard someone saying using reinterpret_cast<ID>(*itself) will ensure that each objects has an unique ID since no two objects will ever have same memory addresses.
Is this a good idea?
0

Share this post


Link to post
Share on other sites
Probably not.

What happens if you save and reload the game? Every object will be in a different address. What happens when you free an object, and allocate another object later? It could potentially re-use the memory address even though the object is different.

Unique IDs per object can be great for many game designs. A simple number assigned to each object is generally sufficient.
2

Share this post


Link to post
Share on other sites
no.

same memory address will be used after delete/free called on that object.
it is messy.

just use a id generator class. if you want something more advanced i recommend boost::Uuid
2

Share this post


Link to post
Share on other sites
Pointers are also different sizes depending on the target platform. I've worked on projects where the various servers and clients were a mixture of 64- and 32-bit applications, so it would have been very difficult to use any sort of platform-dependent ID type for objects that needed to be communicated between them.
1

Share this post


Link to post
Share on other sites
If you don't want to worry about incrementing, then you can [url="http://stackoverflow.com/questions/3247861/example-of-uuid-generation-in-c"]generate a UUID [/url] for every instance. Edited by alnite
0

Share this post


Link to post
Share on other sites
if you need a very shortlived unqiueness, then the memory address will work fine.

Say you're sorting a handful of pointers, you can simply use the address.

One problem is if these are allocated non-continuous, each ptr is heap allocated, then the sort result will not be deterministic.
Your tools may sort your ai nodes in one order and the build process in another, so when you go to debug node 25 in your tool, it's not the same node 25 that the build process created.

A problem with incrementing IDs is that they wrap. For small tests it may appear that everything works fine. But after soaking your game for a couple days you will very likely wrap your IDs, then you need to deal with "well where do i get the next id from?" you'd need to returned freed ids to a list.

So if you need short lived, automatically recycling ids that simply guarantee uniqueness (locally) and are not deterministic, the memory address is perfectly applicable.
In most other cases, with multiple machines, or multiple runs, where the ids much be the same.. the memory address will fail miserably.
0

Share this post


Link to post
Share on other sites
Personally I strongly suggest to [b]use an incremental index[/b] as well.
Except I've often found it useful to create those indices independantly, for each pool of objects so the id is
[font=courier new,courier,monospace](pool, objectIndex)[/font] where an object can be accessed simply by [font=courier new,courier,monospace]pool[objectIndex][/font].
This still has the easiness of the incremental pointer and provides some useful insight on the type of the object (if the various pools are type-coherent) or their lifetime (if the pool is temporally coherent).
0

Share this post


Link to post
Share on other sites
[quote name='ApochPiQ' timestamp='1353293216' post='5002210']
Why on earth would you ever sort a container of pointers by their address values? What is that even going to accomplish?
[/quote]

Maybe there are duplicate entries in the container, and you want to correlate them. Programming is a mysterious world, with many mysterious tasks.
0

Share this post


Link to post
Share on other sites
+1 to incremental index.
Not to mention using memory ptrs makes your application undeterministic. Each time you run the program, if your data is sorted by pointers, the order will always be different.
0

Share this post


Link to post
Share on other sites
[quote name='Matias Goldberg' timestamp='1353337859' post='5002352']
Not to mention using memory ptrs makes your application undeterministic. Each time you run the program, if your data is sorted by pointers, the order will always be different.[/quote]
Unless, of course, your allocations are guaranteed to be in-order and contiguous placement allocations...

The world of memory-friendly optimisations is a strange and wonderful place ;)
0

Share this post


Link to post
Share on other sites
[quote name='bzroom' timestamp='1353330072' post='5002332']
[quote name='ApochPiQ' timestamp='1353293216' post='5002210']
Why on earth would you ever sort a container of pointers by their address values? What is that even going to accomplish?
[/quote]

Maybe there are duplicate entries in the container, and you want to correlate them. Programming is a mysterious world, with many mysterious tasks.
[/quote]

I'm hard pressed to think of a situation that can't be solved by better means than comparing pointer addresses. That's just begging for undefined behavior.
1

Share this post


Link to post
Share on other sites
[quote name='ApochPiQ' timestamp='1353293216' post='5002210']
Why on earth would you ever sort a container of pointers by their address values? What is that even going to accomplish?
[/quote]
Occasionally, sorting a container of pointers by pointer value can be a performance boost, provided that you need to do batch processes on all the elements in the container, the container contains a sufficient number of pointers, the objects pointed to are sufficiently small enough that multiple objects can fit on a cache line (preferably L1), but the data set is large enough that an appreciable number of cache misses occur, the objects are allocated in a way with low fragmentation and inline overhead and the container is not modified (and hence resorted) frequently. Usually a complete reorganization of data storage is more effective in this kind of situation, but it makes for a low programmer effort speed boost if it works.
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