Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


Ideally how many parameters should an object reference pass through


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 warnexus   Prime Members   -  Reputation: 1448

Like
0Likes
Like

Posted 21 January 2014 - 09:33 PM

Ideally how many parameters should an object reference pass through to obtain that reference in a different class before it becomes "bad design or unreadable"?

 

I'm coding my game in Java. I only pass 2 parameters so I am not sure if I am safe or I need to refactor it.

 

I'm writing a dialogue system where I need the object reference of the main character. Problem is that reference is in the Game class. I need it in the DialogueSystem class. But it needs to go through the parameters of the NPC update method and then pass through the DialogueSystem update method.

 

The reason I need it in the DialogueSystem is because I need to make sure the main character does not move when it is interacting with the npcs by checking its ActionState (IDLE,RUNNING,etc).

 

Each NPC has a DialogueSystem object tied to it.

 

 



Sponsor:

#2 frob   Moderators   -  Reputation: 22201

Like
3Likes
Like

Posted 21 January 2014 - 10:39 PM

So you need to know about multiple objects to do your job, and there are connections and dependencies that seem to cross boundaries. This is a pretty normal situation.



One option: Do what it takes to make the game feature work. To a large extent it really doesn't matter what a specific implementation detail looks like. Every veteran programmer has seen code that makes them cringe. At a bare minimum the code must work. I will take confusing bug-free code over bug-ridden code any day. Whatever you do, make sure it works.

A second option: Pass the whole thing, not a part of a thing. This may mean just creating a structure that takes all the game actors and passes it around as a unit, or doing something else that keeps them together. When you tell a game actor to walk you don't just move the feet, instead you give the actor a general instruction and let them do the details. The actor coordinates the details with pathfinding, with path planning and avoidance, with animation, with audio, and with other components. After a great deal of work the motion takes place. When you have lots of parts it is often convenient to bundle them together for a short time.

A third option: Consider the different roles of a user of a class versus the implementer of a class. The people who use the class should be given an extremely simple interface, usually just a single command. They do not care about the details, even if that involves crossing many different systems. As long as you are isolating the complexity to within the object and providing a simple interface, this is generally a good thing.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#3 haegarr   Crossbones+   -  Reputation: 4418

Like
0Likes
Like

Posted 22 January 2014 - 02:41 AM

Although frob is right in general, in the following an approach for the given problem:

 

The PC and the NPC should not move when being in a conversation. This means that "dialog" is a modal mode w.r.t. movement. The fact that a (N)PC is participating in a conversation is reflected by referring a common ConversationInAction object. The controller of the PC and the AI of the NPC are respecting this. If the controller is instructed to move the PC, it leaves the conversation by notifying the ConversationInAction object and switching the own state. The NPC (in fact the entire remaining party of conversation) may now leave conversation, too, so that the common ConversationInAction object gets deleted in the end. Or they may continue to talk (if more than 1 NPC is remaining).

 

Summing up, the state of the PC and NPC reflect conversation. It should be regardless whether the conversationalists are PCs or NPCs, whether they a 2 or more. The conversational part of the state is set by the mechanism that triggers the conversation, and it is respected and later on reset by the PC's controller or NPC's AI. So there is no need to pass the PC through a top level update method.


Edited by haegarr, 22 January 2014 - 02:50 AM.


#4 arka80   Members   -  Reputation: 1006

Like
0Likes
Like

Posted 22 January 2014 - 02:50 AM

I quote the first option of frob, and add my 2 cents:

 

in a design of mine, the dialogue would be a state of the game, and in that state user input for movement would simply be ignored. 



#5 warnexus   Prime Members   -  Reputation: 1448

Like
0Likes
Like

Posted 22 January 2014 - 01:16 PM


To a large extent it really doesn't matter what a specific implementation detail looks like.

 

Does this factor in making sure a particular class "should know" about particular objects to get the job done and "should not know" about other particular objects even to get the job done? 

 

Does the implementation not matter because "design always change so it should be a worrying issue to over think the design"?

 

My eyebrow raised when I read this statement.



#6 warnexus   Prime Members   -  Reputation: 1448

Like
0Likes
Like

Posted 22 January 2014 - 01:20 PM

Although frob is right in general, in the following an approach for the given problem:

 

The PC and the NPC should not move when being in a conversation. This means that "dialog" is a modal mode w.r.t. movement. The fact that a (N)PC is participating in a conversation is reflected by referring a common ConversationInAction object. The controller of the PC and the AI of the NPC are respecting this. If the controller is instructed to move the PC, it leaves the conversation by notifying the ConversationInAction object and switching the own state. The NPC (in fact the entire remaining party of conversation) may now leave conversation, too, so that the common ConversationInAction object gets deleted in the end. Or they may continue to talk (if more than 1 NPC is remaining).

 

Summing up, the state of the PC and NPC reflect conversation. It should be regardless whether the conversationalists are PCs or NPCs, whether they a 2 or more. The conversational part of the state is set by the mechanism that triggers the conversation, and it is respected and later on reset by the PC's controller or NPC's AI. So there is no need to pass the PC through a top level update method.

What is a modal mode w.r.t movement? What does w.r.t  stand for? What is an controller? 

 

I got the implementation to work. The implementation is mostly state management.. I am just confused by the terms you used. Google did not provide much help on the definition.



#7 frob   Moderators   -  Reputation: 22201

Like
0Likes
Like

Posted 22 January 2014 - 02:42 PM

 


To a large extent it really doesn't matter what a specific implementation detail looks like.

 

Does this factor in making sure a particular class "should know" about particular objects to get the job done and "should not know" about other particular objects even to get the job done? 

 

Does the implementation not matter because "design always change so it should be a worrying issue to over think the design"?

 

My eyebrow raised when I read this statement.

 

 

You still need to be smart about it, but assuming the design is stable and you are skilled enough to right low-defect code, I still feel the specific implementation details aren't that important.

 

In my experience most code is only written once, and it is pretty good. There are usually only two real troublesome spots.  The first troublesome spot is where design changes and code must be modified to reflect it. Fortunately good designs keep this to a minimum. The second troublesome spot is defective code; either through bugs or performance problems or some other defect. Usually this code is clustered around confusing areas of design or boundary conditions.

 

As ad hoc numbers I'd say about 60% of all code falls into the single use bucket. It works properly, it does the job listed in the function name, it is easy enough to read. Nobody (including me) will ever revisit the code. About 20% of the code will be reviewed periodically when people are hunting down issues or design changes but not really modifying, and the remaining 20% will actually be modified for various reasons in the future.

 

In a code review I might make a comment that something looks a little clunky, but if I can see what it is doing and the results are valid, I'm usually fine with mildly ugly code.


Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#8 warnexus   Prime Members   -  Reputation: 1448

Like
0Likes
Like

Posted 22 January 2014 - 05:25 PM

Thanks for the information you all!



#9 frob   Moderators   -  Reputation: 22201

Like
0Likes
Like

Posted 23 January 2014 - 12:27 AM

What is a modal mode w.r.t movement? What does w.r.t  stand for? What is an controller? 
 
I got the implementation to work. The implementation is mostly state management.. I am just confused by the terms you used. Google did not provide much help on the definition.


WRT: with respect to.

In several games I there is a pattern where once game actors are in a conversation or dialogue they leave the idle state; they have a state that indicates they are involved in an interaction. That interaction is controlled by a system dedicated to dialog or other types of interactions. They are composed of all the actors and game objects necessary for the interaction to take place. All of them are locked until the interaction is complete, then they return to idle.

It doesn't need to just be actor-to-actor interactions. It can be actor-to-object interactions, or simply interactions targeting themselves. They can't do anything else while in the interactions, although you could easily design the interactions to detect situations that may cause an interruption or higher priority interaction to cause a premature ending of the interaction. That's the kind of thing you see in The Sims. An actor will start doing something at autonomous priority they may do it for several hours. When they are pushed to do something much more interesting or at a higher priority they will transition out of their interaction, return to idle, and move to the next interaction.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#10 haegarr   Crossbones+   -  Reputation: 4418

Like
0Likes
Like

Posted 23 January 2014 - 02:32 AM

What is a modal mode w.r.t movement? What does w.r.t  stand for? What is an controller? 

* In programming "modal" means that the standard behavior is blocked as long as a particular mode is on. It's used as "modal dialog" what means that when such a dialog is open, the document window below is not useable until the dialog is closed. What I meant with this in the context of your dialog system is that the dialog system block the standard possibility of moving around.

 

* w.r.t.: as frob already told.

 

* Controller is a usual name for those part of a game engine with which the player controls the player character. This is the counterpart of AI, which controls non-player characters. A controller usually interprets user input and alters the state of the player character accordingly.


Edited by haegarr, 23 January 2014 - 02:35 AM.


#11 warnexus   Prime Members   -  Reputation: 1448

Like
0Likes
Like

Posted 23 January 2014 - 10:14 AM

 

What is a modal mode w.r.t movement? What does w.r.t  stand for? What is an controller? 

* In programming "modal" means that the standard behavior is blocked as long as a particular mode is on. It's used as "modal dialog" what means that when such a dialog is open, the document window below is not useable until the dialog is closed. What I meant with this in the context of your dialog system is that the dialog system block the standard possibility of moving around.

 

* w.r.t.: as frob already told.

 

* Controller is a usual name for those part of a game engine with which the player controls the player character. This is the counterpart of AI, which controls non-player characters. A controller usually interprets user input and alters the state of the player character accordingly.

 

Thanks for the explanation! I understand now.



#12 warnexus   Prime Members   -  Reputation: 1448

Like
0Likes
Like

Posted 23 January 2014 - 10:15 AM

 

What is a modal mode w.r.t movement? What does w.r.t  stand for? What is an controller? 
 
I got the implementation to work. The implementation is mostly state management.. I am just confused by the terms you used. Google did not provide much help on the definition.


WRT: with respect to.

In several games I there is a pattern where once game actors are in a conversation or dialogue they leave the idle state; they have a state that indicates they are involved in an interaction. That interaction is controlled by a system dedicated to dialog or other types of interactions. They are composed of all the actors and game objects necessary for the interaction to take place. All of them are locked until the interaction is complete, then they return to idle.

It doesn't need to just be actor-to-actor interactions. It can be actor-to-object interactions, or simply interactions targeting themselves. They can't do anything else while in the interactions, although you could easily design the interactions to detect situations that may cause an interruption or higher priority interaction to cause a premature ending of the interaction. That's the kind of thing you see in The Sims. An actor will start doing something at autonomous priority they may do it for several hours. When they are pushed to do something much more interesting or at a higher priority they will transition out of their interaction, return to idle, and move to the next interaction.

 

Interesting. My implementation works exactly like the first paragraph. Thanks frob for the explanation! 






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS