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

Posts I've Made

In Topic: Assigning special number to each class type at compile time

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)

In Topic: Monsterra

28 January 2013 - 07:25 PM

Ah, this guy is a little short tempered, and tends to blow (he's based
off a volcano). When Erderra is angry, *gulp*, he tends to lose the
plot, and is very, very impatient.


Ok, this makes a lot more sense then. You could perhaps reflect Erderra's volcanic origins in the description. The myth simply states that "a ball of rock appeared" and I naturally assumed that to be granite or something. If, for example, a flame had appeared and out of it the black rock that would become Erderra, then the intended origin would have been a lot clearer.


Also, don't forget that this is in another world, you just don't know why the do and don't need to support life.


Again, I naturally assumed that everything but the Monsterra would be similar (in some form) to our known world.


As I think about it, this is an important point to writing your creation myth:

The reader should probably already know what is being created. That is after all, the way actual creation myths come about. People observe their world and then begin to speculate - trying to deduce how everything came about. If the world you are creating is not our own, then it would probably help to first establish how exactly this world is different, and use your creation myth to specifically explain those differences. That way, when we read the creation myth, everytime that we would naturally have a reaction like: "the order of these events seems all wrong", we can immediately understand "and THAT's why THIS is different in his world".

In Topic: Monsterra

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.

In Topic: A stealth weapon that's never been done before

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.

In Topic: Realitive size in games

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.