Question on Code Structure
I would put all the action of a person in the class Person.
If you put all the interaction function in another class it kinds of break a little the concept of object. You will end with a sort of huge library class with a lot of function not related to the library but other class. And imagine if you want to modify a function, you will have to fetch into your huge library class the one function which affect the one class you want to modify. I think it would be simpler to have all the function related to a class in this class :)
Here, the function haveConversation would be in Person, and would take another Person (the target the actor want to interact with) as a parameter. And forcing him into the action haveConversation.
Here's an old article that describes this paradigm: http://www.gamasutra.com/view/feature/131404/gdc_2002_social_activities_.php
Which is exactly why you wouldn't put it into Person. A Person shouldn't need to know about and track the state of every possible interaction. Each class/object should handle as few pieces of state as you can while still being complete. Otherwise you end up with core objects like your Person having hundreds of functions and instances end up several kilobytes in size. Working on that kind of code is a nightmare.
You might want to Google the "SOLID" principles. Also, perhaps Google some of the GDC talks and presentations on how the Sims was structured since it's pretty similar to what you're doing. Their AI and interaction systems, for instance, are ingeniously light-weight given the level of complexity Sims characters display.
Sean Middleditch – Game Systems Engineer – Join my team!
Alvaro, just for clarification, are you (and/or the linked article) suggesting to have a class called something like 'SocialInteractions' filled with functions like 'HaveConversation' or 'ShakeHands' and then call that class' functions with the Person objects?
No. I can see two alternatives:
1) You can have individual classes for each kind of interaction (what Sean suggests). It might be useful to have them derive from a common interface.
2) You can describe activities in some scripting language so they can be exposed to a game designer. Different activities would have different state, as described by the variables used in the corresponding script.
The choice between those alternatives depends on how many different interactions you may have, how complex they are and how easy you want to make changing them. I think option 2 is very neat but it might be overkill if all you want to do is have occasional greetings between agents.
I would probably make the conversation an object in itself, and have a way to add and remove participants and update the conversation on a frame by frame basis whilst the game runs.
This way, you can easily have a situation where multiple people join in the same conversation, more than two of them.
Of course, this is just the way i'd do it, and just an opinion :)
Games/Projects Currently In Development:
Discord RPG Bot | D++ - The Lightweight C++ Discord API Library | TriviaBot Discord Trivia Bot