Jump to content


Photo

Task 11


  • Please log in to reply
7 replies to this topic

#1 rincewind

rincewind

    Programming Department

  • Xenocide Programming Department
  • 541 posts

Posted 25 November 2005 - 03:43 PM

Just a reminder, here's the task description:

Base implementation of the player class cluster and their bindings into the other clusters. Base implementation of the entry point to the Player and their owned objects. No serialization is required.


Just starting a thread for it. From what I've seen, most of that stuff is already in the codebase. From what I get from that description what is needed for that task is just getting all the members, member-collections and their accessors in there, as well as the defined methods with some basic functionality.

Only thing I really see missing is the Profile especially GameOptions implementation. Don't know how this would relate to Settings though... Can someone shed some light on this as I haven't been at that design session and I couldn't find anything on the forums.

Also, what else would be needed to call that task finished?

Rincewind
Posted Image

I love boost!!! The next best thing since the invention of C++.

#2 UnFleshed One

UnFleshed One

    Programming Department

  • Xenocide Inactive
  • 304 posts

Posted 25 November 2005 - 11:08 PM

Profile goes with this task, yes. There is null state of profile already.

GameOptions is not related to Settings. I guess it should replace it. If we can get rid of Settings and transfer all functionality to GameOptions, thus removing another singleton (there is a crusade on that, yes :)), and making more clear and proper hierarchy.

Is there any reason why GameOptions can't perform all functions of Settings? (by being inside Profile which is inside Player, which is global as a singleton).

Edited by UnFleshed One, 26 November 2005 - 01:54 AM.

Darkness is under the candle.

#3 rincewind

rincewind

    Programming Department

  • Xenocide Programming Department
  • 541 posts

Posted 26 November 2005 - 05:04 AM

Profile goes with this task, yes. There is null state of profile already.

GameOptions is not related to Settings. I guess it should replace it. If we can get rid of Settings and transfer all functionality to GameOptions, thus removing another singleton (there is a crusade on that, yes :)), and making more clear and proper hierarchy.

Is there any reason why GameOptions can't perform all functions of Settings? (by being inside Profile which is inside Player, which is global as a singleton).

<{POST_SNAPBACK}>


I don't know, moving the Singleton in there shouldn't be a big problem. Question is if all stuff in setting is really part of a player-profile... There's some tweakable UI stuff that is in there more for testing and data-driven design stuff.
Also, there's the issue of lifecycle. Some of that stuff is already needed at initialization time. E.g. sound settings.
I don't know if we shouldn't maybe keep it separate and have GameOptions "inject" the player-settings into the Settings-class.

edit: btw, does it make sense to have settings liked to a player-instance (e.g. a savegame?) think music volume.


Rincewind

Edited by rincewind, 26 November 2005 - 06:00 AM.

Posted Image

I love boost!!! The next best thing since the invention of C++.

#4 UnFleshed One

UnFleshed One

    Programming Department

  • Xenocide Inactive
  • 304 posts

Posted 26 November 2005 - 01:09 PM

I see what you mean... So Settings will do actual work and store global settings, like video options and stuff like that, while GameOptions will store and provide Profile-specific settings. Like currently used shortcut map and so on.

They don't linked to Player instance, they linked to Profile instance.

Edited by UnFleshed One, 26 November 2005 - 01:09 PM.

Darkness is under the candle.

#5 rincewind

rincewind

    Programming Department

  • Xenocide Programming Department
  • 541 posts

Posted 27 November 2005 - 04:24 AM

I see what you mean... So Settings will do actual work and store global settings, like video options and stuff like that, while GameOptions will store and provide Profile-specific settings. Like currently used shortcut map and so on.

They don't linked to Player instance, they linked to Profile instance.

<{POST_SNAPBACK}>


Well, profile is linked to player, so in an indirect fashion, GlobeOptions are linked to player. I still don't quite see the reasoning behind it. What would you store in a savegame by savegame fashion?

Rincewind
Posted Image

I love boost!!! The next best thing since the invention of C++.

#6 UnFleshed One

UnFleshed One

    Programming Department

  • Xenocide Inactive
  • 304 posts

Posted 27 November 2005 - 12:18 PM

As I understand it, profile is something that is custom for every player (that is, gamer). So, since we have some settings common for a computer and some settings special for particular user, we store them separately.

To be more OOP we probably should have a Settings class, which will do the actual work, then have a GlobalSettings class wich will store computer-wide settings and then have UserSettings class, wich will manage other settings on per-user basis...

UserSettings (now GameOptions) will be owned by Profile, Settings will be its own singleton and GlobalSettings I don't know yet.
Darkness is under the candle.

#7 rincewind

rincewind

    Programming Department

  • Xenocide Programming Department
  • 541 posts

Posted 27 November 2005 - 02:43 PM

The feature of having user-specific settings sure sounds interesting, but I wouldn't put too much effort into it right now. Most games get by very well without it and it will cost us quite a bit to rip the current settings apart and put them somewhere else.

Rincewind
Posted Image

I love boost!!! The next best thing since the invention of C++.

#8 UnFleshed One

UnFleshed One

    Programming Department

  • Xenocide Inactive
  • 304 posts

Posted 27 November 2005 - 02:59 PM

So, there will be no GameOptions in profile. For this task it is not nessesary to do anything with Settings then, no?
Darkness is under the candle.