Simple Property Reflection and Serialization

    It has been a while since I posted, but it all because of good reasons, I assure you. However, in my busy life I have found some time to whip together a simple C++ solution that demonstrates how to implement your own C++ serialization and property reflection. Along with that I have included a small demo that shows the code working as well as one that shows one of the possibilities of using this system.

    Keep in mind that this is far from complete as it only supports simple classes in the meantime. However, you can always build up from the source code to add support for enums, structs, functions, templates, interfaces, pointers, references, and multiple inheritance. For right now though, I will show off the basics.

    So, where to start when it comes to a C++ reflection system with serialization? Well, we want to definitely start off with the reflection part of the code. Where do we start from there? First, we want to know what an object or variable is. What kind of data it represents. This is commonly known as the type of the variable or object. This is where we will begin. There are a lot of different ways to go about this approach. For instance, I have seen pre-generated GUIDs assigned to templated structs with a single 'Get' method with a static function member that returns this GUID. Works out pretty well, but I went even simpler.

    The approach I took was a single static struct with a type identifier (incremented long) and a name (a simple string from the standard library). This is how the code looks:

static long typeidInstance = 0;

template<typename T>
struct Type : public IType {
 Type(const std::string name) :
  name(name)
 {
  typeId = typeidInstance++;
  TypeGraph::Get().AddType(typeId, this);
 }

 long GetTypeId() const override { return typeId; }
 virtual const std::string GetTypeName() const override { return name; }

 bool IsTypeOf(IType* other) const override {
                return other->GetTypeId() == typeId;
 }
 typedef typename T TYPE;

private:
 long typeId;
 const std::string name;
};

    What is this code doing? Well it is pretty simple. It inherits from a basic IType interface so as to allow a map or graph to contain references to the defined types without knowing the specific implementation. This graph allows getting meta data on types (reflection data) based on the Id or Name of the type. By using this template, a few macros, and static initalization, we can defined types like seen in the "Types.h" header.

    Alright, so we have a way to identify different types without much code overhead. What about information about a type? This would be meta data (reflection). Now, type has the name included (which really should be removed) but we have a class called Meta that will be the base class of everything reflection based.

    Meta has two basic properties: name and typeId. The name is not the type name, it is rather the name given to that Meta information, i.e. class name, object name, property name, etc. The declaration for this base class is as follows:

struct Meta : public core::serial::ISerializable {
 Meta(std::string name, long typeId);

 virtual ~Meta();

 Meta(const Meta& rhs) = delete;
 Meta& operator = (const Meta & rhs) = delete;

 const std::string GetName() const;
 const long GetTypeId() const;

 virtual bool Read(void* obj, std::istream& in, int version) override;
 virtual bool Write(void* obj, std::ostream& out, int version) const;

private:
 std::string name;
 long typeId;
};

    This class inherits from an ISerializable interface to make life easier for this example. It implements that interfaces Read and Write methods. Now, one misleading piece of info for this is that the interface name suggests it serializes itself; but the method takes in a void pointer to the object to serialize. This is probably not the best but works for now.

    In regards to the class details, it does what it does, it has a name and type id and getters for those properties. This is the core of the reflection framework. Another property I would like to add is a 64-bit data property that uses bitwise operators for meta data flags. Such information would be if it is a pointer, a class, a primitive, and / or volatile to name a few.

    Building up from this class we implement a property interface that has two added methods, Get and Set. Both of these methods do as they suggest to the property they reference. This property interface is only made so that pointers can be created for them in another Meta derived class called Class. Class represents meta data about a class. The code for Class is as follows:

struct IProperty;

struct Class : public Meta {
 Class(std::string name, long typeId);
 ~Class();

 void AddProperty(std::string name, IProperty* prop);
   
 std::vector<IProperty*> GetProperties() const;
 IProperty* GetProperty(std::string name) const;

 virtual bool Read(void* obj, std::istream& in, int version) override;
 virtual bool Write(void* obj, std::ostream& out, int version) const override;

private:
 std::map<std::string, IProperty*> Properties;
};

    Create, now we are able to get information about a class. We can also get any instance of a class and serialize it. How so? Well we can save the property information using these Read and Write methods using the Property template to write out the actual properties. If you want to see the implementation details about that, take a look at the Meta.cpp, Property.h, and Class.cpp source files. There you find out how serialization takes place using meta information, streams, and property pointers.

    This lays the ground work of the reflection and serialization example and concludes part one. I hope you enjoy looking at the source code found on github as much as I enjoyed writing it. If you have questions in regards to C++, implementation, or ideas, please feel free to comment.

Some Experiments and OpenSource code

Recently I have taken an interest in network communication more so than usual. Particular interests in secure network communications. With that being said, I have recently started on a small project dubbed "f42r". The given name is so because I had no idea what I was going to make when I started, or where it will be going - if it goes anywhere.

Currently, f42r is a cryptochat service. It is a single program that can be configured to run as a client or a server when it is started.

The server simple communicates all messages from one client to all other clients connected to it. The server is also configured on startup with a dh file, key file, and a public key file for ssl based communications with each client.

The client simply connects to and verifies the server. The server is verified as per RFC2818 despite the fact it does not use HTTP or HTTPS. From there, messages can be sent from the client application (running as a simple console application) to the server. These messages are sent to all clients connected to the server.

There is no data storage for these servers, all configuration is defined at run time and clients get to define their own name for each client instance they start up.

There is also some attempt at cross platfrom compatibility; however, the program has only been compiled in Visual Studio 2013 and its relative compiler and run on a 64-bit Windows OS.

Another small feature, done as experiments in OS APIs, is the InfoHarvester class. This guy, upon load, gathers miscellaneous information about the computer that the client is running on, then sends this data to the server being connected to. I was planning on using this feature to create hardware based identities.

Currently, the project is on github, found here: https://github.com/hollsteinm/f42r

As a warning, the project uses Boost and OpenSSL as mentioned in the Readme.

Version 0.0.5.4 Of [Working Title] AdventureGameQuest Released!

Just a quick announcement for all of the awesome people out there, I have released version 0.0.5.4 of my text adventure game! It comes with a few gameplay enhancements as well as some additional security features.

The gameplay enhancements are as follows:

• "whereami" command that tells you where you are, where you can go, and if where you are at is an exit.
• First person narrative. Originally, we had some bad grammar, and that is fixed now. Everything *should* be in the first person narrative.

Security Changes:

• You may now reset your password from the Login page.
• Password requirements are less strict (due to popular demand, it is *just* a game after all)

I look forward to hearing about some of your adventures in the game and comments about what can be done to improve it! Link here to play: http://adventuregamequest.azurewebsites.net/

Program Like A Pro

Today I have decided to program like a pro and implement a "One function to do everything" class that acts as an entry point into any program I will ever make again. I call it, the 'Jerk API'. How does this work? Well, let me tell you.

First and foremost, let us look at the greatest operator overload to exist:

operator()

Why? Why is this awesome? I will continue after we look at the greatest return type ever created:

void*

"Whoa!" You may be saying. I agree, it is "Whoa" worthy. The best return type is now combined with the ultimate operator to exist:

void* operator()

Do you see where this is goin? If so, you should keep on reading. Because the ultimate function that should only ever be implemented in every API, SDK, software package, library, so on and so forth is as follows:

void* operator(...);

Yes, the ultimate function. It is the one ring of programming, the Filet Mignon, the Mt. Everest, just simply the best!

For those of you who are not familiar with this sort of epic programming, let us look more closed at the void* return type. Firstly, what is void? It means nothing, or no type. How awesome is that! We don't need to worry about what we return because it doesn't care. Making it a pointer allows us to actually return a pointer to something that somebody else has to worry about casting to the right object. We can return whatever we want, when we want, and however we choose so.

Now let us take a look at the best parameter argument in existence as well, the vararg (...). This allows us to accept any number of arguments without telling the mewling babe of a programmer who uses our library/API/etc. the types of the arguments or even a description. A true interface that only the pros can handle.

With that being said, let me give a great example of all the fun we can have! I even included unions for this example (probably just as awesome of a argument as the varargs). (I would click it to see all of the glory)


Well, isn't that just great? I concur. Anyways, if you want to be a pro programmer, always remember, your classes need only one method.

void* operator()(...);

ENJOY!

Component Based Design

Today I am going to talk about using Components for your game objects. 

Wow, that one came out of nowhere, wasn't I just talking about my new alpha version game and the design contest I have going for it at adventuregamequest.azurewebsites.net/#/contest? Yes, but let us take a break from Text-RPG games and focus on some exciting 3D Games.

As I have mentioned before, I am currently working on two projects. Both of these projects are a 3rd person adventure/action game of sorts. From various phases of the design process, before implementing any code, I have come to the conclusion that components are great. In fact, I would venture to say its the next best thing to inheritance.

To keep this in scope, I am not talking about the Component-Entity design pattern per say, rather, the component systems implemented in both Unreal Engine 4 and Unity 4. Not coincidentally, these are two of the largest game engines I can think of that are still of relevance and readily available to the public. Both of these engines incorporate a component model, where you have a base object within the world that has objects attached to them.

In Unity these are the MonoBehaviour scripts. They can be attached to any GameObject within the engine and readily used. In Unreal Engine 4, these are ActorComponents that can be attached to Actors.

Why is this such a good system?

I have several answers to that question. These answers are as follows: modularity, prototyping, less limitations.

The first point is the best: modular components make life awesome. I would venture to say that, for games, components are the next best thing after object oriented programming languages/design. By allowing a designer/programmer to take an unspecified object with no real value other than existing as an entity - GameObject in Unity and Actor in Unreal - on can put together pieces to design a complex system or entity within the game. The best part is that traits of the entity can be replicated and attached to other entities that are not necessarily an instance of that entity. For example, one of the problems I had with a game I was making in UE4 was as follows:

An Actor has several different methods to attack. They can have a weapon, or use an unarmed attack. This means the Actor (we will refer it to creature from now on) will need to have some way to cause damage without a weapon. Simple enough, sounds like a simple property named damage. And, again, simply, the weapon now needs a property called damage. Nice, simple, easy to the point, use some logic to see if the creature has a weapon, if not, use it's damage.
But wait, now we want ranged weapons. Well, a ranged weapon is a weapon, so we will just inherit from weapon, also inheriting the damage property. But a ranged weapon doesn't do damage, it shoots things that cause damage. Well, we could give that projectile a damage property too, sounds good, and ignore the ranged weapon's damage property when the projectile hit an enemy. Another route would be to have a pointer to the firing weapon, and if the projectile hits anything, use the ranged weapons damage to cause damage.
Nice, that is all wired up now. So for each actor that has this damage property, add a callback event to apply damage on the other Actor hit by the creature, the creature's weapon, or the creature's ranged weapon's projectile.
Awesome done.
But wait, now we want spells, okay, just copy all logic from the other four classes...

 Clearly, you can see where this is going. And it is a long an miserable road to travel. This is what your (prototyped) files would begin to look like:

class Creature : AActor
{
public:
float Damage;
Weapon* MyWeapon;
float GetDamage()
{
if(MyWeapon == NULL)
return this->Damage;
else
return MyWeapon->Damage;
}
}
class Weapon : AActor
{
public:
float Damage;
}
//Notice the circular dependencies in this awful design not using components
class RangedWeapon : Weapon
{
public:
Projectile* WhatIShoot;
}
class Projectile : Actor //You could even have projectile inherit from weapon if you would like... but is that really any better?
{
public:
float GetDamage()
{
return WhatShotMe->Damage;
}
RangedWeapon* WhatShotMe;
}

Sure, you could argue, "Well, why not have a DamageActor that has all these stats?" As an exercise to the reader, I will let you argue that point.

So here is the alternative:

Make an ActorComponent called DamageComponent, add a damage property (and any other awesome damage like properties like critical hit, critical chance, critical multiplier, etc.) and have a get method that calculates damage.
Slap that component onto any actor you want and implement whatever event that causes damage (overlap, hit, fall, etc.)
Done, Need spells? Awesome, create a spell actor and slap that puppy on there.

Seems pretty obvious why the whole modularity thing comes in handy now, doesn't it? This also helps create a nice, distinct, seperation of concerns when it comes to your software. Rendering components render, collision components collide, gameplay components do game stuff, and so on and so forth.

Next is how easy this modularity makes prototyping. Let us go back to the first example of making attack power/damage where we created a file for each entity that could possibly cause damage. Better, yet, let us take that a step further and say we used some good OOP and have a DamageActor inherited from Actor that all of these classes inherit from. Now, we just add all the extra properties we need for this. Seems like a good solution.

Well, the Game Designer came in and changed something. The player can now transform into any one of the enemy AI you see before you. You already created all of these awesome combat mechanics using inheritance, and you created the player with a controller, as well as some stats of his own (since this is a stealth game all of a sudden, the player is not a DamageActor because, unlike every other protagonist in the world of games, he does not kill people). So, do we turn this docile, sneaky player into a Damage Actor? Do we just create and inherited class for each possible AI in the game into a PlayerXXXActor and have a bunch of unneeded data implemented?

No. That is bad.

This is a tough one, but my approach would be to find a reference to the base class and copy over the components into the component array, exclude the ones that are type or super type of DamageComponent. One line of code, done. Call it a day, and no crunch time.

Who loves components, modularity, and prototyping? We do.

Finally, this brings to the point of less limitations. In the world of programming, refactoring is a way of life. It can be fun, it can be tedious, but it is also the result of lots of prototyping. With components we can swap in and out common and uncommon responsibilities between common and uncommon entities within the game. Let us, for instance look at a Unity example.

You have a multi player game and there is a single player mode. Do you want to write a script called AIScript where you have if statements for every single action? For instance:

public class AIScript : MonoBehaviour
{
private bool multiplayer;
private ClientRunner client;
OnUpdate()
{
if(multiplayer && client != null)
{
client.Send("Position", new object[]{position.x, position.y, position.z});
}
else
{
//Do nothing, so we have a stupid if/else statement here (or we could hide it with out putting the else, but does that really make you feel good                                 inside?)
}
if(multiplayer && client != null)
{
//Receive a whole slew of data to update
}
else
{
//Um.... do nothing, perhaps go out into the local game world and get that //same data
}
//A plague of if/else blocks
if(multiplayer && client != null)
{
}
else
{
}
if(multiplayer && client != null)
{
}
else
{
}
if(multiplayer && client != null)
{
}
else
{
}
if(multiplayer && client != null)
{
}
else
{
}
}
}

Looks okay. I mean, if the AI is on the network it replicates, if not it uses the game world. Well, that is a lot of conditional branching in an update loop - kind of sucks for performance. And now the AI is responsible for its own Client/Server or Local Gameplay management. Might as well as throw ALL information that requires that knowledge into those blocks of data, or do a lot more copying and pasting.

I have your solution from this awful life: Have a CommonAI, NetworkAI, and LocalAI, have an AI manager detect gamemode and when creating AI, attach the appropiate script. No need to go in and out of if/else blocks to change little things, you can still use inheritance by having common AI routines go in Common AI and have the Network* or Local* inherit from that. Not bad, components win the day again.

In the end I would like to say that I love the component systems used in modern game engines. I know this may seem obvious, but some schools teach the importance of OOP in schools to the point where one can focus on only using OOP in game engines and gameplay classes. When there is a better solution out there, it should be taught, and I hope this helped you to see the light or help solve a difficult case of multi-inheritance messes.

 

Game Development Competition Announced!

Hello Blogger/enjoy-game-programming/Game Development community,

I am posting this because I plan on holding a competition for the alpha version of my online text RPG game found at http://adventuregamequest.azurewebsites.net/#/. The competition is simple, create a short story based quest line that falls in line with the quest flow of the game. Before I continue, there will be three winners selected from the competition. The winning quests will be included in the game as a playable quest line and credit for assissting in the devleopment of the game on the website.
There are several categories that will be judged for this competition. These categories are flow, balance, and originality. Flow is judged on how well the story of the quest fits together with the actual quest objectives as well as how the quests go together when leading from one to the other. Balance is the difficulty progression of the quests as the player completes them. Finally, originality is the cumalitive story line of the quests. The latter includes, characters, places, monsters, and all of the other exciting elements of an epic.

Now that we have those details out of the way, there are several rules which I will outline below.

1) Submissions must be made to alpha-adventuregamequest@outlook.com with the subject line of "Alpha Game Quest Contest"

2) There must be a grand total of 50 Quests.

3) Quests have the following structure:

a) Quest Giver
i) Name of the Quest Giver
ii) A description of the quest giver
iii) The location a quest giver is in
iv) The quests that must be completed to unlock this quest giver
v) The quest that quest giver gives

b) Quest
i) The name of the quest
ii) A description of the quest (this is mostly the story part)
iii) Quest brief - Follows the syntax of verb, number, what.
iv) Quest Type
aa) Collect
bb) Slay
cc) Travel To
v) Quests that may be triggered after this one is completed (optional)
vi) Rewards: Score, Experience, Gold

4) Finally, a high level overview of your collection of quests. This includes the full story, where the quests fit in, and anything else you find useful. (Essentially, a short story)

5) Full list of the linear progression (or not so linear progression ;) ) of the quests, each one numbered

6) The deadline is February 27, 2015 and the finalists (top 10) will be posted on the website [ http://adventuregamequest.azurewebsites.net/#/ ] by March 6, 2015. The winners will be announced April 10, 2015.

With all the nitty gritty out of the way, I do have some notes to make about the submissions. These notes are listed as follows:

1) *Slight* Deviation of quest structure are encouraged. By slight, I mean the types of quests, as well as rewards. Be creative - not crazy. Remember, it is a text based RPG.

2) Questions are encouraged in email at the submission address with the subject line "Alpha Game Quest Contest Inquiry", or as a comment below

3) Spelling and grammar are encouraged to be correct

4) English is my primary language, so I encourage submissions in English, but will attempt to go through some online translator if I must. I read German as a poor secondary language.

I look forward to your submissions and am very excited for the opportunity to do this for the game development community. If you want to get a feel for the game before getting started, join now for free and play for a bit at the games website. [ http://adventuregamequest.azurewebsites.net/#/ ]

Greatest Adventure Game Update (so far)

Today is an exciting day! I have just release version 0.0.3.1 for my text adventure game at adventuregamequest.azurewebsites.net, feel free to try out the new version at the site! The game is chocked full on new features that I am excited to share. These features are as follows:

• Enhanced Security: Users now need to confirm email address when signing up for the game. This will pave the way for password recovery and support.
• Quests: The quest system for the game has been added! This is a huge update as it will pave the way for the Beta version and a fully implemented story!!!!!!!!!! Can you not see the impact of this feature!?!?!? If not, or even if you do, go and check it out.
• More Achievements: With more things to do in the game, there come more achievements, meaning more opportunities to gain bragging rights.

So go ahead, join today, or log back in, you won't regret it! Here is the path for the alpha testing server - all are invited:

adventuregamequest.azurewebsites.net