Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Sep 2011
Offline Last Active Aug 22 2016 12:33 AM

#5041176 Assigning special number to each class type at compile time

Posted by on 09 March 2013 - 09:19 AM

Of course, you could go all fancy and generate these unique class IDs automatically using template magic! *Applause*

You want to write your classes, and you don't want to manually assign a unique id to each one of them. Luckily you can make your compiler do the class counting. First you'll need a Base class with a static variable that counts your classes:

class Base {

  // Virtual function to get the unique class id (special number)
  virtual int getUniqueClassId(void) const = 0;
  // This static variable counts your classes (it exists exactly once in the entire program)
  static int uid_count;

Next you'll need a "SpecialBase" class. A class that exists between your actual class and your base class. Via template magic, this class will automatically do the counting for you. In order for this to work, we use a basic template feature. Your compiler does not consider a class with template parameter a single class. SpecialBase<A> and SpecialBase<B> are considered completely separate classes that just happen to use the same code. So if your SpecialBase class were to have a static variable, that variable would be created once for each specialized class you use in your program.

You can use that to create the following:

template <class SpecialClass>
class SpecialBase : public Base {

  // This function gives you the unique class id of an object
  int getUniqueClassId(void) const { return getUniqueClassIdStatic(); }

  // This function gives you the unique class id
  static int getUniqueClassIdStatic(void) {
    if (uid >= Base::uid_count)   // If the unique id is invalid...
      uid = Base::uid_count++;    // ... set the id and increment uid_count
    return uid;
// This static variable is your classes unique id (it exists once for
// each of your classes)
  static int uid;

// Initialize the unique id to an invalid value
template <class SpecialClass> int SpecialBase<SpecialClass>::uid = INT_MAX;

There now exists a static uid variable for each variation of the SpecialBase class and they are all initialized to INT_MAX.
The first time anyone asks for the unique class id (by calling getUniqueClassId(), or getUniqueClassIdStatic(), a new unique id is created, based on the current uid_count we defined earlier in the Base class. The counter of the Base class (the one that exists only once in the entire program) is then incremented. Therefore, the next class that asks will automatically get a new and unique id. Keep in mind though: The order the ids are given out is based on the order they are first queried at runtime (see below for more info).

Oh and in some .cpp file somewhere you'll obviously want to initialize uid_count to zero:

#include "Base.h"
// Initialize the unique id count to 0
int Base::uid_count = 0;

How is this actually used?

// Define your classes (yep, that's all)
class A : public SpecialBase<A> { };
class B : public SpecialBase<B> { };
class C : public SpecialBase<C> { };

// Determine an object's class:
C obj;
if (obj.getUniqueId() == A::getUniqueIdStatic()) // false
  std::cout << "Object is of class A";
if (obj.getUniqueId() == B::getUniqueIdStatic()) // false
  std::cout << "Object is of class B"; 
if (obj.getUniqueId() == C::getUniqueIdStatic()) // true
  std::cout << "Object is of class C";

Note that you won't have to touch the getUniqueClassId() functions in your own code. All you have to do, is make sure that your class inherits from SpecialBase and that you use your own classes name as the template parameter. (Thus ensuring that no two classes inherit from the same specialization of SpecialBase)

Oh, but I wanted control over which class gets which index, or at least some kind of order!
Just forcibly query some ids, before doing anything else...

int main(void) {
  A::getUniqueClassIdStatic(); // A is assigned 0
  C::getUniqueClassIdStatic(); // C is assigned 1
  B::getUniqueClassIdStatic(); // B is assigned 2
  F::getUniqueClassIdStatic(); // F is assigned 3

  // your stuff...

I hope this helps! Depending on your project, this may be a little much. It just happened to be what I was working on recently. (And you could probably take this even further by using enums instead of static variables... but I'll just doubt that you have several million classes for these few static vars to create any performance issue)

#5026322 Monsterra

Posted by on 28 January 2013 - 05:09 AM

    Zeitlineal, ruler of Time

I think I see what you were going for here, but I'm not sure the name means what you think it means. The german does translate to "ruler of time", but with the "ruler" being the measuring instrument, rather than the regent. The name just looks really off... happy.png

Regarding the creation myth itself:

The myth, as it is presented, is fairly generic, with the different Spirits doing their respective thing. Feels like there are already many variations of this around, so you may have to look into ways to make your own approach a little more interesting.


My first suggestion would be making the creation a little more condensed:

  • Arknell (Monsterra) creates Zeitlineal (Time) and Espace (Space)
  • Time and Space are created.
  • from Zeitlineal and Espace spring Erderra (Earth), Aqcuasser (Water), Aeridon (Air) and Vita (Life).
  • Earth, Water, Air and Life are created.

I like that you try to add personality to your mythical Monsterra. That's something that you could expand upon.

I was rather surprised to see earth being the impatient one. In my mind earth carries rather stoic properties. I would have naturally assumed air or life to be more impatient. I would also have assumed life to be the last thing created, as it requires the other elements to exist.


Reading your description I imagined Arknell as a grandfatherly figure, and Zeitlineal and Espace being the parents to four bickering siblings. I like the rivalry between earth and water, and would like to see air and maybe life added to that mix. Life would also make for a prime candidate for "being punished for impatience" (again, it would make sense if it were created last). Its punishment could have been to constantly having to renew itself, thus explaining the entire life/death thing.

#4969805 A stealth weapon that's never been done before

Posted by on 15 August 2012 - 05:36 AM

Boomerang - after hitting a target it returns and you have to catch it. if you don't hit an enemy, it wont return.

Wait, isn't that the opposite of how a boomerang is supposed to work?

I like the idea of simple rocks in a zombie survival scenario. Ammo conservation is an important aspect of survival and rocks are not only plentiful but also highly reusable.

How about small throwable rocks or bricks?
You hit an enemy and there's a (mostly silent) squishy impact. If you miss, the rock/brick causes considerably more noise (depending on the surface it lands on?). However, the noise originates from the point of impact. That way rocks can not only be used as stealthy weapons, but also to create diversions.

#4964662 Realitive size in games

Posted by on 30 July 2012 - 06:37 PM

I'm not aware of any definitive standards, AFAIK it's just an arbitrary scale that has to be set depending on the project. You usually want your grid to map to a real-life unit of measurement (imperial/metric), while also keeping your floating point values from growing too high. There are workarounds for the floating point issue, but sticking to a scale in which you can rely on accuracy is always simpler. A large-scale RTS may use a scale of .1 = 1 kilometer, while an FPS may use .1 = 1meter (I just made those numbers up, so don't quote me there). It depends somewhat on the scale of what you want to display, but mostly on personal preference.

As for the size difference between projects, you can always just scale your models accordingly. It's important to keep in mind that all these values are purely relative.

#4964242 Why do most FPS games have 2 teams?

Posted by on 29 July 2012 - 07:09 AM

I guess because of "If you're not with us, you're against us" logic.

That is definitely part of it, but wouldn't that statement be true for any number of teams?
A related question: Why do most (all?) sports have only two teams?
(Is there a competitive sport with more than two teams at the same time? Really, I'm not a sports person at all.)

I believe having only two teams is the easiest way to determine a fair winner/loser. Consider for example a match between three teams A,B,C. Team A may be objectively "better" at playing the game than either Team B or Team C and would dominate either in a one-on-one match. However, in this scenario Team B and C could gang up on Team A (knowingly or by coincidence) and thus deafeat A. This is usually not what you want for ranked competitions.

Now, I'm not saying that having more than two teams isn't an interesting mechanic - it adds a tactical layer to the game and may work well, if properly implemented. I'm not that interested in the whole "games as sports/competitions" aspect anyway and would enjoy a chaotic four team FPS extravaganza. However, for the above mentioned reasons, it's probably easier/safer for developers to stick with the proven one-on-one model, especially considering the (usually more competitive) FPS audience.