C++ Namespace vs Reference passed around like crazy - Implement a quest journal

Question

May sound funny, but that's what the question is about.

Suppose you have this situation: http://i48.tinypic.com/whl6pk.jpg

Red squares are data types. Hexagons are methods and Journal is the main issue here. Or more exactly, how the link between Game and Journal should be interpreted. Basically, a lot of game components (instantiated inside of Game) will have to gain access to the Journal functionality. The two options that I have thought of myself are the following:

Journal could be a namespace w/ 'globally' used methods and fields. Something like:

journal::AddEntry(someEntry);

OR I could make Journal a Class, just like Game, and instantiate it inside of Game, and then pass a reference to Journal to each property of Game that needs to use the journal. Something like:

  GameProperty *property = new GameProperty(&ourJournal);
  //...inside of property:
  Journal *referenceToJournal;

But then, if I'd delete referenceToJournal, the actual ourJournal object would be deleted too, right? I'm pretty sure this just complicates things by a lot, and having lots of references towards the same object is a bad habit.

I'm kind of thinking that the:

namespace Journal
{
//Fields and methods go here
}
...
#include "Journal.h"
Journal::method();

is the best way to achieve global visibility for the Journal without much stress. But it kind of hurts, since I come from a C# & XNA background where everything is object oriented. Which is the main reason I have thought of a:

class Game()
{
void loadcontent();
void update();
void draw();
}

logic.

How would you attempt to achieve given the scenario? Instantiate a Journal inside of Game and then constantly pass a reference to Journal to all the other game components (instantiated inside of Game), or just treat everything (including Game) as namespaces to provide 'global' access to all required components? I'm also thinking about classes with public static fields and methods, but that'd be just like namespaces, at least from my point of view. Here is some more supportive code, to better describe my view on things (pseudocode for the namespace idea):

//FILE Journal.cpp (implementation of Journal.h)
namespace Journal
{
struct JournalEntry
{
    INT QuestID;
    String Description;
};

Vector<JournalEntry> Entries;


void AddEntry(JournalEntry theEntry)
{
    Entries.Add(Entry);
}

/*
* Used at getting all text that has to be shown on the
*/
Vector<String> GetDescriptionsForEntriesWithQuestID(INT theQuestID)
{
    Vector<String> Descriptions;
    foreach (JournalEntry jEntry in Entries)
    {
        if (jEntry.QuestID == theQuestID)
        {
            Descriptions.Add(jEntry.Description);
        }
    }
    return Descriptions;
}
};


//FILE GameComponent.cpp implementation of GameComponent.h
#include "Journal.h"
void GameComponent::ShowInfo()
{
Vector<String> info = Journal::GetDescriptionsForEntriesWithQuestID(3);
//go through the collection and do stuff
}

Thanks!

Answer 1

My first instinct is that you've got a mistaken assumption hiding in the sentence 'Basically, a lot of game components (instantiated inside of Game) will have to gain access to the Journal functionality.' Why will a lot of game components need access to the journal? The way you've laid it out, journal entries should only be coming from your 'story manager' or equivalent; information the player learns about NPCs can come from this, information they learn about objects can come from this, etc. At worst, it feels like you should hang the journal methods off of your core Player class somewhere and be making calls along the lines of Player->AddJournalEntry() (which will then call to the journal class behind the scenes, of course). Regardless, the upshot is that 'lots of game components' needing access to this fairly specialized entity is a good sign of a design error somewhere else in the chain.

Answer 2

Well, namespace are more to organize code, and a journal seems to me better as a class. To help you out, you could use C++ references (Journal& myJournal) and also use the theory of "whoever creates, is the same one that deletes". That is, if your Game new'ed Journal, it should delete it too, no other object should bother about deleting it, Game should.

This works very well, and avoid memory leaks, since you know who should delete it, and you don't get confused about where to delete it.

And just one plus: Namespaces are just names. a static global and namespace members are just the same on compiled code.

Answer 3

This started as a comment on Steven Stadnicki's comment, but grew too big so I figured might as well answer it fully.

As for your question on whether to use a class or module-type thing with a namespace, I don't think it actually matters. Rid yourself of this need to constantly be object-oriented! Whether you should use a namespace or some kind of global/singleton/dependency-injected class depends on how you're using namespaces in general.

If you'd have multiple journals loaded at one time with different state, then yes it should be a class. Otherwise, it might be unnecessary. I presume that the general flow for setting up and using the journal is something like this:

On game startup:
  Initialize Journal (either Player.Journal = new Journal(); or Journal::Initialize()).
    This should grab memory that the journal needs to do work
  On game startup, Journal load quest data from disk for lookup by ID
  On saved-game load, Journal loads quest data for the current player
  During gameplay, Journal accepts queries and operations to lookup quest info or add quests to current player's journal
  On saved-game unload, flag all player-specific data as "dirty" or reset on the spot
  On game quit, Journal cleans itself up

For games where you'd only have a single Journal (ie: no multiplayer, sync or async), the namespace approach is perfectly valid so long as it fits within your scheme of namespace usage. You could also make a class with entirely static members. The differences are subtle and not worth thinking about. There's fundamentally little difference between calling Journal* journalInstance = new Journal(); ... delete journalInstance; and Journal::Init(); ... Journal::DeInit();. You're just allocating and initializing memory, manipulating it, and then freeing it.

Now for my commentary on Steven's comment. I might have misinterpreted what you were getting at, I apologize and please let me know so I can edit this to make more sense. This approach doesn't seem to be that flexible in the long run. If I'm following your logic correctly, this means that for any sort of system like this related to any system that may be a part of the player, you'd need to add a check to the list of things that happens when the player interacts with an object. Say you wanted a rock that would add something to your journal and give you a buff. That's an extra conditional in the Interact() function. "Do you have journal text to add? Do you have buffs to apply to the player?" Now what if you have another rock that adds a buff to the player, but also triggers a cutscene. Now you have "Do you have journal text to add? Do you have any buffs to apply to the player? Do you have a cutscene to play?" This will get out of hand.

It would make more sense to me to make AddJournalEntryOnInteract a behavior/component which would be in charge of calling the Journal functions. That way you could add as many sorts of components as you'd like that could respond to a player interact. If there's only ever one Journal ever, then hiding Journal functions behind the player class seems like it's adding unnecessary overhead. This would make sense in multiplayer, since each player would have their own journal, but if this is single player, that's not really necessary to do and just adds one more set of functions to your player class that don't need to be there.

The implementation could be, that in your scene data, you give this rock a list of components that respond to Interact();. When the rock is Interact()ed with, it iterates through all of its components that respond to Interact(); and each has the opportunity to do their thing like adding content to the journal, buffing the player, triggering a cutscene, or whatever.

EDIT

One point I forgot to mention about the Journal namespace vs class thing, is that you'll likely find it easier to create and use mock journal objects if you want to do unit testing with a mocked Journal.

ANOTHER EDIT: But then again, what's so bad about include guards?