• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Nicholas Kong

Ideally how many parameters should an object reference pass through

11 posts in this topic

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.

 

 

0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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. 

0

Share this post


Link to post
Share on other sites


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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

 


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.

0

Share this post


Link to post
Share on other sites

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.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites

 

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.

0

Share this post


Link to post
Share on other sites

 

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! 

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0