Return to Answer

• Card games start at turn 1, not 0. Don't mix code-behind indexes and user interface numbers.
• To that end, I would suggest a strict naming convention: Numbers are 1-indexed, indexes are 0-indexed. Which means you need to either rename your field to turnIndex, or rework it to start from 1.
• I wouldn't call nextTurn() at the start of a game (and at the start of a turn), but rather after a turn has completed. This makes more sense semantically (and logically). As a simple example: a for loop doesn't let its index start at -1 and then autoincrements it before iterating the first time. It's counterintuitive behavior.

• Card games start at turn 1, not 0. Don't mix code-behind indexes and user interface numbers.
  • For example, I would consider turnList[oneIndexedTurnNumber-1] more readable than doing the inverse alert("Starting turn " + (zeroIndexedTurnNumber+1))". From a technical perspective, either can be correct, but the first snippet's context (using it as an array index) immediately explains why you're doing -1. The second snippet doesn't immediately explain why you're doing +1 (if you assume that the variable name does not actually contain "zero-indexed", of course).
• To that end, I would suggest a strict naming convention: Numbers are 1-indexed, indexes are 0-indexed. Which means you need to either rename your field to turnIndex, or rework it to start from 1.
• I wouldn't call nextTurn() at the start of a game (and at the start of a turn), but rather after a turn has completed. This makes more sense semantically (and logically). As a simple example: a for loop doesn't let its index start at -1 and then autoincrements it before iterating the first time. It's counterintuitive behavior.

A very minor comment, it's Cthulhu, not Cuthulu. It is phonetically pronounced "Cuthulu" though.

A very minor comment, it's Cthulhu, not Cuthulu. It is phonetically pronounced "Cuthulu" though.

public class Number {  public int Value;    public Number(int value)  { this.Value = value; } } public class Five  { public Five() : base(5)   { } } public class Twenty  {   public Twenty() : base(20)   { } } var myAge = new Twenty(); var fingersOnMyLeftHand = new Five(); 

Number myAge = 20; Number fingersOnMyLeftHand = 5; 

public EnemyUnit CreateDemon(hand, deck) { return new EnemyUnit(10, 100, 10, "#DFB720", "Demon", 7, hand, deck); } public EnemyUnit CreateHellHound(hand, deck) { return new EnemyUnit(5, 60, 5, "#C0C0C0", "Hell Hound", 4, hand, deck); } 

For game design specifically, you'll see that most games tend to not inherit for different unit types, but rather to have a single unit type with omittable properties.
For example, if you have both physical armor and magical armor, you don't need to create separate classes for these. Just give EnemyUnit both PhysicalArmor and MagicalArmor properties, and simply set them to 0 in the current enemy doesn't have that particular type of armor.

class Number { constructor(value) { this.Value = value; } } class Five extends Number { constructor() {  super(5) } } class Twenty extends Number { constructor() {   super(20) } } var myAge = new Twenty(); var fingersOnMyLeftHand = new Five(); 

myAge = Number(20); fingersOnMyLeftHand = Number(5); 

function CreateDemon(hand, deck) { return new EnemyUnit(10, 100, 10, "#DFB720", "Demon", 7, hand, deck); } function CreateHellHound(hand, deck) { return new EnemyUnit(5, 60, 5, "#C0C0C0", "Hell Hound", 4, hand, deck); } 

For game design specifically, you'll see that most games tend to not inherit for different unit types, but rather to have a single unit type with omittable properties.
For example, if you have both physical armor and magical armor, you don't need to create separate classes for these. Just give EnemyUnit both PhysicalArmor and MagicalArmor properties, and simply set them to 0 if the current enemy doesn't have that particular type of armor.