KGameProperty< type > Class Template Reference

A class for network transparent games. More...

#include <kgameproperty.h>

Inheritance diagram for KGameProperty< type >:

[legend]Collaboration diagram for KGameProperty< type >:

[legend]List of all members.

Public Member Functions
	KGameProperty (int id, KGamePropertyHandler *owner)
	Constructs a KGameProperty object.
	KGameProperty ()
	This constructor does nothing.
virtual	~KGameProperty ()
void	setValue (type v)
	Set the value depending on the current policy (see setConsistent).
bool	send (type v)
	This function sends a new value over network.
bool	setLocal (type v)
	This function sets the value of the property directly, i.e.
void	changeValue (type v)
	This function does both, change the local value and change the network value.
virtual void	save (QDataStream &stream)
	Saves the object to a stream.
const type &	value () const
virtual void	load (QDataStream &s)
	Reads from a stream and assigns the read value to this object.
const type &	operator= (const type &t)
	This calls setValue to change the value of the property.
const type &	operator= (const KGameProperty &property)
	This copies the data of property to the KGameProperty object.
	operator type () const
	Yeah, you can do it!
virtual const type_info *	typeinfo ()

---

Detailed Description

template<class type>
class KGameProperty< type >

A class for network transparent games.

Note: The entire API documentation is obsolete!

The class KGameProperty can store any form of data and will transmit it via network whenver you call send. This makes network transparent games very easy. You first have to register the data to a KGamePropertyHandler using KGamePropertyBase::registerData (which is called by the constructor). For the KGamePropertyHandler you can use KGame::dataHandler or KPlayer::dataHandler but you can also create your own data handler.

There are several concepts you can follow when writing network games. These concepts differ completely from the way how data is transferred so you should decide which one to use. You can also mix these concepts for a single property but we do not recommend this. The concepts:

• Always Consistent (clean)
• Not Always Consistent (dirty)
• A Mixture (very dirty)

I repeat: we do not recommend the third option ("a mixture"). Unless you have a good reason for this you will probably introduce some hard to find (and to fix) bugs.

consistent (clean):

This "policy" is default. Whenever you create a KGameProperty it is always consistent. This means that consistency is the most important thing for the property. This is achieved by using send to change the value of the property. send needs a running KMessageServer and therefore MUST be plugged into a KGamePropertyHandler using either registerData or the constructor. The parent of the dataHandler must be able to send messages (see above: the message server must be running). If you use send to change the value of a property you won't see the effect immediately: The new value is first transferred to the message server which queues the message. As soon as all messages in the message server which are before the changed property have been transferred the message server delivers the new value of the KGameProperty to all clients. A QTimer::singleShot is used to queue the messages inside the KMessageServer.

This means that if you do the following:

 KGamePropertyInt myProperty(id, dataHandler());
 myProperty.initData(0);
 myProperty = 10;
 int value = myProperty.value();

then "value" will be "0". initData is used to initialize the property (e.g. when the KMessageServer is not yet running or can not yet be reached). This is because "myProperty = 10" or "myProperty.send(10)" send a message to the KMessageServer which uses QTimer::singleShot to queue the message. The game first has to go back into the event loop where the message is received. The KGamePropertyHandler receives the new value sets the property. So if you need the new value you need to store it in a different variable (see setLocal which creates one for you until the message is received). The KGamePropertyHandler emits a signal (unless you called setEmitSignal with false) when the new value is received: KGamePropertyHandler::signalPropertyChanged. You can use this to react to a changed property.

This may look quite confusing but it has a big advantage: all KGameProperty objects are ensured to have the same value on all clients in the game at every time. This way you will save you a lot of trouble as debugging can be very difficult if the value of a property changes immediately on client A but only after one or two additianal messages (function calls, status changes, ...) on client B.

The only disadvantage of this (clean) concept is that you cannot use a changed variable immediately but have to wait for the KMessageServer to change it. You probably want to use KGamePropertyHandler::signalPropertyChanged for this.

Always Consistent (dirty):

There are a lot of people who don't want to use the (sometimes quite complex) "clean" way. You can use setAlwaysConsistent to change the default behaviour of the KGameProperty. If a property is not always consistent it will use changeValue to send the property. changeValue also uses send to send the new value over network but it also uses setLocal to create a local copy of the property. This copy is created dynamically and is deleted again as soon as the next message from the network is received. To use the example above again:

 KGamePropertyInt myProperty(id, dataHandler());
 myProperty.setAlwaysConsistent(false);
 myProperty.initData(0);
 myProperty = 10;
 int value = myProperty.value();

Now this example will "work" so value now is 10. Additionally the KMessageServer receives a message from the local client (just as explained above in "Always Consistent"). As soon as the message returns to the local client again the local value is deleted, as the "network value" has the same value as the local one. So you won't lose the ability to use the always consistent "clean" value of the property if you use the "dirty" way. Just use networkValue to access the value which is consistent among all clients.

The advantage of this concept is clear: you can use a KGameProperty as every other variable as the changes value takes immediate effect. Additionally you can be sure that the value is transferred to all clients. You will usually not experience serious bugs just because you use the "dirty" way. Several events have to happen at once to get these "strange errors" which result in inconsistent properties (like "game running" on client A but "game ended/paused" on client B). But note that there is a very good reason for the existence of these different concepts of KGameProperty. I have myself experienced such a "strange error" and it took me several days to find the reason until I could fix it. So I personally recommend the "clean" way. On the other hand if you want to port a non-network game to a network game you will probably start with "dirty" properties as it is you will not have to change that much code...

Mixture (very dirty):

You can also mix the concepts above. Note that we really don't recommend this. With a mixture I mean something like this:

 KGamePropertyInt myProperty(id, dataHandler());
 myProperty.setAlwaysConsistent(false);
 myProperty.initData(0);
 myProperty = 10;
 myProperty.setAlwaysConsistent(true);
 myProperty = 20;

(totally senseless example, btw) I.e. I am speaking of mixing both concepts for a single property. Things like

 KGamePropertyInt myProperty1(id1, dataHandler());
 KGamePropertyInt myProperty2(id2, dataHandler());
 myProperty1.initData(0);
 myProperty2.initData(0);
 myProperty1.setAlwaysConsistent(false);
 myProperty2.setAlwaysConsistent(true);
 myProperty1 = 10;
 myProperty2 = 20;

are ok. But mixing the concepts for a single property will make it nearly impossible to you to debug your game.

So the right thing to do(tm) is to decide in the constructor whether you want a "clean" or "dirty" property.

Even if you have decided for one of the concepts you still can manually follow another concept than the "policy" of your property. So if you use an always consistent KGameProperty you still can manually call changeValue as if it was not always consistent. Note that although this is also kind of a "mixture" as described above this is very useful sometimes. In contrast to the "mixture" above you don't have the problem that you don't exactly know which concept you are currently following because you used the function of the other concept only once.

classes:

If you want to use a custum class with KGameProperty you have to implement the operators << and >> for QDataStream:

 class Card
 {
 public:
 int type;
 int suite;
 };
 QDataStream& operator<<(QDataStream& stream, Card& card)
 {
 Q_INT16 type = card.type;
 Q_INT16 suite = card.suite;
 s << type;
 s << suite;
 return s;
 }
 QDataStream& operator>>(QDataStream& stream, Card& card)
 {
 Q_INT16 type;
 Q_INT16 suite;
 s >> type;
 s >> suite;
 card.type = (int)type;
 card.suite = (int)suite;
 return s;
 }

 class Player : KPlayer
 {
 [...]
 KGameProperty<Card> mCards;
 };

Note: unlike most QT classes KGameProperty objects are *not* deleted automatically! So if you create an object using e.g. KGameProperty<int>* data = new KGameProperty(id, dataHandler()) you have to put a delete data into your destructor!

Author:

Andreas Beckermann <b_mann@gmx.de>

Definition at line 581 of file kgameproperty.h.

---

Constructor & Destructor Documentation

template<class type> KGameProperty< type >::KGameProperty (  int  id, KGamePropertyHandler *  owner )  [inline]

Constructs a KGameProperty object. A KGameProperty object will transmit any changes to the KMessageServer and then to all clients in the game (including the one that has sent the new value) Parameters: id  The id of this property. MUST be UNIQUE! Used to send and receive changes in the property of the playere automatically via network. owner  The parent of the object. Must be a KGame which manages the changes made to this object, i.e. which will send the new data. Note that in contrast to most KDE/QT classes KGameProperty objects are not deleted automatically! Definition at line 597 of file kgameproperty.h.

template<class type> KGameProperty< type >::KGameProperty (   )  [inline]

This constructor does nothing. You have to call KGamePropertyBase::registerData yourself before using the KGameProperty object. Definition at line 604 of file kgameproperty.h.

template<class type> virtual KGameProperty< type >::~KGameProperty (   )  [inline, virtual]

Definition at line 606 of file kgameproperty.h.

---

Member Function Documentation

template<class type> void KGameProperty< type >::changeValue (  type  v  )  [inline]

This function does both, change the local value and change the network value. The value is sent over network first, then changed locally. This function is a convenience function and just calls send followed by setLocal Note that emitSignal is also called twice: once after setLocal and once when the value from send is received See also: send setLocal setValue value Definition at line 744 of file kgameproperty.h. References KGameProperty< type >::send(), and KGameProperty< type >::setLocal(). Referenced by KGame::setMaxPlayers(), KGame::setMinPlayers(), and KGameProperty< type >::setValue(). Here is the call graph for this function:

template<class type> virtual void KGameProperty< type >::load (  QDataStream &  s  )  [inline, virtual]

Reads from a stream and assigns the read value to this object. This function is called automatically when a new value is received over network (i.e. it has been sent using send on this or any other client) or when a game is loaded (and maybe on some other events). Also calls emitSignal if isEmittingSignal is TRUE. Parameters: s  The stream to read from Implements KGamePropertyBase. Definition at line 780 of file kgameproperty.h. References KGamePropertyBase::emitSignal(), KGamePropertyBase::isEmittingSignal(), and KGamePropertyBase::setDirty(). Here is the call graph for this function:

template<class type> KGameProperty< type >::operator type (   )  const [inline]

Yeah, you can do it! int a = myGamePropertyInt; If you don't see it: you don't have to use integerData.value() Definition at line 831 of file kgameproperty.h. References KGameProperty< type >::value(). Here is the call graph for this function:

template<class type> const type& KGameProperty< type >::operator= (  const KGameProperty< type > &  property  )  [inline]

This copies the data of property to the KGameProperty object. Equivalent to setValue(property.value()); Definition at line 818 of file kgameproperty.h. References KGameProperty< type >::setValue(), and KGameProperty< type >::value(). Here is the call graph for this function:

template<class type> const type& KGameProperty< type >::operator= (  const type &  t  )  [inline]

This calls setValue to change the value of the property. Note that depending on the policy (see setAlwaysConsistent) the returned value might be different from the assigned value!! So if you use setPolicy(PolicyClean): int a, b = 10; myProperty = b; a = myProperty.value(); Here a and b would differ! The value is actually set as soon as it is received from the KMessageServer which forwards it to ALL clients in the network. If you use a clean policy (see setPolicy) then the returned value is the assigned value Definition at line 807 of file kgameproperty.h. References KGameProperty< type >::setValue(), and KGameProperty< type >::value(). Here is the call graph for this function:

template<class type> virtual void KGameProperty< type >::save (  QDataStream &  stream  )  [inline, virtual]

Saves the object to a stream. Parameters: stream  The stream to save to Implements KGamePropertyBase. Definition at line 754 of file kgameproperty.h.

template<class type> bool KGameProperty< type >::send (  type  v  )  [inline]

This function sends a new value over network. Note that the value DOES NOT change when you call this function. This function saves the value into a QDataStream and calls sendProperty where it gets forwarded to the owner and finally the value is sent over network. The KMessageServer now sends the value to ALL clients - even the one who called this function. As soon as the value from the message server is received load is called and _then_ the value of the KGameProperty has been set. This ensures that a KGameProperty has _always_ the same value on _every_ client in the network. Note that this means you can NOT do something like myProperty.send(1); doSomething(myProperty); as myProperty has not yet been set when doSomething is being called. You are informed about a value change by a singal from the parent of the property which can be deactivated by setEmittingSignal because of performance (you probably don't have to deactivate it - except you want to write a real-time game like Command&Conquer with a lot of acitvity). See emitSignal Note that if there is no KMessageServer accessible - before the property has been registered to the KGamePropertyHandler (as it is the case e.g. before a KPlayer has been plugged into the KGame object) the property is *not* sent but set *locally* (see setLocal)! Parameters: v  The new value of the property Returns: whether the property could be sent successfully See also: setValue setLocal changeValue value Definition at line 670 of file kgameproperty.h. References KGamePropertyBase::isLocked(), KGamePropertyBase::isOptimized(), KGamePropertyBase::sendProperty(), and KGameProperty< type >::setLocal(). Referenced by KGameProperty< type >::changeValue(), and KGameProperty< type >::setValue(). Here is the call graph for this function:

template<class type> bool KGameProperty< type >::setLocal (  type  v  )  [inline]

This function sets the value of the property directly, i.e. it doesn't send it to the network. Int contrast to See also: you change _only_ the local value when using this function. You do _not_ change the value of any other client. You probably don't want to use this if you are using a dedicated server (which is the only "client" which is allowed to change a value) but rather want to use send(). But if you use your clients as servers (i.e. all clients receive a players turn and then calculate the reaction of the game theirselves) then you probably want to use setLocal as you can do things like myProperty.setLocal(1); doSomething(myProperty); on every client. If you want to set the value locally AND send it over network you want to call changeValue! You can also use setPolicy to set the default policy to PolicyLocal. See also: setValue send changeValue value Definition at line 715 of file kgameproperty.h. References KGamePropertyBase::emitSignal(), KGamePropertyBase::isEmittingSignal(), KGamePropertyBase::isLocked(), KGamePropertyBase::isOptimized(), and KGamePropertyBase::setDirty(). Referenced by KGameProperty< type >::changeValue(), KGameProperty< type >::send(), and KGameProperty< type >::setValue(). Here is the call graph for this function:

template<class type> void KGameProperty< type >::setValue (  type  v  )  [inline]

Set the value depending on the current policy (see setConsistent). By default KGameProperty just uses send to set the value of a property. This behaviour can be changed by using setConsistent. Parameters: v  The new value of the property Definition at line 615 of file kgameproperty.h. References KGameProperty< type >::changeValue(), KGamePropertyBase::id(), KGamePropertyBase::policy(), KGamePropertyBase::PolicyClean, KGamePropertyBase::PolicyDirty, KGamePropertyBase::PolicyLocal, KGameProperty< type >::send(), and KGameProperty< type >::setLocal(). Referenced by KGameProperty< type >::operator=(). Here is the call graph for this function:

template<class type> virtual const type_info* KGameProperty< type >::typeinfo (   )  [inline, virtual]

Returns: a type_info of the data this property contains. This is used e.g. by KGameDebugDialog Reimplemented from KGamePropertyBase. Definition at line 833 of file kgameproperty.h.

template<class type> const type& KGameProperty< type >::value (   )  const [inline]

Returns: The local value (see setLocal) if it is existing, otherwise the network value which is always consistent on every client. Definition at line 764 of file kgameproperty.h. Referenced by KPlayer::emitSignal(), KGame::gameStatus(), KGame::isRunning(), KGame::maxPlayers(), KGame::minPlayers(), KGameProperty< type >::operator type(), and KGameProperty< type >::operator=().

---

The documentation for this class was generated from the following file:

• kgameproperty.h

---