Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Combining modified flag with a class member modification
117 views
Skip to first unread message
JiiPee
Jun 8, 2017, 12:27:35 AM6/8/17
to
Say I have this kind of class structure:
class Game
{
...
private:
Player m_player;
bool m_pointsChanged{false};
};
class Player
{
...
private:
int points;
};
When some function in the Game class modifies players points the
m_pointsChanged needs to change to true.
What would be the best way to do this? I have this kind of situation
many times. I would like it so it is not possible to modify points alone
without m_pointsChanged being also updated. So for example:
class Player
{
void setPoint(int pt) { points = pt; }
private:
int points;
};
is not acceptable because then we could (accidentally) change points
from Game class doing:
m_player.setPoint(24);
and m_pointsChanged would not be updated (thus having a wrong value).
I was thinking these things:
1) should Player be inside the Game class if the points are so closely
linked with the modified flag?
2) This is one solution:
class Player;
class Game
{
private:
static void setPlayerPoints(Game& game, Player& player);
Player m_player;
bool m_pointsChanged{false};
};
class Player
{
private:
friend static void Game::setPlayerPoints(Game& game, Player& player);
int points;
};
and then player's points can only be set by using this setPlayerPoints
function (Player class does not have any setters for points). But the
problem is then that Player does not have setters.... is this a good idea?
3) I could create a setter in Player class like this:
class Player
{
public:
void setPoints(WordScrambleGame& game, int newPoints);
...
};
and then make Player a friend of Game. but the problem with this is that
then Player gets access to many private members of Game class it does
not need to get access. I wish I could limit the friend access to only
one variable... but its not in C++ i guess?
Any ideas? I have this situation in other projects as well... always
thinking about this ;).
class Game
{
...
private:
Player m_player;
bool m_pointsChanged{false};
};
class Player
{
...
private:
int points;
};
When some function in the Game class modifies players points the
m_pointsChanged needs to change to true.
What would be the best way to do this? I have this kind of situation
many times. I would like it so it is not possible to modify points alone
without m_pointsChanged being also updated. So for example:
class Player
{
void setPoint(int pt) { points = pt; }
private:
int points;
};
is not acceptable because then we could (accidentally) change points
from Game class doing:
m_player.setPoint(24);
and m_pointsChanged would not be updated (thus having a wrong value).
I was thinking these things:
1) should Player be inside the Game class if the points are so closely
linked with the modified flag?
2) This is one solution:
class Player;
class Game
{
private:
static void setPlayerPoints(Game& game, Player& player);
Player m_player;
bool m_pointsChanged{false};
};
class Player
{
private:
friend static void Game::setPlayerPoints(Game& game, Player& player);
int points;
};
and then player's points can only be set by using this setPlayerPoints
function (Player class does not have any setters for points). But the
problem is then that Player does not have setters.... is this a good idea?
3) I could create a setter in Player class like this:
class Player
{
public:
void setPoints(WordScrambleGame& game, int newPoints);
...
};
and then make Player a friend of Game. but the problem with this is that
then Player gets access to many private members of Game class it does
not need to get access. I wish I could limit the friend access to only
one variable... but its not in C++ i guess?
Any ideas? I have this situation in other projects as well... always
thinking about this ;).
Jerry Stuckle
Jun 8, 2017, 8:55:22 AM6/8/17
to
{
public:
void setPoints(int pt) {
if (points != pt) [
points = pt;
points_modified = true;
}
}
private:
int points;
bool points_modified;
};
And ensure the only change to points in the Player class is through the
setPoints method.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================
JiiPee
Jun 8, 2017, 11:25:11 AM6/8/17
to
On 08/06/2017 13:55, Jerry Stuckle wrote:
> class Player
> {
> public:
> void setPoints(int pt) {
> if (points != pt) [
> points = pt;
> points_modified = true;
> }
> }
>
> private:
> int points;
> bool points_modified;
> };
>
> And ensure the only change to points in the Player class is through the
> setPoints method.
True this works (and might be the solution... did not even think about
> class Player
> {
> public:
> void setPoints(int pt) {
> if (points != pt) [
> points = pt;
> points_modified = true;
> }
> }
>
> private:
> int points;
> bool points_modified;
> };
>
> And ensure the only change to points in the Player class is through the
> setPoints method.
this), but a small problem here is that now I need to loop all the
players always to know if one of them is changed. In my version the Game
class keeps record if one is changed so no need to loop the players.
Although in real situation there will not be more than 100 players. so
doing the loop always if very fast. You dont see this a problem that I
always have to loop the 100 players to know if one is changed? If the
Game class keeps the record of this then would not need to loop.
JiiPee
Jun 8, 2017, 11:27:28 AM6/8/17
to
On 08/06/2017 13:55, Jerry Stuckle wrote:
>
>
> class Player
> {
> public:
> void setPoints(int pt) {
> if (points != pt) [
> points = pt;
> points_modified = true;
> }
> }
>
> private:
> int points;
> bool points_modified;
> };
>
> And ensure the only change to points in the Player class is through the
> setPoints method.
The small downside is that if I have 100 players I always have to loop
> {
> public:
> void setPoints(int pt) {
> if (points != pt) [
> points = pt;
> points_modified = true;
> }
> }
>
> private:
> int points;
> bool points_modified;
> };
>
> And ensure the only change to points in the Player class is through the
> setPoints method.
all the players to know if one is changed. Also when I want to set them
"unchanged" again I have to loop 100 players to do that. so 2 x 100
operations. But is this the best way still to do this?
Scott Lurndal
Jun 8, 2017, 11:30:22 AM6/8/17
to
call a std::function and that function would handle whatever you
need to do when the points value changes.
Alf P. Steinbach
Jun 8, 2017, 12:30:39 PM6/8/17
to
On 08-Jun-17 6:27 AM, JiiPee wrote:
> Say I have this kind of class structure:
>
> class Game
> {
>
> ...
>
> private:
> Player m_player;
Are you sure there is only a single player?
> Say I have this kind of class structure:
>
> class Game
> {
>
> ...
>
> private:
> Player m_player;
That's a somewhat rhetorical question because in the later discussion
you talk about looping over 100 players. So let's assume you meant
vector<Player> m_players;
> bool m_pointsChanged{false};
> };
>
> class Player
> {
>
> ...
>
> private:
> int points;
> };
>
> When some function in the Game class modifies players points the
> m_pointsChanged needs to change to true.
That's simple: let each player know which Game it belongs to, e.g by
having a pointer to that Game instance.
> What would be the best way to do this? I have this kind of situation
> many times.
And I think that by properly defining what you mean by “best”, you will
possibly have answered your own question already. ;-)
[snip]
Cheers & hth.,
- Alf
Öö Tiib
Jun 8, 2017, 12:32:34 PM6/8/17
to
That means Game has one and only one Player component.
From above sentence "if I have 100 players" we can however conclude
that now your Game can have big amount of Players. That is entirely
different situation. The "best" for these two situations is different.
Have reference to Game in Player. Then when Player's points
will change then it can inform Game about it that sets its
points_modified.
JiiPee
Jun 8, 2017, 12:55:01 PM6/8/17
to
On 08/06/2017 16:30, Scott Lurndal wrote:
>> The small downside is that if I have 100 players I always have to loop
>> all the players to know if one is changed. Also when I want to set them
>> "unchanged" again I have to loop 100 players to do that. so 2 x 100
>> operations. But is this the best way still to do this?
> I'd probably put a callback into the setPoints method that would
> call a std::function and that function would handle whatever you
> need to do when the points value changes.
ok, one possiblitiy.. have to think about this
>> The small downside is that if I have 100 players I always have to loop
>> all the players to know if one is changed. Also when I want to set them
>> "unchanged" again I have to loop 100 players to do that. so 2 x 100
>> operations. But is this the best way still to do this?
> I'd probably put a callback into the setPoints method that would
> call a std::function and that function would handle whatever you
> need to do when the points value changes.
JiiPee
Jun 8, 2017, 12:59:33 PM6/8/17
to
On 08/06/2017 17:30, Alf P. Steinbach wrote:
>
> Are you sure there is only a single player?
no sorry, obviously in a game many players :). Just wanted to keep it
>
> Are you sure there is only a single player?
simple. Ye could be even like 200 players. a vector of players
>
> That's a somewhat rhetorical question because in the later discussion
> you talk about looping over 100 players. So let's assume you meant
>
> vector<Player> m_players;
>
>
>> bool m_pointsChanged{false};
>> };
>>
>> class Player
>> {
>>
>> ...
>>
>> private:
>> int points;
>> };
>>
>> When some function in the Game class modifies players points the
>> m_pointsChanged needs to change to true.
>
> Oh, like a dirty-flag.
>
> That's simple: let each player know which Game it belongs to, e.g by
> having a pointer to that Game instance.
>
>
>> What would be the best way to do this? I have this kind of situation
>> many times.
>
> You need to define “best” for THAT question to make sense.
are changed then absolutely surely the flag is also modified.. and
points cannot be changed without the flag to be modified. That was my
aim. But also I dont want player class getting access to all private
members of the Game. Speed is not an issue necessary (although I dont
like so much looping for nothing really?).
>
> And I think that by properly defining what you mean by “best”, you
> will possibly have answered your own question already. ;-)
Paavo Helde
Jun 8, 2017, 1:08:16 PM6/8/17
to
On 8.06.2017 7:27, JiiPee wrote:
> Say I have this kind of class structure:
>
> class Game
> {
>
> ...
>
> private:
> Player m_player;
> bool m_pointsChanged{false};
> };
>
> class Player
> {
>
> ...
>
> private:
> int points;
> };
One option:
> Say I have this kind of class structure:
>
> class Game
> {
>
> ...
>
> private:
> Player m_player;
> bool m_pointsChanged{false};
> };
>
> class Player
> {
>
> ...
>
> private:
> int points;
> };
class Player {
public:
Player(bool& modifiedRef): modified_(modifiedRef) {}
void ChangePoint(int x) {
points = x;
modified_ = true;
}
private:
bool& modified_;
int points;
};
Game::Game(): m_player(m_pointsChanged) {}
This is basically a callback mechanism without over-engineering.
JiiPee
Jun 8, 2017, 1:17:36 PM6/8/17
to
On 08/06/2017 18:08, Paavo Helde wrote:
>
> One option:
>
> class Player {
> public:
> Player(bool& modifiedRef): modified_(modifiedRef) {}
> void ChangePoint(int x) {
> points = x;
> modified_ = true;
> }
> private:
> bool& modified_;
> int points;
> };
>
> Game::Game(): m_player(m_pointsChanged) {}
>
> This is basically a callback mechanism without over-engineering.
oh thanks, one more solution :). I already got some other good ones..
>
> One option:
>
> class Player {
> public:
> Player(bool& modifiedRef): modified_(modifiedRef) {}
> void ChangePoint(int x) {
> points = x;
> modified_ = true;
> }
> private:
> bool& modified_;
> int points;
> };
>
> Game::Game(): m_player(m_pointsChanged) {}
>
> This is basically a callback mechanism without over-engineering.
but good to know all this. You guys know these things for sure :).
Interesting.... so i would pass the Game modified-flag to player by
reference... hmm. This might actually be the best if I understood
correctly, but have to first think.
>
>
>
Scott Lurndal
Jun 8, 2017, 1:32:32 PM6/8/17
to
1:N relationship between game and player.
JiiPee
Jun 8, 2017, 2:38:18 PM6/8/17
to
JiiPee
Jun 9, 2017, 12:08:21 AM6/9/17
to
On 08/06/2017 18:08, Paavo Helde wrote:
> One option:
>
> class Player {
> public:
> Player(bool& modifiedRef): modified_(modifiedRef) {}
> void ChangePoint(int x) {
> points = x;
> modified_ = true;
> }
> private:
> bool& modified_;
> int points;
> };
>
> Game::Game(): m_player(m_pointsChanged) {}
>
> This is basically a callback mechanism without over-engineering.
>
>
>
This was simple and quite suitable for me so I chose this. Although
>
> class Player {
> public:
> Player(bool& modifiedRef): modified_(modifiedRef) {}
> void ChangePoint(int x) {
> points = x;
> modified_ = true;
> }
> private:
> bool& modified_;
> int points;
> };
>
> Game::Game(): m_player(m_pointsChanged) {}
>
> This is basically a callback mechanism without over-engineering.
>
>
>
others suggestions good as well and might use them in the future. Just
that I could not use bool& modified_; but a pointer, because I had to be
able to do assignment for Player so needed a pointer.
JiiPee
Jun 10, 2017, 5:14:28 PM6/10/17
to
dangerous as its possible the modified_ is pointing to a non-existence
variable if its a pointer. If there any way to solve the problem that
assignment cannot be done If I use your reference method? how can i copy
Point's if it has that reference?
Gert-Jan de Vos
Jun 11, 2017, 8:41:37 AM6/11/17
to
Allocate a shared_ptr<bool> in Game and pass shared_ptr's to all Player objects involved in the Game.
Paavo Helde
Jun 11, 2017, 2:02:50 PM6/11/17
to
namely that the callback pointer may have become invalid meanwhile if
you are not careful.
As Gert-Jan suggested, every conceptual problem in computer programming
can be solved by extra redirection, so yes you can use std::shared_ptr
to either the bool variable or to the object holding the bool variable.
In the latter case I would actually suggest to hold std::weak_ptr
pointers instead, to reduce the possibility of creating cyclic data
structures (aka memory leaks).
JiiPee
Jun 11, 2017, 4:32:18 PM6/11/17
to
On 11/06/2017 19:02, Paavo Helde wrote:
>
> In the callback mechanisms you would have the same conceptual problem,
> namely that the callback pointer may have become invalid meanwhile if
> you are not careful.
>
> As Gert-Jan suggested, every conceptual problem in computer
> programming can be solved by extra redirection, so yes you can use
> std::shared_ptr to either the bool variable or to the object holding
> the bool variable. In the latter case I would actually suggest to hold
> std::weak_ptr pointers instead, to reduce the possibility of creating
> cyclic data structures (aka memory leaks).
ok thanks, I ll investiagate this.
>
> In the callback mechanisms you would have the same conceptual problem,
> namely that the callback pointer may have become invalid meanwhile if
> you are not careful.
>
> As Gert-Jan suggested, every conceptual problem in computer
> programming can be solved by extra redirection, so yes you can use
> std::shared_ptr to either the bool variable or to the object holding
> the bool variable. In the latter case I would actually suggest to hold
> std::weak_ptr pointers instead, to reduce the possibility of creating
> cyclic data structures (aka memory leaks).
JiiPee
Jun 11, 2017, 4:32:24 PM6/11/17
to
On 11/06/2017 13:41, Gert-Jan de Vos wrote:
> Allocate a shared_ptr<bool> in Game and pass shared_ptr's to all Player objects involved in the Game.
> Allocate a shared_ptr<bool> in Game and pass shared_ptr's to all Player objects involved in the Game.
Öö Tiib
Jun 12, 2017, 4:47:51 AM6/12/17
to
* There is a "game" and there are "player"s of it. Ok so far with me.
* Now somehow one of those "player"s can be without "game" (or
with already ended and destroyed game). How?
* Also the "points" of that particular "player" can somehow change
without it being in actually existing "game". How?
So now the "player" tries to notify to unexisting "game" that the points
changed. The situation itself indicates deeper insanity somewhere.
JiiPee
Jun 12, 2017, 3:41:47 PM6/12/17
to
those are selected the ones which are in a particular game. A player can
be removed from the game even in the middle of the game. And all of the
functionalities use the same Player class.
> * Also the "points" of that particular "player" can somehow change
> without it being in actually existing "game". How?
Players points are onlyl changed if it is in a game. Although other
variables like the title of the player and the name of the player can
possibly be modified even without being in a game (just modifying the
players database).
> So now the "player" tries to notify to unexisting "game" that the points
> changed. The situation itself indicates deeper insanity somewhere.
does not need to be in any game at that moment. Also logically speaking
so. If you modify a certain database -players name, why would it need to
be in a game?
Öö Tiib
Jun 14, 2017, 3:43:46 AM6/14/17
to
something "game-like". For example if it leaves some real "chess game"
then it is some "idle-list" or in "lobby" that follows interface rules of "game".
Reason is that "one to 0..many" relation can be much more convenient than
"0..1 to 0..many" relation.
>
> > * Also the "points" of that particular "player" can somehow change
> > without it being in actually existing "game". How?
>
> No the points are not changed outside the player being in a game.
> Players points are onlyl changed if it is in a game. Although other
> variables like the title of the player and the name of the player can
> possibly be modified even without being in a game (just modifying the
> players database).
there is possibility also that the "points" are not really part of "player".
May be these are part of "score"? That "score" would then be record
that is in "0..many to one" relation with "game" and "0..many to one"
relation with player. Think about it bit deeper. Getting those entities
and relations right is quite important for making software successfully.
>
> > So now the "player" tries to notify to unexisting "game" that the points
> > changed. The situation itself indicates deeper insanity somewhere.
>
> If the game is in a state of "modifying players data", then I guess it
> does not need to be in any game at that moment. Also logically speaking
> so. If you modify a certain database -players name, why would it need to
> be in a game?
"shop" that is in state of modifying "customer"s data. What is going on?
Some hacky violation of abstraction layers. Shops "advertize", "make offers",
"sell goods" etc not "modify data".
JiiPee
Jun 14, 2017, 7:53:48 AM6/14/17
to
On 14/06/2017 08:43, Öö Tiib wrote:
>> There are permanently stored players (which are in a file) and then from
>> those are selected the ones which are in a particular game. A player can
>> be removed from the game even in the middle of the game. And all of the
>> functionalities use the same Player class.
> On such case you could make it so that "player" must be always in
> something "game-like". For example if it leaves some real "chess game"
> then it is some "idle-list" or in "lobby" that follows interface rules of "game".
> Reason is that "one to 0..many" relation can be much more convenient than
> "0..1 to 0..many" relation.
I got a bit exited about what others suggested about shared pointer,
>> There are permanently stored players (which are in a file) and then from
>> those are selected the ones which are in a particular game. A player can
>> be removed from the game even in the middle of the game. And all of the
>> functionalities use the same Player class.
> On such case you could make it so that "player" must be always in
> something "game-like". For example if it leaves some real "chess game"
> then it is some "idle-list" or in "lobby" that follows interface rules of "game".
> Reason is that "one to 0..many" relation can be much more convenient than
> "0..1 to 0..many" relation.
which might do the job. But I think about this idea as well.
>
>>> * Also the "points" of that particular "player" can somehow change
>>> without it being in actually existing "game". How?
>> No the points are not changed outside the player being in a game.
>> Players points are onlyl changed if it is in a game. Although other
>> variables like the title of the player and the name of the player can
>> possibly be modified even without being in a game (just modifying the
>> players database).
> I still don't understand it fully but what it sounds like is that
> there is possibility also that the "points" are not really part of "player".
class Player
{
private:
int points;
};
so it is fixed part of it. Its the points the player gets in one/current
game. Its there (currently) only for the purpose of the current game.
> May be these are part of "score"? That "score" would then be record
its the score/points in the current running game (if the player in it).
> that is in "0..many to one" relation with "game" and "0..many to one"
> relation with player. Think about it bit deeper. Getting those entities
> and relations right is quite important for making software successfully.
>
>>> So now the "player" tries to notify to unexisting "game" that the points
>>> changed. The situation itself indicates deeper insanity somewhere.
>> If the game is in a state of "modifying players data", then I guess it
>> does not need to be in any game at that moment. Also logically speaking
>> so. If you modify a certain database -players name, why would it need to
>> be in a game?
> Yes but that sounds like unnaturally generic state. As analogy imagine a
> "shop" that is in state of modifying "customer"s data. What is going on?
> Some hacky violation of abstraction layers. Shops "advertize", "make offers",
> "sell goods" etc not "modify data".
But a good topic to discuss, after I think about it.
Well it works pretty well like it is, but always good to make things
more logical.
Öö Tiib
Jun 15, 2017, 10:44:14 AM6/15/17
to
for features that I can imagine. Player can be in lot of games during
his career. Player may be interested how well he did in games of the
past. But if the points are in player then those will be overwritten by
next game.
>
> > May be these are part of "score"? That "score" would then be record
>
> ye could call is score.... i just named it points. But the same thing:
> its the score/points in the current running game (if the player in it).
>
> > that is in "0..many to one" relation with "game" and "0..many to one"
> > relation with player. Think about it bit deeper. Getting those entities
> > and relations right is quite important for making software successfully.
> >
> >>> So now the "player" tries to notify to unexisting "game" that the points
> >>> changed. The situation itself indicates deeper insanity somewhere.
> >> If the game is in a state of "modifying players data", then I guess it
> >> does not need to be in any game at that moment. Also logically speaking
> >> so. If you modify a certain database -players name, why would it need to
> >> be in a game?
> > Yes but that sounds like unnaturally generic state. As analogy imagine a
> > "shop" that is in state of modifying "customer"s data. What is going on?
> > Some hacky violation of abstraction layers. Shops "advertize", "make offers",
> > "sell goods" etc not "modify data".
>
> sure if its not logical I ll change it. I ll think about this...
> But a good topic to discuss, after I think about it.
> Well it works pretty well like it is, but always good to make things
> more logical.
a "game" to "hack bits of player" but to "provide context for playing".
Interacting with game technically can result that some subset of bits
of player change but it is not responsibility of game to deal with those
bits.
JiiPee
Jun 16, 2017, 3:38:34 PM6/16/17
to
On 15/06/2017 15:43, Öö Tiib wrote:
> On Wednesday, 14 June 2017 14:53:48 UTC+3, JiiPee wrote:
>>
>> so it is fixed part of it. Its the points the player gets in one/current
>> game. Its there (currently) only for the purpose of the current game.
> Yes that is what I wrote that may be is not made in convenient way
> for features that I can imagine. Player can be in lot of games during
> his career. Player may be interested how well he did in games of the
> past. But if the points are in player then those will be overwritten by
> next game.
I guess you mean that better to have points outside the Player class. I
> On Wednesday, 14 June 2017 14:53:48 UTC+3, JiiPee wrote:
>>
>> so it is fixed part of it. Its the points the player gets in one/current
>> game. Its there (currently) only for the purpose of the current game.
> Yes that is what I wrote that may be is not made in convenient way
> for features that I can imagine. Player can be in lot of games during
> his career. Player may be interested how well he did in games of the
> past. But if the points are in player then those will be overwritten by
> next game.
agree that might be a perfect way, but then that would increase the
complexity of the code quite a lot (as I would have to create a
structure to hold the points). thats why I put it there. Other reason
was that because I cannot see the Player being used in this program for
any other purposes than 1) playing a game 2) modifying its data. So I
chose in this case to just put it there to keep it simple as I cannot
see player used in any other ways in this program.
My idea was here that the Player contains all the information for the
player, game points being one.
If I use the player in more complex way then maybe better to separate in
the future.
It nicely walks there "for free" with the player - dont need to worry
that a player gets another players/wrong points.
>> sure if its not logical I ll change it. I ll think about this...
>> But a good topic to discuss, after I think about it.
>> Well it works pretty well like it is, but always good to make things
>> more logical.
> It is not bad logic. It is wrong abstraction layer. We do not expect
> a "game" to "hack bits of player" but to "provide context for playing".
> Interacting with game technically can result that some subset of bits
> of player change but it is not responsibility of game to deal with those
> bits.
where the whole game is run and Player.
In main I create game-instance and thats it. Everything runs there.
Thats why it also modifies player.
Game means: the game is running. Its like a video game: when you swich
on the video game we can say that the game is running, right? or you
mean that the game only starts when the first move is done? evertyghing
before that does not belong to game (like adding player to the
game/modifying players data etc)?
JiiPee
Jun 16, 2017, 3:43:39 PM6/16/17
to
On 15/06/2017 15:43, Öö Tiib wrote:
> But if the points are in player then those will be overwritten by
> next game.
it really should be called:
> next game.
int currentPointsInGame;
then there is no question what it is used for. that would solve that
confusion
JiiPee
Jun 16, 2017, 4:09:01 PM6/16/17
to
On 14/06/2017 08:43, Öö Tiib wrote:
> On such case you could make it so that "player" must be always in
> something "game-like". For example if it leaves some real "chess game"
> then it is some "idle-list" or in "lobby" that follows interface rules of "game".
Yes I agree better structure would be to separate players info (name,
> something "game-like". For example if it leaves some real "chess game"
> then it is some "idle-list" or in "lobby" that follows interface rules of "game".
picture, address etc) from the game data. The reason I started doing
this is because at that time I was "sure" that this program will never
do lobby-kind of things, its only a program running this particular
simple game. So I was kind of thinking keeping it "simple" rather than
creating many different classes etc.
But its true that if in the future I want to add more games and use the
same base-structure i have here, then I would need to modify a bit that
Player structure to be more general. Although that is not difficult to
do as its a simple game.
I should be thinking ahead even now (even though the game is very simple)?
Öö Tiib
Jun 17, 2017, 4:18:20 AM6/17/17
to
On Friday, 16 June 2017 23:09:01 UTC+3, JiiPee wrote:
> On 14/06/2017 08:43, Öö Tiib wrote:
> > On such case you could make it so that "player" must be always in
> > something "game-like". For example if it leaves some real "chess game"
> > then it is some "idle-list" or in "lobby" that follows interface rules of "game".
>
>
> Yes I agree better structure would be to separate players info (name,
> picture, address etc) from the game data. The reason I started doing
> this is because at that time I was "sure" that this program will never
> do lobby-kind of things, its only a program running this particular
> simple game. So I was kind of thinking keeping it "simple" rather than
> creating many different classes etc.
That was not what mine sentence you quoted said. Lets say you already
> On 14/06/2017 08:43, Öö Tiib wrote:
> > On such case you could make it so that "player" must be always in
> > something "game-like". For example if it leaves some real "chess game"
> > then it is some "idle-list" or in "lobby" that follows interface rules of "game".
>
>
> Yes I agree better structure would be to separate players info (name,
> picture, address etc) from the game data. The reason I started doing
> this is because at that time I was "sure" that this program will never
> do lobby-kind of things, its only a program running this particular
> simple game. So I was kind of thinking keeping it "simple" rather than
> creating many different classes etc.
have classes for player and game. When player is guaranteed to be always
in game then that for example can make all the checks and handling like
if(player.current_game == NULL) unneeded. That *is* keeping it simpler.
No?
> But its true that if in the future I want to add more games and use the
> same base-structure i have here, then I would need to modify a bit that
> Player structure to be more general. Although that is not difficult to
> do as its a simple game.
>
>
> I should be thinking ahead even now (even though the game is very simple)?
the changes needed later may be so major that it is better to write new
program instead of making the changes.
Richard Damon
Jun 17, 2017, 5:38:57 PM6/17/17
to
cases, but not in others. Particularly when something can get involved
in different contexts. In yoour case I can see the use for several
different classes for differing sorts of information in different
contexts. It sounds like you have possibly one set of information about
a player not connected to any particular game, global information about
them. This information would be saved in permanent storage, and perhaps
updated by specific actions.
A second chunk of data is for a player in a particular game. This data
would need to know what player it relates to and what game. This iis
where your current points would be stored and updated as the player
plays the game. This data might only live in the processors ram, or
maybe saved as part of the game if you have that sort of functionality.
A last chunk of data would be a historical record. When the game is
over, a summary of how they did is stored in permanent storage, and that
data is likely never changed thereafter.
JiiPee
Jun 23, 2017, 3:24:11 PM6/23/17
to
On 17/06/2017 22:38, Richard Damon wrote:
> Rolling up 'everything' about something in a single class works in
> some cases, but not in others. Particularly when something can get
> involved in different contexts. In yoour case I can see the use for
> several different classes for differing sorts of information in
> different contexts. It sounds like you have possibly one set of
> information about a player not connected to any particular game,
> global information about them. This information would be saved in
> permanent storage, and perhaps updated by specific actions.
>
> A second chunk of data is for a player in a particular game. This data
> would need to know what player it relates to and
Ye data related only to a game. But how would you name that class?
> Rolling up 'everything' about something in a single class works in
> some cases, but not in others. Particularly when something can get
> involved in different contexts. In yoour case I can see the use for
> several different classes for differing sorts of information in
> different contexts. It sounds like you have possibly one set of
> information about a player not connected to any particular game,
> global information about them. This information would be saved in
> permanent storage, and perhaps updated by specific actions.
>
> A second chunk of data is for a player in a particular game. This data
> would need to know what player it relates to and
Player? How would you name the persons permanent detail class? Person?
Or PlayerInGame/Player?
> what game. This iis where your current points would be stored and
> updated as the player plays the game. This data might only live in the
> processors ram, or maybe saved as part of the game if you have that
> sort of functionality.
>
> A last chunk of data would be a historical record. When the game is
> over, a summary of how they did is stored in permanent storage, and
> that data is likely never changed thereafter.
ID is the players (sing in-) name.
JiiPee
Jun 23, 2017, 3:29:40 PM6/23/17
to
On 17/06/2017 09:17, Öö Tiib wrote:
> That was not what mine sentence you quoted said. Lets say you already
> have classes for player and game. When player is guaranteed to be always
> in game then that for example can make all the checks and handling like
> if(player.current_game == NULL) unneeded. That*is* keeping it simpler.
> No?
The way I do is that all players are read first in a vector. Then when
> That was not what mine sentence you quoted said. Lets say you already
> have classes for player and game. When player is guaranteed to be always
> in game then that for example can make all the checks and handling like
> if(player.current_game == NULL) unneeded. That*is* keeping it simpler.
> No?
game starts I create another vector and copy the players there from the
first vector who want to play.
but true to be perfect the game data better to isolate from persons details
0 new messages