Что легче : byte или char?

По занимаемому месту

byte - занимает 8 бит,

char - 16 бит, так как хранит символ Юникода (16-разрядный),

Это без учёта оптимизации. Если смотреть с учётом оптимизации среды C# то будет зависеть от того в каком контексте вы используете эти данные, если просто в стеке их хранить то может и одно и тоже даже место занимать будут, если массив, то byte поменьше будет. Но это ориентировочно, так как оптимизация внутри среды C# может вести себя по-разному на разных платформах, и там не всё документировано.

Но в реальных приложениях, где не нужно выжимать максимум, обычно используется enum для хранения варианта из списка значений, который по умолчанию хранится в памяти как int, но можно настроить и другие варианты хранения, например byte, описание тут. На уровне процессора думаю по скорости скорее всего будет одно и тоже. Но по удобству enum однозначно лучше, так как предоставляет интерфейс для работы с перечислениями.

Добавлено: Перечитал ваш вопрос ещё раз, и понял что у вас в игре эта переменная скорее всего будет один раз храниться, значит по скорости и по объёму памяти разницы не будет никакой. Если только вы не делаете базу результатов матча. Поэтому enum.

Первое правило любых оптимизаций: сначала померяй, потом оптимизируй.

Нет, не так: сначала померяй, потом подумай, а потом уже оптимизируй.

И снова не так: сначала померяй на реальных сценариях с реальными данными, потом подумай, потом попробуй свою оптимизацию, после чего проверь, что изменения играют роль в реальных сценариях с реальными данными и только потом окончательно принимай решение о необходимости той или иной оптимизации.

Теперь к вопросу. Точнее, к ответу:

Нужно использовать enum, поскольку он максимально подходит для перечисления нескольких элементов:

public enum GameState { Play, Lose, Win }

По умолчанию, размер экземпляра этого перечисления будет 4 байта. Но это можно поправить:

public enum GameState:byte { Play, Lose, Win }

Но здесь не все так просто (именно поэтому вначале нужно замерять в реальных условиях).

public class SomeClass
{
   private GameState _state;
   private string _name;
}

В этом случае размер SomeClass будет (64 разрядный .NET): ObjectHeader (16bytes) + 16 bytes. Поскольку будет выравнивание. На 32-х разрядном .NET-е будет 8 + 8.

Тут можно узнать о том, что наш GameState можно положить в структуру и использовать Pack=1, чтобы размер структуры был меньше. Но, почти наверняка это будет экономия на спичках только если число подобных объектов не будет исчисляться миллионами. Но даже если таких объектов миллионы, подобные трюки могут дать просед в скорости исполнения, поскольку доступ к невыровненным полям менее эффективен.

В общем, в качестве заключения: использовать enum, поскольку это то, что разумнее всего использовать для решения этой задачи. И забыть о производительности до тех пор, пока это не станет проблемой и не будет доказано с помощью профайлера.