Jump to content



Multiple switches vs if-else conditions

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

#1 lmbarns   Members   -  Reputation: 128

Like
0Likes
Like

Posted Today, 11:21 AM

I'm wondering what's more efficient, using inner switches, or lengthy if-else conditions, if you have 20+ cases which have multiple options for each case?

So I prototyped a menu system for npcs, and I'm trying to figure out if I could do it better. Basically there are potentially more than 20 npcs with dialogue over several levels in the game.

Currently, when you trigger a dialogue from an npc, it calls a function makeMenu(true, npcName, interactionNum){}


Within that function is a switch for the npcName, within the npc's "case:" it has an if-else to check interactionNum and I'm wondering if a second switch would be better, within a switch?

switch(npcName){
case "smith":
	 if(interactionNum == 0){}
	 if(interactionNum == 1){}
	 if(interactionNum == 2){}
	 if(interactionNum == 3){}
break;
case "mage":
	 if(interactionNum == 0){}
	 if(interactionNum == 1){}
	 if(interactionNum == 2){}
	 if(interactionNum == 3){}
break;
//etc repeated 20x
}

Instead of:
switch(npcName){
	 case "smith:
		  switch(interactionNum){
			   case 1:
	 	 	 	 //dialogue 1
			   break;     
	 		  case 2:
	 	 	 	 //dialogue 2
	 		  break;
	 		  case 3:
	 	 	 	 .//dialogue 3
	 		  break;
}
	 case "mage":
	 	 	 switch(interactionNum){
			   case 1:
	 	 	 	 //dialogue 1
			   break;    
	 		  case 2:
	 	 	 	 //dialogue 2
	 		  break;
	 		  case 3:
	 	 	 	 .//dialogue 3
	 		  break;
}
//etc repeated 20x
}


On top of this there are quests in addition to dialogue, and it's on mobile.

Any advice or recommended reading? Thanks

Ad:

#2 6510   Members   -  Reputation: 127

Like
0Likes
Like

Posted Today, 11:31 AM

Don't use ifs or switches for that.
Create some kind of a dialog manager class which gets a game context as input and returns the appropriate dialog.
Store the dialog mapping in some external format so you can add, modify and delete without compiling.

#3 Nyndex   Members   -  Reputation: 101

Like
0Likes
Like

Posted Today, 11:35 AM

Whenever I see a big switch or if-else block I think of the Strategy Pattern

#4 way2lazy2care   Members   -  Reputation: 256

Like
0Likes
Like

Posted Today, 12:01 PM

View Post6510, on 23 May 2012 - 11:31 AM, said:

Don't use ifs or switches for that.
Create some kind of a dialog manager class which gets a game context as input and returns the appropriate dialog.
Store the dialog mapping in some external format so you can add, modify and delete without compiling.
This is probably a better specific solution.

In general, if/else and switch performance varies by language. Generally switches are more readable for cases like this though, and rarely perform any worse than if/else. AVOID STRINGS AS SWITCH KEYS though. Much better to make some sort of enumeration/other uid that can go into the switch somehow. If/else comparisons too for that matter. String comparison can be redonkulously expensive and dangerous.

#5 lmbarns   Members   -  Reputation: 128

Like
0Likes
Like

Posted Today, 12:18 PM

Thanks guys. I'm using C#, and can definitely switch out the strings for an int and just keep track of which npc is which number, or an enum/list of npcs.

I thought about using xml to hold the dialogue but it seems in the switch it wasn't terribly difficult to read/edit.

Currently each npc has a collider, when the player walks close enough and collides with the trigger, it toggles the menu elements and populates them with the text from the switch. I have a GUI layout of buttons/background/text placeholders which are toggled off in a Start() function, then when the player triggers a menu it enables the proper elements and updates their content. Then if the player touches "read more" button, it increments a pageNum variable, and re-calls the same function passing itself as the argument, and the incremented pageNum gets caught in an if() conditional and overwrites the text with the next page of dialogue and enable/disables any other buttons/icons available.

This is what the prototype looks like:








We are working on generating results for this topic
PARTNERS