webdonsk.ruКак сделать игру в си шарп
Добавил пользователь Алексей Ф. Обновлено: 21.08.2024
- Определение логики (бизнес логика)
- Проектирование архитектуры
- Реализация игры
- Написание тестов
По хорошему пункты 4 и 3 нужно поменять, но т. к. мы захотим (а мы захотим) менять требования решено делать в таком порядке.
Для начала подумаем, что мы хотим получить от этой игры. Определимся с тем, что это будет пошаговая Role Playing Game. Большинство современных игр RPG предоставляют своим пользователям различные классы персонажей, деревья умений и др. Мы начнем с одного класса персонажа. NPC вводить не будем (это не влияет на общую архитектуру игры и упростит разработку). Также не будем реализовывать игровой мир, но в разработанной системе это сделать будет не сложно. А в качестве бонуса реализуем бота! Бот должен будет подсказывать игроку, какой ход он думает оптимальный. Опишем некоторые правила и информацию об игре.
Игрок
- Здоровье
- Максимальное здоровье
- Сила
- Монеты
- Предметы
Возможные действия
- Сразиться с монстром
- Покупка оружия
- Покупка брони
- Лечение
Попробуем разделить логику игры от логики представления. С оговоркой, что это не клиент серверное приложение и для упрощения некоторых моментов сознательно упрощаем реализацию. С характеристиками персонажа и возможными действиям разобрались, приступим к проектированию архитектуры. Общая архитектура сборок будет следующей:
Разделим логику на: представление и движок. Сборка для конфигурации игры вынесена отдельно. В следующей части мы рассмотрим разработку сборки GameConfig, как единственной сборки без зависимостей (да и одну из первых сборок в игре). В ней находятся модели настроек игры и некоторые адаптеры.
Небольшой спойлер, как будет выглядеть игра в конце:
Если у вас после прочтения и изучения исходного кода появились вопросы или комментарии буду очень признателен.
Проектирование шутера начинается с разработки сценария, после чего определяются классы (поля и методы), проектируется визуальный интерфейс игры, программируются методы этих классов.
Возможный сценарий игры
Место действия. Сражение происходит в космическом пространстве в окрестностях Земли.
Противник. НЛО имеют традиционную форму тарелок, каждая из них отличается размерами и окраской. Над Землей они появляются сериями и планируют сверху вниз на Землю с различной скоростью, при этом возможно и их горизонтальное смещение. Интервал времени между появлениями серий может уменьшаться. Количество НЛО в небе одновременно не превышает некоторого максимального числа — количество НЛО в космическом флоте противника.
Игрок. Игрок, находясь в своем корабле, использует свое оружие с лазерным прицелом (blaster) и перемещается в околоземном пространстве, старается сбить НЛО противника. Для управления перемещением игрока используется мышь, стрельба — нажатием левой кнопки мыши.
Взаимодействие. При попадании в НЛО следует обозначить его подрыв и удалить его останки из околоземного пространства. В первом приближении будем считать, что физическое касание НЛО и корабля не приводит к потере корабля игрока (это будет следующая задача).
Цель игры — уничтожить максимальное количество НЛО противника (максимальный результат — 100%).
Проектирование классов
Класс Player
Поля класса:
public Point point; // положение игрока в 2D-пространстве
public Size size; // размеры игрока
public Region reg; // занимаемая им область в пространстве
public Pen laser_pen; // свойство оружия
Методы класса:
public void New_player() // задать свойства (параметры) игрока
public void Show_player() // показать его на поле битвы
Содержание методов этого и последующих классов рассмотрим позднее.
Класс Bugs
Поля:
public Point point; // положение НЛО в 2D-пространстве
public Size size; // размеры НЛО
int veloX; // скорость смещения по X
int veloY; // скорость_падения по Y
public HatchBrush br; // кисть для покраски НЛО
public Region reg = new Region(); // занимаемая им область в пространстве
public Boolean life = true; // НЛО жив (true) или мертв (false)
Методы:
public void New_bug() // задать свойства (параметры) НЛО
public void Form_bug() // задать форму НЛО, например, тарелку
public void Move_bug() // задать новое местоположение НЛО
Класс Enemies
Вспомогательный класс BrushColor
Поля класса:
public Color FonColor; // цвет фона
public Color LaserColor; // цвет лазера
public Color DashBug; // цвет штриховки НЛО
public Color KilledBug; // цвет сбитого НЛО
Методы класса:
public BrushColor() // конструктор (настройка цветов)
public HatchBrush New_br(int rch) // кисть для задания цвета НЛО
public Color RandomColor(int rch) // генератор случайного цвета
Класс Form1
Методы класса Form1 (реакции на события):
а) конструктор формы
public Form1()
б) при загрузке формы
private void Form1_Load(object sender, EventArgs e)
в) старт игры
private void button1_Click(object sender, EventArgs e)
г) включение/отключение лазера
private void button2_Click(object sender, EventArgs e)
д) стоп игры, результат
private void button3_Click(object sender, EventArgs e)
е) один временной такт игры
private void timer1_Tick(object sender, EventArgs e)
ж) генерация серий
private void timer2_Tick(object sender, EventArgs e)
3) попадание НЛО под вертикальный обстрел лазером
private void Form1_MouseClick(object sender, MouseEventArgs e)
Настройка объектов
Для использования полного экрана зададим свойство Form1.WindowState=Maximized.
Подготовим в графическом редакторе изображения игрока размером 100х100 пикселей с именами player.bmp и player1.bmp, например так:
и сохраним их в папке Resourсes проекта. Зададим свойство imageList1.ImageSize = 100;100 и внесем в коллекцию imageList1.Images эти два файла (члены 0 и 1)
Изображения НЛО будет генерировать метод public void Form_bug().
Настройки таймеров:
timer1.Enable=false (выключен);
timer2.Enable=false (выключен);
timer1.Interval=400 (0,4c);
timer2.interval=5000 (5c).
Исходный вид формы (в том числе с не визуальными компонентами) представлен ниже:
Вместо кнопок можно задать меню из трех позиций: Старт, Лазер, Стоп. Соответственно сменятся и названия методов, связанных с выбором пунктов меню.
Реализация методов класса Player:
Комментарии: Размер изображения определяется через размер рисунка (см. далее метод Form1_Load() ). Левый верхний угол объекта имеет координаты (0,0). Область, занимаемая игроком, прямоугольная. Цвет луча лазера определяется свойством F.bc.LaserColor. Для доступа к объекту bc, расположенному на форме, параметр метода задаем как Form1 F.
б) показать игрока
Комментарии: Метод имеет параметры: Form1 F (для доступа к объекту g и свойству BackColor – цвету фона), int x, int y — новые координаты игрока (x – ось симметрии). Первый оператор снимает защиту с предыдущей области расположения игрока. Также определяется новая область reg. Метод DrawImage(F.imageP, point) обеспечивает рисование игрока, метод ExcludeClip(reg) обеспечивает защиту заданной области до следующего вызова метода. Совет: Уберите первый и последний операторы и посмотрите на изменения в отображении игрока.
Реализация методов класса Bugs
а) генерация одного НЛО
Комментарии: Метод формирует начальные координаты НЛО, его размеры, скорости смещения за 1 такт срабатывания таймера timer1, выбирает цвет кисти для его покраски. Везде используется генератор случайных чисел класса Random. Для задания области reg вызывается следующий метод.
б) задание формы НЛО
в) вертикальное падение НЛО с горизонтальными смещениями
Комментарий: новая область размещения НЛО заполняется на каждом такте срабатывания таймера 1 после изменения координат через метод Form_bug().
Реализация методов класса Enemies
а) настройка серий и создание ссылок на объекты НЛО
Комментарии: В методе задается жестко число серий — 10. Вычисляется число НЛО в каждой серии. Обнуляется счетчик числа генераций (серий) и числа активных НЛО. Создаются ссылки на максимально возможное число объектов.
б) удаление сбитых НЛО
в) смещение и отображение НЛО
Комментарий: Метод в цикле для активных НЛО обеспечивает их смещение и отображение на экране.
г) одна серия НЛО
Комментарий: Метод добавляет новую серию НЛО, каждый из которых имеет свой цвет, размеры и начальное местоположение.
д) подбитые НЛО, выделены F.bc.KilledBug цветом
Комментарий: проверяет попадание объектов под лазерный прицел, отмечает их в свойстве life как false, обеспечивает вспышку НЛО при подрыве.
Реализация методов класса BrushColor
а) кисть для задания цвета НЛО
Комментарий: Метод возвращает кисть класса HatchBrush (шаблон штриховки) из библиотеки System.Drawing.Drawing2D, состоит из одного оператора.
б) случайный цвет
Комментарий: этот метод мы уже использовали ранее в других примерах.
Реализация методов класса Form1
а) конструктор формы
Комментарий: без изменений.
б) при загрузке формы
г) Включение/отключение лазера игроком
Комментарий: включение/отключение лазера игроком
д) Стоп. Результат
е) один временной такт
ж) генерация серий
Комментарии: Увеличение номера серии на 1, сокращение на 100 мс интервала выпуска следующей серии, если реализованы все nlo.N_generation, то остановка генерации ( timer2.Stop();) , иначе генерация очередной серии.
з) попадание НЛО под вертикальный обстрел лазером
Комментарии: И, наконец, последний самый главный метод, вызываемый при клике на форме, обеспечивает показ игрока в заданном мышью положении, выстрел из оружия, отметка подбитых НЛО, вспышки при их подрыве.
Интересно, что событие MouseClick демонстрирует взаимодействие объектов трех классов: Form1, Player и Enemies, а опосредовано и всех пяти (+ Bugs и BrushColor).
Развитие игры
Опираясь на пример игры, постарайтесь ее развить.
Например, чтобы столкновение игрока с НЛО приводило к уменьшению счета игры вплоть до ее остановки при ранениях, несовместимых с жизнью игрока.
Другое направление — изменение способов задания объектов, используя базы данных и/или файлы.
Третье направление — изменение траекторий движения, как игрока, так и противников.
Четвертое направление — добавление нового вида (класса) противников, отличающихся от безобидных пока НЛО, после чего создайте для них общий класс, от которого они будут наследоваться (принцип наследования).
Не забывайте и про принцип полиморфизма, пусть методы родственных классов называются одинаково, а действуют по-разному.
Во-первых, я не буду повторять документацию иными словами.
Во-вторых, необходимо знание программирования, чтобы понять о чем я пишу.
К сожалению, эта статья не сможет вам помочь, если вы хотите создать свою казуальную игру используя лишь мышь.
Зато я шаг за шагом расскажу о создании движка, на котором будет работать игровая логика нашей экономической стратегии.
Для тех, кто любит спойлеры или просто хочет почитать код — в конце есть ссылка не репозиторий, где каждый пункт добавлен отдельным коммитом.
Кого заинтересовало узнать, что за игра — внизу есть видео и ссылка на бесплатное скачивание.
Краткое описание GD, которого мы хотим достичь
1. Игрок управляет кораблем. В корабле можно выстраивать комнаты, в комнатах можно добавлять в слоты модули.
2. Для постройки чего-либо необходимо потратить ресурсы и подождать время.
Через полгода разработки результат должен выглядеть как-то так)
План работы
1. Настраиваем проекты
2. Создаем ядро — базовые сооружения
3. Добавляем и тестируем первые команды — построить строение и модуль
4. Выносим настройки строений и модулей в отдельный файл
5. Добавляем течение времени
6. Добавляем Constructible, строения теперь строятся некоторое время
7. Добавляем ресурсы, для постройки необходимы ресурсы
8. Добавляем цикл производства — модуль потребляет и выдает ресурсы
Статья получилась очень объемной, потому пришлось разделить ее на две части. В данной части мы сделаем первые пять пунктов, а во второй части закончим
1. Настраиваем проекты
2. Создаем ядро — базовые сооружения
Что ж, это указывает, что настроили мы корректно и можно переходить к программированию логики.
Итак, разберемся с нашим гейм-дизайном. У нас есть корабль (Ship), в нем комнаты (Room), в каждую комнату может быть построено строение (Building), а в каждом строении могут быть модули (Module). Конечно, Room и Building можно было бы объединить в одну сущность, но далее такое разделение нам только поможет.
Для всех этих сооружений я создам отдельный namespace Architecture и базовые классы. А так же enum для индексов комнат. Многие вещи, которые мы сейчас делаем — временные и необходимы, чтобы запустить первый тест гейм-логики.
3. Добавляем и тестируем первые команды — построить строение и модуль
И хотя сейчас даже такая маленькая структура излишня — чуть позже благодаря ей мы прикрутим необходимые нам события. А существование каждого атомарного действия в отдельной команде позволит нам их комбинировать. Напишем наши первые два действия:
Пришло время посмотреть, работает ли наш движок. В тестах создаем ядро, пробуем построить комнату, а в нее пытаемся построить модуль. Кроме этого стоит добавить проверку, что нельзя построить то, чего гейм-логика не должна позволять строить:
4. Выносим настройки строений и модулей в отдельный файл
К счастью, наши тесты прекрасно проходятся. Теперь нам необходима возможность линейно расширять количество строений и модулей — для этого необходимо сделать следующее:
- Создать конфигурацию для строений и модулей — " class BuildingConfig " и " class ModuleConfig ", именно они будут хранить все настройки наших сооружений.
- Building и Module при создании должны принимать соответствующие настройки
- Сделать фабрику для создания модулей и строений
- Добавить настройки для нескольких строений и модулей
- Адаптировать существующий код под новые входные данные
Как можно понять, теперь наш код нерабочий. Для того, чтобы не таскать каждый раз с собой конфиги создадим фабрику, которая будет выпускать наши сооружения зная только их тип. Я знаю, что название пока слишком общее, но мы всегда с легкостью можем его переименовать благодаря IDE, так же, как и разделить на две фабрики:
И хотя сейчас код корректен — при запуске наших тестов мы словим "Not implemented yet" . Для этого вернемся к нашей фабрике и реализуем несколько строений и модулей.
Я сразу добавил несколько строений и модулей, чтобы можно было покрыть тестами. И сразу скажу — да, хранить все эти настройки в фабрике нету никакого смысла. Они будут лежать отдельно в JSON файлах, по одному на структуру, парсится и передаваться в фабрику. К счастью, у нас движок даже не заметит этого изменения. Ну а пока нам не так критично вынести их в ЖСОНы, как запустить тесты и проверить все ли корректно работает. К счастью, да. Заодно допишем тесты, что нельзя построить модуль не в той комнате, например, Furnace в PowerPlant.
Увы, как вы можете догадаться, никто логику проверки не писал. Добавим условие валидации в команду постройки модуля и после этого успешно пройдем тест:
Что ж, теперь все корректно. Заодно добавим тесты на корректную работу лимитов и пойдем дальше.
5. Добавляем течение времени
Компьютеры дискретны. И все игры дискретны. Если говорить просто, то представим, что все игры — пошаговые. У большинства игр шаги пропускаются автоматически и 60 раз в секунду. Такие игры называются риалтайм. Я понимаю, что это очень грубо, но для реализации гейм-логики довольно удобно представлять, что ваша игра — пошаговая и мыслить такими категориями. А потом уже на клиенте можно запустить tween между двумя состояниями и юзеру будет красиво и игра будет работать быстро. Для начала введем понятие хода:
А также введем команду, которая позволяет переключать хода. Я сразу добавил команду, которая позволяет переключить несколько ходов — будет довольно удобно во время тестирования. В тестах одним выстрелом покроем сразу двух зайцев.
Забегая далеко вперед напишу, как сделать переключалку скоростей в игру, которая позволит нам запускаться с разной скоростью:
Теперь в Unity достаточно будет подвесится на любой Update и передавать дельта время в наш TimeWarp:
Продолжение следует.
В следующей статье мы закончим создание работоспособной основы для нашего движка, реализовав следующие пункты:
6. Добавляем Constructible, строения теперь строятся некоторое время
7. Добавляем ресурсы, для постройки необходимы ресурсы
8. Добавляем цикл производства — модуль потребляет и выдает ресурсы
Для тех, кто просто любит код — есть отдельный репозиторий на ГитХаб
Кроме этого, если вас интересуют вопросы по разработке SpaceLab — задавайте, отвечу на них в комментариях или в отдельной статье
C Sharp скачать программу бесплатно
ВТОРАЯ ЧАСТЬ:
Полные и новые версии первой части:
Проверено Kaspersky:
Угрозы не обнаружены.
Скачивайте на GameJolt!
Теперь доступно на Itch.io
Пробные и тестовые версии:
Инструкция к C Sharp редактору:
Описание и среда разработки CS Maker
Отладка скрипта CSharpMaker
+ задачи по программированию c sharp
Отладка скрипта!
C Sharp Maker может также проводить отладку кода. Она проверяет весь скрипт на наличие ошибок или на неправильное местоположение блока. В таких случаях программа C Sharpmaker выделяет их красным цветом!
Отзывы о программе и видео-уроках по ней:
Артём Стрыгин
Не программа, а сказка! …
BeZZuBiK Фурия
Wow Games, огромнейшее спасибо за такое полезное видео! Оно мне реально помогло. …
-ENERGI
Годно, особенно озвучка:)
C Sharp Maker пример кода:
Новый вид программы (Тёмная тема с большим разрешением окна!)
Насколько удобен C sharp для разработки игр? Причем не в контексте использования с юнити, а просто? Есть ли какие-то известные игры, где c sharp используется в качестве основного языка при разработке?
Я в этом слабенький, но слышал, что для игр лучшим является с++
ты в этом слабенький
Я в этом слабенький
но слышал, что для игр лучшим является c++
Ты в этом слабенький
Андрюха, у нас тут infinite loop, возможно memleak, по коням!
бля, затыкай скорее, мемы утекут
ты в этом слабенький
но я слышал, что для игр лучшим является c++
Смотря что ты подразумеваешь под разработкой игр? Наверно, для инди подойдет, но опять же нафига писать свой движок, если есть куча готовых. Если хочется сделать что-то серьезное, то тогда С++\С. Если говорить про создание игр в одиночку, то написание собственного движка это пустая трата времени.
>Если хочется сделать что-то серьезное, то тогда С++\С.
Плюсы на нормальном уровне гораздо сложнее в изучении, насчет си не знаю.
Разработка инди игр это не про движки, а про геймплей, дизайн и т.д.
Не понял, что вы хотите сказать?
Он думает что ты будешь движок писать
Зачем мне это? Я типичный индюк.
Вам надо выбрать какой-то готовый популярный простой движок, который вы сможете быстро изучить и начать делать свой проект. Обычно в этих движках есть свой какой-то скриптовый язык, который можно выучить за неделю. Фактически через пару недель изучения мануалов вы можете делать свой проект.
Я не хочу быстро сделать что-то. Хотел бы - взял бы что-нибудь типа intersect engine. Мне нужны реальные навыки. Я не из тех, кто хочет чтоб быстро и без напряга, могу читать gof, если надо.
Писать игру на шарпе с нуля - это примерно так же связано с реальными навыками, как очумелые ручки - с работой конструктора на заводе.
Максимум что получится - тормозящий на всем майнкрафт.
И тем не менее, это - интересный опыт.
Мне кажется это и есть реальные навыки. Берете готовый и простой движок с хорошим мануалом, быстро изучаете его и приступаете к созданию собственной игры. В своё время ковырялся с cocos-2dx, qt и т.д. В конечном итоге остановился на defold. Простой и есть всё что надо.
Это реальные навыки не только в геймдеве. В любой отрасли главное - максимально быстро получить готовый продукт, и купить обычно дешевле, чем разрабатывать.
Комментарий удален по просьбе пользователя
Комментарий удален по просьбе пользователя
Блять, В юнити вообще нельзя делать 2д игры, лол. Это 3д движок. 2д игры на юнити - это 3д игры с плоскими модельками и зафиксированной камерой.
Внутренний метод рендера никак не влияет на то, что потребитель играет в 2Д игру и воспринимает её как двухмерную.
Мы тут про движки, или про восприятие игрока? Любая игра на юнити кажущаяся игроку двухмерной на самом деле трехмерная с фиксированной камерой.
Про пайплайн, в котором геймдиз дизайнит 2Д игру, а художники рисуют 2Д-спрайти и 2Д-задники, приправленные 2Д-эффектами. Каким образом программер отрисовал всё это 2Д на экране - это уже его личное дело, остальные участники команды могут вообще быть не в курсе насчет этого "внутреннего 3Д".
Мы в данной теме обсуждаем именно движки, способы работы с ними и т.п. Что ты вломился то, геймдезигнер.
Твой нелепый вброс с откровениями насчет 3Д привлек внимание. Что ты этим пытался доказать, художник?
Если мне понадобится мнение людей максимально далеких от темы, и ничего в ней не понимающих, я тебя тэгану. Пока свободен.
Просто твоя безграмотность лишь народ в заблуждение вводит. 2Д-игра в Юнити - это не просто 3Д с далеко стоящей камерой, как тебе могло казаться из-за незнания матчасти или катастрофически устаревших данных, это именно отдельный режим, в котором Z-координата объекта вообще нихрена не значит, ибо порядок отрисовки определяется либо указанием слоя и позиции в оном в случае спрайтрендера, либо положением в иерархии канваса в случае юайного элемента. Так что тебе ни на минуту не позволяют забыть, что ты работаешь именно в 2Д и это двухмерная игра. Если ты и сейчас не понял, поясню на примере - в сцене объект находится дальше всех, а отрисовывается поверх всех, потому что на координату глубины движку наплевать, она в 2Д игре не учитывается. Такая-то трехмерность.
Это какое-то нововведение последнего времени похоже, 90% извеестных платформеров на юнити написано еще до этой хуиты. И для UI обычно используют сторонние библиотеки.
Sprite Renderer - Компонент Sprite Renderer позволяет вам отображать изображения в виде спрайтов(Sprites), чтобы использовать их и в 2D и в 3D сценах.
Ну хз, по моему очевидно, что это просто обрезанный 3d объект, что бы было удобнее.
Вот поэтому я и сказал, что твои данные катастрофически устарели. 2Д уже давно совершенно отдельный режим, не требующий адских извращений для имитации двухмерности, которыми страдали в первых версиях Юнити.
Но в любом случае мудак выше - не прав. Юнити подстраивается под разработчиков, но сам по себе это никак не "движок для мобильных 2д платформеров".
Огромное количество корявых поделок сослужило ему плохую службу, создав подобный имидж - такова цена доступности и популярности. И да, дело не в самом движке, а в толпах рукожопов и жадных аферистов, которым плевать на качество продукта и оптимизацию. Они бы так любому движку репутацию испортили - но Юнити был первым из доступных такого уровня, потому и принял на себя удар. Не уверен, что стоит вообще браться кого-то переубеждать, разбирающиеся в вопросе люди и сами знают, что к чему - а не разбирающиеся пускай и дальше по городским мифам ориентируется :)
Почитал про 2д режим, да, 2-3 года назад даже намека на это не было. Был всратый UI, котоырм никто не пользовался, и все.
Ну вообще этот режим с 2013 года доступен, если память не изменяет - так что скорее лет шесть уже прошло, достаточно давно ввели.
Может быть, может им просто никто не пользовался, хз.
Комментарий удален по просьбе пользователя
Не пробовал, так что деталей не знаю - но знакомый художник лепил прототипы игр в Анриле не будучи программистом, и утверждал, что тамошняя система визуального программирования позволяет клепать игры из ассетов гораздо легче и удобнее, чем в Юнити.
Комментарий удален по просьбе пользователя
Возможно есть какие-то нюансы лицензирования - а может просто так повелось, что Юнити первый ответ на все вопросы по движкам в случае инди-разработки. Ну, сложилось так исторически.
Комментарий удален по просьбе пользователя
Комментарий удален по просьбе пользователя
Это связано с политикой лицензирования юнити. Крупные ААА издатели не готовы отдавать сколько то там процентов с каждой проданной копии игры.
Большая популярность юнити среди мобильных и инди игр говорит прежде всего о лучшей архитектуре и скорости, позволяющие добиться максимального быстродействия на любых платформах при минимальном вложении средств в разработку.
Это так же видно на примере не слишком высокобюджетных 3д игр на ПК (выше перечислил) Подобный сегмент на анриле как правило работает намного хуже.
Комментарий удален по просьбе пользователя
А чем разработка игр на юните не является реальными навыками?)
Комментарий удален по просьбе пользователя
Не, понятно, что из-за своей специфики Unity для AAA не используют.
Но блядь, на нем сделаны Subnautica, Cities Skylines, Beat Saber, Risk of Rain 2, Ori and the Blind Forest и ещё куча хороших игр.
Комментарий удален по просьбе пользователя
Потому что шарп проще плюсов. И не надо мне рассказывать сказки про блюпринты.
Комментарий удален по просьбе пользователя
Unity . ничего не выйдет на свет у этого второсортного движка
Unreal Engine . на блюпринтах можешь посидеть
Комментарий удален по просьбе пользователя
Возможно, что потолок по графону у анрила выше, но если ты не мегакорпорация с многомиллионными (в долларах) бюджетами - получится у тебя на анриле глючная тормозная херня.
Комментарий удален по просьбе пользователя
Выше - экспертное мнение человека, который считает Unity - 2d движком.
Комментарий удален по просьбе пользователя
Крупные компании прекрасно разрабатывают игры на Unity.
Комментарий удален по просьбе пользователя
Стратегии серии Endless, Life is Strange: Before the storm, Colin mcRay rally 2013го года, Cities: Skylines, Furi, Wasteland 2, Praey for the Gods, Escape from Tarkov
Это все мобилки?
Комментарий удален по просьбе пользователя
Смелое заявление. Посмотри хотя бы на Ori, который там в blind forest и well of wisps в след году
Комментарий удален по просьбе пользователя
Платформеры не игры 2019го года)
А что можно назвать играми 2019 года с таким подходом? Все жанры вроде старые.
Комментарий удален по просьбе пользователя
"Вызывание восторга" - это какая-то слишком субъективная оценка, вкусовщина. Примеров подобных "игр 2019 года" не будет, насколько я понимаю, ибо всё уже старое.
Комментарий удален по просьбе пользователя
Ты вообще в хеллблейд играл? Что он там нового привнес? Мне очень нравится эта игра, но там нет никаких новых механик, да и старые не самве лучшие. Ладно пубг еще что-то новое сделал, и то, идея баттл рояля не нова. Исходя из твоей логики, фортнайт вообще на нем паразитирует.
В общем-то твое мнение понятно, спасибо.
Не только про него. Юнити предназначен для создания игр. На нем можно сделать как отстой, так и хорошую игру. Все зависит от желания и умения разработчика.
Комментарий удален по просьбе пользователя
Если хочется сделать игру - берёшь готовый движок
Хочется просто кодить по хардкору - c++
я как системный программист с опытом 10 лет, хочу заметить что недостатком шарпов является сборщик мусора, в остальном он ничем не хуже схх. если память использовать аккуратно вы ничего не выйграете. в остальном шарпы новее чем убогий схх. хотите системного хардкора учите D или RUST.
Да да, а еще у твоих программ на плюсах никогда, НИКОГДА не течет память. Сборщик мусора - основной плюс шарпа перед плюсами.ж
в плюсах какраз память охуенно иожет течь, и гц кокраз создавался для того чтоб не текло. чтоб ты знал malloc тоже страницами память забирает, и говнокодом положить его гораздо проще чем gc. в 99% игры используют данные размешенные на стеке и тут у схх и шарпов паритет, в отличие от явы.
Комментарий удален по просьбе пользователя
Там всего-лишь простенький счётчик ссылок
Мне кажется в современном мире геймдева нужно выбирать не язык программирования, а подходящую среду\платформу\движок.
Бредовый какой то вопрос, если делаете игру на юнити там апи на основе сишарпа. Смысл вообще спрашивать про сишарп без привязки к движку.
В целом, лучше использовать Unity.
Дратути net core
А, забыл. Производительность у него средняя. Простенькие проекты вполне выдержит. Выдержит и по-сложнее. Но всякие физические симуляторы или игры с ААА-графикой - это не сюда уж точно.
вы о ком говорите? юнити как двиг написан на схх и просто менее оптимизирован и надрочен чем унреал, никаких недостатков у шарпов в геймдеве перед схх нет. пару тройку алгоритмов можно и на схх имплртировать в игру, если нужно, напоминаю юнити кроскомпилится в схх давно
нет это не так, он работал когда-то давно, сейчас можно в vs дизасемблер посмотреть, в очень значительной части кода будет 1в1. потери происходят при проверках выхода за пределы массива и тп. при должной оптимизации их млжно опустить
Конечно есть Mono Framework, но если честно, то я не видел ни одного реально классного продукта, который был бы написан на нём под Linux.
Юнити на моно.
Работая с этим сайтом, Вы даете согласие на использование файлов Cookie.
Презентация игровых программ курса
Каждый день будет приходить по одному уроку.
Первый урок будет прислан уже через несколько минут.
Каждый день на почту будет приходить по одному уроку.
Ты в любой момент сможешь отписаться от рассылки.
Чтобы стать хорошим программистом — нужно писать программы. На нашем сайте очень много практических упражнений.
Ты в любой момент сможешь отписаться от рассылки.
Научился: Александр Низов. Следующим курсом пока что выбрал курс "Теория ООП". В целом впечатления о данном сайте только положительные. Самому очень интересна данная методика к изуечению ЯП, посмотрим что покажет практика). Фотографию прикрепляю).
Научился: Отличный курс ! Как всегда узнал что то новое, получил практику программирования
Трудности: Не знаю какой проходить следующий курс, в раздумьях )
Читайте также: