Advertisement

Question on Code Structure

Started by April 01, 2015 02:37 PM
6 comments, last by Brain 9 years, 10 months ago
I have a question mostly regarding design/structure. I am planning some sort of life/social simulator. Say I have a class called 'Person' which I use the generate the people that populate the game world. If I want to create methods that will take 2 people and make them interact (for example, haveConversation, or something of the sort) is it better to have that method within the 'Person' class, or a separate class used for holding all similar methods like this. Or possibly another option that I am not aware of. Any help/guidance is appreciated!

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.

Advertisement
I disagree. There is a natural option that is having the conversation be an object that instructs its participants to say or do things. The interface of Person would allow it to say things, or to play animations. But you wouldn't want to bloat it with methods to have conversations, participate in dances, take buses or pay bills. All of those things are handled by objects of a class SocialActivity that has a list of participants and sends them actions to perform.

Here's an old article that describes this paradigm: http://www.gamasutra.com/view/feature/131404/gdc_2002_social_activities_.php
Thanks to the both of you for input. 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? Pardon my noobiness, I'm learning as I go. I found that article very interesting by the way.
I'd imagine you'd want a unique class for each kind of interaction, since there's all kinds of unique state that needs to be managed for an interaction.

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.
Advertisement
A someone with slightly more than beginner experience, and being that this will be a mostly text/menu based game that probably wont have an incredible amount of depth, option 1, as Sean suggested, will probably be the safer route for me. Thanks for the inputs!

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 :)

This topic is closed to new replies.

Advertisement