Return to Answer

Your idea

Your idea is nice, but it will cause problems when extending the game. For example, we will add spock and lizard:

var spock = ["spock", "paper", "lizard", "scissors", "rock"];

Now, index 1 and 2 mean p1Loss, and index 3 and 4 mean p1Win. This can easily cause bugs in the future.

Maybe a better idea

You could instead maintain arrays that say what items beat. For example:

var spockBeats = ["scissor", "rock"];

Then, check at the beginning if the input of the users is equal, return "tie" if it is. If it is not, find the appropriate array for user1 (I would use a switch instead of many if-else) and see if it contains the choice of user2.

In this case, extending the game is easier. New item? Add a new array and a new switch option, and add the item to some of the other arrays.

In case you really want to extend the game (I mean like adding a couple dozen or more options), this approach too would become somewhat annoying. In that case you might want to read up on graph theory, as this is basically just a directed graph. I think that an adjacency matrix might work well then.

For rock, paper, scissor, the matrix would look like this:

   R  P  S
R  0 -1  1  
P  1  0 -1
S -1  1  0

And you use it like this: Player1 plays paper, Player2 plays rock. Look in the paper row for the value under rock. it is 1 and player1 wins. -1 would mean they lose, and 0 means tie. For just rock, paper, scissors this is overkill, but for a lot more options this might work well.

Comments on current code

• I would save the strings (rock, paper, scissors) in fields at the top of the file. It's an easy source of bugs because of typos
• I would return which player won, not with what choice they won. Or both, but the current way seems just odd to me

Your idea

Your idea is nice, but it will cause problems when extending the game. For example, we will add spock and lizard:

var spock = ["spock", "paper", "lizard", "scissors", "rock"];

Now, index 1 and 2 mean p1Loss, and index 3 and 4 mean p1Win. This can easily cause bugs in the future.

Maybe a better idea

You could instead maintain arrays that say what items beat. For example:

var spockBeats = ["scissor", "rock"];

Then, check at the beginning if the input of the users is equal, return "tie" if it is. If it is not, find the appropriate array for user1 (I would use a switch instead of many if-else) and see if it contains the choice of user2.

In this case, extending the game is easier. New item? Add a new array and a new switch option, and add the item to some of the other arrays.

In case you really want to extend the game (I mean like adding a couple dozen or more options), this approach too would become somewhat annoying. In that case you might want to read up on graph theory, as this is basically just a directed graph. I think that an adjacency matrix might work well then.

For rock, paper, scissor, the matrix would look like this (it contains duplicate information, but I don't think that memory is a concern and removing it would make it harder to use):

   R  P  S
R  0 -1  1  
P  1  0 -1
S -1  1  0

And you use it like this: Player1 plays paper, Player2 plays rock. Look in the paper row for the value under rock. it is 1 and player1 wins. -1 would mean they lose, and 0 means tie. For just rock, paper, scissors this is overkill, but for a lot more options this might work well.

Comments on current code

• I would save the strings (rock, paper, scissors) in fields at the top of the file. It's an easy source of bugs because of typos
• I would return which player won, not with what choice they won. Or both, but the current way seems just odd to me

Your idea

Your idea is nice, but it will cause problems when extending the game. For example, we will add spock and lizard:

var spock = ["spock", "paper", "lizard", "scissors", "rock"];

Now, index 1 and 2 mean p1Loss, and index 3 and 4 mean p1Win. This can easily cause bugs in the future.

Maybe a better idea

You could instead maintain arrays that say what items beat. For example:

var spockBeats = ["scissor", "rock"];

Then, check at the beginning if the input of the users is equal, return "tie" if it is. If it is not, find the appropriate array for user1 (I would use a switch instead of many if-else) and see if it contains the choice of user2.

In this case, extending the game is easier. New item? Add a new array and a new switch option, and add the item to some of the other arrays.

In case you really want to extend the game (I mean like adding a couple dozen or more options), this approach too would become somewhat annoying. In that case you might want to read up on graph theory, as this is basically just a directed graph. I think that an adjacency matrix might work well then.

Comments on current code

• I would save the strings (rock, paper, scissors) in fields at the top of the file. It's an easy source of bugs because of typos
• I would return which player won, not with what choice they won. Or both, but the current way seems just odd to me

Your idea

Your idea is nice, but it will cause problems when extending the game. For example, we will add spock and lizard:

var spock = ["spock", "paper", "lizard", "scissors", "rock"];

Now, index 1 and 2 mean p1Loss, and index 3 and 4 mean p1Win. This can easily cause bugs in the future.

Maybe a better idea

You could instead maintain arrays that say what items beat. For example:

var spockBeats = ["scissor", "rock"];

Then, check at the beginning if the input of the users is equal, return "tie" if it is. If it is not, find the appropriate array for user1 (I would use a switch instead of many if-else) and see if it contains the choice of user2.

In this case, extending the game is easier. New item? Add a new array and a new switch option, and add the item to some of the other arrays.

In case you really want to extend the game (I mean like adding a couple dozen or more options), this approach too would become somewhat annoying. In that case you might want to read up on graph theory, as this is basically just a directed graph. I think that an adjacency matrix might work well then.

For rock, paper, scissor, the matrix would look like this:

   R  P  S
R  0 -1  1  
P  1  0 -1
S -1  1  0

And you use it like this: Player1 plays paper, Player2 plays rock. Look in the paper row for the value under rock. it is 1 and player1 wins. -1 would mean they lose, and 0 means tie. For just rock, paper, scissors this is overkill, but for a lot more options this might work well.

Comments on current code

• I would save the strings (rock, paper, scissors) in fields at the top of the file. It's an easy source of bugs because of typos
• I would return which player won, not with what choice they won. Or both, but the current way seems just odd to me

Your idea

Your idea is nice, but it will cause problems when extending the game. For example, we will add spock and lizard:

var spock = ["spock", "paper", "lizard", "scissors", "rock"];

Now, index 1 and 2 mean p1Loss, and index 3 and 4 mean p1Win. This can easily cause bugs in the future.

Maybe a better idea

You could instead maintain arrays that say what items beat. For example:

var spockBeats = ["scissor", "rock"];

Then, check at the beginning if the input of the users is equal, return "tie" if it is. If it is not, find the appropriate array for user1 (I would use a switch instead of many if-else) and see if it contains the choice of user2.

In this case, extending the game is easier. New item? Add a new array and a new switch option, and add the item to some of the other arrays.

Comments on current code

• I would save the strings (rock, paper, scissors) in fields at the top of the file. It's an easy source of bugs because of typos
• I would return which player won, not with what choice they won. Or both, but the current way seems just odd to me

Your idea

Your idea is nice, but it will cause problems when extending the game. For example, we will add spock and lizard:

var spock = ["spock", "paper", "lizard", "scissors", "rock"];

Now, index 1 and 2 mean p1Loss, and index 3 and 4 mean p1Win. This can easily cause bugs in the future.

Maybe a better idea

You could instead maintain arrays that say what items beat. For example:

var spockBeats = ["scissor", "rock"];

Then, check at the beginning if the input of the users is equal, return "tie" if it is. If it is not, find the appropriate array for user1 (I would use a switch instead of many if-else) and see if it contains the choice of user2.

In this case, extending the game is easier. New item? Add a new array and a new switch option, and add the item to some of the other arrays.

In case you really want to extend the game (I mean like adding a couple dozen or more options), this approach too would become somewhat annoying. In that case you might want to read up on graph theory, as this is basically just a directed graph. I think that an adjacency matrix might work well then.

Comments on current code

• I would save the strings (rock, paper, scissors) in fields at the top of the file. It's an easy source of bugs because of typos
• I would return which player won, not with what choice they won. Or both, but the current way seems just odd to me