Ещё из не самых заметных, но очень важных достижений: практически всё, что касается баланса (хит-пойнты, урон, скорость, скорострельность, ускорение, размер хит-бокса, небо, аллах), вынесено в JSON-файл, где это дело можно править, не лазая в исходный код.
https://freesound.org - тут можно поискать звуковые эффекты. ^_^
Комментарий недоступен
Не, можно и потопить. Плюсы в 80-ых/90-ых, насколько я знаю, были стандартом во всей отрасли, когда дело касалось ООП и вообще всякого энтерпрайза. А в геймдеве это стандарт, который держит свои позиции до сих пор. Всё-таки скорость выполнения решает. Если бы не запредельная сложность языка (плюсы) и не запредельная низкоуровневость (чистый си), то цены б им не было. А, ну ещё и синтаксис чуть-чуть нечеловеколюбивый. Но к этому мы уже привыкли и в другие производные языки потащили, вплоть до Джаваскрипта.
Комментарий недоступен
А можно узна́ть зачем в играх юнит тесты?
Я как бы понимаю что если игра онлайн, то сервер может отрубится и клиент начнет работать не правильно. И что бы не искать ошибок там где их нет есть вот такие тесты.
Но вот для офлайновых игр, особенно для определения столкновения по пикселям, не совсем понятно. Ведь пишеш функцию, она работает, если переменные изолированы в ней то все, она всегда будет работать, зачем юнит тесты в таком случае?
А как ты ещё проверишь те же столкновения? Чисто на глаз? Чисто на всякий случай: под юнит-тестами понимается код, которые проверяет небольшие части другого кода. И вот для того, чтобы проверить, что код столкновений работает правильно, как ты не распологай два хит-бокса, юнит-тесты идеальны. Ещё один случай: убедиться, что перезарядка работает правильно даже в тех случаях, когда у нас пять-десять кадров в секунду. Да и просто убедиться, что важные тебе части кода работают правильно, перед тем, как их использовать, явно будет не лишним.
Тесты пишутся зачастую, чтоб потом легко можно было понять, что и где отвались при изменениях. Почитайте про регрессионное тестирование.