1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
|
/*
This file is part of the KDE games library
Copyright (C) 2001 Martin Heni ([email protected])
Copyright (C) 2001 Andreas Beckermann ([email protected])
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License version 2 as published by the Free Software Foundation.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Library General Public License for more details.
You should have received a copy of the GNU Library General Public License
along with this library; see the file COPYING.LIB. If not, write to
the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA.
*/
/*
$Id$
*/
#ifndef __KGAMEPROCESS_H_
#define __KGAMEPROCESS_H_
#include <tqstring.h>
#include <tqobject.h>
#include <tqfile.h>
#include "kgameproperty.h"
#include <krandomsequence.h>
#include <kdemacros.h>
class KPlayer;
class KMessageFilePipe;
/**
* This is the process class used on the computer player
* side to communicate with its counterpart KProcessIO class.
* Using these two classes will give fully transparent communication
* via TQDataStreams.
*/
class KDE_EXPORT KGameProcess: public TQObject
{
Q_OBJECT
TQ_OBJECT
public:
/**
* Creates a KGameProcess class. Done only in the computer
* player. To activate the communication you have to call
* the exec function of this class which will listen
* to the communication and emit signals to notify you of
* any incoming messages.
* Note: This function will only return after you set
* setTerminate(true) in one of the received signals.
* So you can not do any computer calculation after the exec function.
* Instead you react on the signals which are emitted after a
* message is received and perform the calculations there!
* Example:
* \code
* int main(int argc ,char * argv[])
* {
* KGameProcess proc;
* connect(&proc,TQT_SIGNAL(signalCommand(TQDataStream &,int ,int ,int )),
* this,TQT_SLOT(slotCommand(TQDataStream & ,int ,int ,int )));
* connect(&proc,TQT_SIGNAL(signalInit(TQDataStream &,int)),
* this,TQT_SLOT(slotInit(TQDataStream & ,int )));
* connect(&proc,TQT_SIGNAL(signalTurn(TQDataStream &,bool )),
* this,TQT_SLOT(slotTurn(TQDataStream & ,bool )));
* return proc.exec(argc,argv);
* }
* \endcode
*/
KGameProcess();
/**
* Destruct the process
*/
~KGameProcess();
/**
* Enters the event loop of the computer process. Does only
* return on setTerminate(true)!
*/
bool exec(int argc, char *argv[]);
/**
* Should the computer process leave its exec function?
* Activated if you setTerminate(true);
*
* @return true/false
*/
bool terminate() const {return mTerminate;}
/**
* Set this to true if the computer process should end, ie
* leave its exec function.
*
* @param b true for exit the exec function
*/
void setTerminate(bool b) {mTerminate=b;}
/**
* Sends a message to the corresponding KGameIO
* device. Works like the sendSystemMessage but
* for user id's
*
* @param stream the TQDataStream containing the message
* @param msgid the message id for the message
* @param receiver unused
*/
void sendMessage(TQDataStream &stream,int msgid,TQ_UINT32 receiver=0);
/**
* Sends a system message to the corresonding KGameIO device.
* This will normally be either a performed move or a query
* (IdProcessQuery). The query option is a way to communicate
* with the KGameIO at the other side and e.g. retrieve some
* game relevant data from here.
* Exmaple for a query:
* \code
* TQByteArray buffer;
* TQDataStream out(buffer,IO_WriteOnly);
* int msgid=KGameMessage::IdProcessQuery;
* out << (int)1;
* proc.sendSystemMessage(out,msgid,0);
* \endcode
*
* @param stream the TQDataStream containing the message
* @param msgid the message id for the message
* @param receiver unused
*/
void sendSystemMessage(TQDataStream &stream,int msgid,TQ_UINT32 receiver=0);
/**
* Returns a pointer to a KRandomSequence. You can generate
* random numbers via e.g.
* \code
* random()->getLong(100);
* \endcode
*
* @return KRandomSequence pointer
*/
KRandomSequence *random() {return mRandom;}
protected:
/**
* processes the command line argumens to set up the computer player
* Pass the argumens exactely as given by main()
*/
void processArgs(int argc, char *argv[]);
protected slots:
/**
* A message is received via the interprocess connection. The
* appropriate signals are called.
*/
void receivedMessage(const TQByteArray& receiveBuffer);
signals:
/**
* The generic communication signal. You have to connect to this
* signal to generate a valid computer response onto arbitrary messages.
* All signals but IdIOAdded and IdTurn end up here!
* Example:
* \code
* void Computer::slotCommand(int &msgid,TQDataStream &in,TQDataStream &out)
* {
* TQ_INT32 data,move;
* in >> data;
* // compute move ...
* move=data*2;
* out << move;
* }
* \endcode
*
* @param inputStream the incoming data stream
* @param msgid the message id of the message which got transmitted to the computer
* @param receiver the id of the receiver
* @param sender the id of the sender
*/
void signalCommand(TQDataStream &inputStream,int msgid,int receiver,int sender);
/**
* This signal is emmited if the computer player should perform a turn.
* Calculations can be made here and the move can then be send back with
* sendSystemMessage with the message id KGameMessage::IdPlayerInput.
* These must provide a move which complies to your other move syntax as
* e.g. produces by keyboard or mouse input.
* Additonal data which have been written into the stream from the
* ProcessIO's signal signalPrepareTurn can be retrieved from the
* stream here.
* Example:
* \code
* void slotTurn(TQDataStream &in,bool turn)
* {
* int id;
* int recv;
* TQByteArray buffer;
* TQDataStream out(buffer,IO_WriteOnly);
* if (turn)
* {
* // Create a move - the format is yours to decide
* // It arrives exactly as this in the kgame inputMove function!!
* TQ_INT8 x1,y1,pl;
* pl=-1;
* x1=proc.random()->getLong(8);
* y1=proc.random()->getLong(8);
* // Stream it
* out << pl << x1 << y1;
* id=KGameMessage::IdPlayerInput;
* proc.sendSystemMessage(out,id,0);
* }
* }
* \endcode
*
* @param stream The datastream which contains user data
* @param turn True or false whether the turn is activated or deactivated
*
*/
void signalTurn(TQDataStream &stream,bool turn);
/**
* This signal is emmited when the process is initialized, i.e. added
* to a KPlayer. Initial initialisation can be performed here be reacting
* to the KProcessIO signal signalIOAdded and retrieving the data here
* from the stream.
* It works just as the signalTurn() but is only send when the player is
* added to the game, i.e. it needs some initialization data
*
* @param stream The datastream which contains user data
* @param userid The userId of the player. (Careful to rely on it yet)
*/
void signalInit(TQDataStream &stream,int userid);
protected:
bool mTerminate;
KMessageFilePipe *mMessageIO;
private:
TQFile rFile;
TQFile wFile;
KRandomSequence* mRandom;
};
#endif
|
