код си шарп для игры
Консольная игра
Ребята помогите плииз, как это написать. Учусь с нуля.
Написать игру, в которою могут играть два игрока.
При старте, игрокам предлагается ввести свои никнеймы.
Никнеймы хранятся до конца игры.
Программа загадывает случайное число gameNumber от 12 до 120 сообщая это число игрокам.
Игроки ходят по очереди(игра сообщает о ходе текущего игрока)
Игрок, ход которого указан вводит число userTry, которое может принимать значения 1, 2, 3 или 4,
введенное число вычитается из gameNumber
Новое значение gameNumber показывается игрокам на экране.
Выигрывает тот игрок, после чьего хода gameNumber обратилась в ноль.
Игра поздравляет победителя, предлагая сыграть реванш
Подумать над возможностью реализации разных уровней сложности.
В качестве уровней сложности может выступать настраиваемое, в начале игры,
значение userTry, изменение диапазона gameNumber, или указание большего количества игроков (3, 4, 5. )
Подумать над возможностью реализации однопользовательской игры
т е игрок должен играть с компьютером.
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Консольная игра
Написать игру, в которою могут играть два игрока. При старте, игроках предлагается ввести свои.
Консольная игра
Здравстуйте кому не сложно помогите с написанием консольной игры. Условие надо написать игру в.
2D консольная игра
Хотел сделать с графикой ТЕТРИС, но потом подумал, что неплохо попробовать прощупать сначала такую.
Консольная игра квест
Помогите пожалуйста создать игру-квест, никак не могу понять почему выскакивает ошибка, с.
Программирование на C, C# и Java
Уроки программирования, алгоритмы, статьи, исходники, примеры программ и полезные советы
ОСТОРОЖНО МОШЕННИКИ! В последнее время в социальных сетях участились случаи предложения помощи в написании программ от лиц, прикрывающихся сайтом vscode.ru. Мы никогда не пишем первыми и не размещаем никакие материалы в посторонних группах ВК. Для связи с нами используйте исключительно эти контакты: vscoderu@yandex.ru, https://vk.com/vscode
Игра на C#: Угадай число
Сегодня мы будем создавать кое-что простое, но в то же время интересное – это игра на C# под названием “Угадай число”. Смысл игры заключается в том, что компьютер рандомно загадывает число от 0 до 9, а пользователь должен угадать это число, имея 3 попытки.
Итак, приступаем. Создаём консольное приложение (“Файл”->”Создать”->”Проект”->”Консольное приложение”) и для начала задаём функцию Random вот так:
Иными словами, мы создаём некий генератор случайных чисел rand, который каждый раз при запуске программы будет генерировать псевдослучайные числа, значение которых каждый раз будут заноситься в целочисленную переменную i. Число 10 в скобках означает, что всегда будет производиться генерация только лишь 10 первых чисел (0, 1, 2, 3, 4, 5, 6, 7, 8, 9). Если в скобках поставить 100, то рандом будет выбирать числа из диапазона от 0 до 99 и т.д.
Также мы инициализируем переменную count:
Игра на C# меньше 8 Кб
Как уменьшить размер исполняемого файла C#?
Как человеку, выросшему во времена дискет и 56 Кбит модемов, мне всегда нравились небольшие программы. Я мог поместить много небольших программ на дискету, которую носил с собой. Если программа не помещалась на моем гибком диске, я начинал думать, почему: много графики? Музыка? Программа сложная или просто раздулась?
В наши дни дисковое пространство стало настолько дешевым (а огромные флешки настолько вездесущими), что люди отказались от оптимизации размера.
Единственная область, где размер еще имеет значение — это передача: при передаче программы по проводу мегабайты приравниваются к секундам. Быстрое соединение на 100 Мбит может пропускать только 12 мегабайт в секунду в лучшем случае. Когда на другом конце провода находится человек, ожидающий завершения загрузки, разница между пятью и одной секундами может оказать существенное влияние на восприятие. Человек может зависеть от времени передачи либо напрямую: он загружает программу по сети, либо косвенно — бессерверная служба развертывается для ответа на веб-запрос.
Люди обычно воспринимают что-то быстрее 0,1 секунды как мгновенное. 3 секунды — примерно предел непрерывности потока пользователя, и вам было бы трудно удержать пользователя после 10 секунд.
Хотя меньший размер больше не является существенным, он всё равно лучше.
Эта статья вышла как эксперимент, чтобы выяснить, насколько маленьким может быть полезный автономный исполняемый файл C#. Могут ли приложения C# достичь размеров, при которых пользователи посчитают время загрузки мгновенным? Возможно ли использовать C# в тех местах, где язык не используется сейчас?
Что такое автономность?
Автономное приложение — это приложение, включающее в себя все необходимое для запуска на операционной системе. Компилятор C# принадлежит к группе компиляторов, нацеленных на виртуальную машину (Java и Kotlin — другие заметные члены группы). Выходные данные компилятора C# — это исполняемый файл, требующий выполнения некоторой виртуальной машины. Нельзя просто установить чистую операционную систему и ожидать, что на ней можно запускать программы, созданные компилятором C#.
Для автономности приложение на C# должно включать среду выполнения и все используемые библиотеки классов. Это много, чтобы вписаться в планируемые 8 Кб!
Игра меньше 8 Кб
Мы создадим клон змейки:
Не интересна игровая механика? Не стесняйтесь переходить к интересным частям, где мы сжимаем игру с 65 мегабайт до 8 килобайт за 9 шагов, прокрутите до графика.
Игра без выделения памяти
Мы собираемся создать игру без выделения памяти, и под этим я не имею в виду “не выделять память в цикле игры”, распространённое среди разработчиков игр C#. Я имею в виду запрет ключевого слова new со ссылочными типами во всей кодовой базе. Причины станут очевидны на заключительном шаге сжатия игры.
При таком ограничении можно задаться вопросом, есть ли вообще смысл в использовании C#: без new мы не будем использовать сборщик мусора, не сможем выбрасывать исключения и т.д. То есть язык С будет работать так же хорошо.
Одна из причин использования C# — “потому что это возможно”. Другая причина — тестируемость и общий доступ к коду. Хотя игра не выделяет память для ссылочных типов, это не означает, что ее части не могут повторно использоваться в другом проекте, не имеющем таких ограничений. Например, части игры могут быть включены в проекта xUnit, чтобы покрыть приложение юнит-тестами. Если кто-то выбирает C для сборки игры, всё ограничено возможностями C, даже если код используется повторно. Но поскольку C# обеспечивает хорошее сочетание конструкций высокого и низкого уровня абстракций, мы можем использовать высокий уровень по умолчанию, а низкий уровень при необходимости. Для достижения размера развертывания в 8 Кб потребуется низкоуровневая часть.
Структура игры
Начнем со структуры буфера кадров. Буфер кадров — это компонент, содержащий пиксели (или в данном случае — символы), отображаемые на экране:
Мы не можем переборщить с размером фиксированного массива, потому что как часть структуры массив должен жить в стеке, а стеки, как правило, ограничены небольшим количеством байтов (обычно 1 Мб на поток) и 40*20*2 width*height* sizeof(char) — допустимое число.
Этот генератор не слишком хорош, но нам не нужно ничего сложного. Теперь пишем обёртку для логики игры:
Состояния, которые должна отслеживать змейка:
Мы используем генератор случайных чисел для генерации случайного положения и направления змеи. Мы случайным образом размещаем еду на игровой поверхности так, чтобы она не перекрывала змею, и запускаем цикл игры. Внутри игрового цикла мы просим змею обновить свое положение и проверить, съела ли она сама себя. Затем рисуем змею, проверяем клавиатуру на ввод, тестируем змею с едой и отображаем всё на консоль. Давайте посмотрим, где мы находимся с точки зрения размера.
Il Linker
С этой настройкой игра сжимается до 25 МБ. Хорошее сокращение, но оно далеко от нашей цели.
IL Linker имеет более агрессивные настройки, не выставляемые публично, и они могут работать дальше, но в конце концов, мы ограничимся размером самой среды выполнения CoreCLR coreclr.dll в 5,3 Мбайт. Возможно, мы зашли в тупик на пути к игре на 8 Кб?
В отличие от CoreCLR, Mono также зависит от распространяемой библиотеки среды выполнения Visual C++, недоступной в установке Windows по умолчанию: чтобы сохранить автономность приложения, нам нужно зашить эту библиотеку в приложение. Это увеличивает объем ещё на один мегабайт или около того.
Среда выполнения
Давайте посмотрим, где мы находимся теперь с конфигурацией CoreRT по умолчанию:
4,7 МБ. Файл пока самый маленький, но этого недостаточно.
Умеренная экономия размера в CoreRT
Сейчас мы на уровне 4,3 МБ.
Включение сильной экономии в CoreRT
Я сгруппировал еще несколько вариантов компиляции в режим “сильной экономии”. Режим удаляет поддержку возможностей, важных для многих приложений, но не для нашей змейки. Мы удаляем:
Мы достигли 3,0 МБ, это 5% от начального размера, но у CoreRT есть еще один трюк.
Отключение рефлексии
Сейчас мы на уровне 1,2 МБ. Оверхед на рефлексию довольно значителен.
Пачкаем руки
Как мы уже видели ранее, CoreRT — это набор библиотек времени выполнения в сочетании с опережающим компилятором. Что делать, если мы заменим библиотеки времени выполнения с минимальным переопределением? Мы решили не использовать сборщик мусора, и это делает работу намного более выполнимой. Начнём с простого:
Пересоберём игру с заменой фреймворка:
Неудивительно, что это не слишком эффективно. Заменяемые API уже относительно легки, переписывание только добавляет пару килобайт, о которых не стоит упоминать. Но это важная ступенька к последнему шагу нашего путешествия.
Замена библиотек среды выполнения
Оставшиеся 1,2 МБ кода и данных в игре — это поддержка вещей, которые мы не видим, но они есть, они готовы, если нам понадобятся. Есть сборщик мусора, поддержка обработки исключений, код для форматирования и печати трассировок стека на консоль, когда происходит необработанное исключение, и многие другие вещи под капотом.
Компилятор может обнаружить, что ничего этого не требуется, и избежать их генерации, но то, что мы пытаемся сделать, настолько странно, что неплохо добавить функции компилятора для его поддержки. Способ избежать этого — просто предоставить альтернативную библиотеку времени выполнения. Начнем с переопределения минимальной версии базовых типов:
Теперь откажемся от файла проекта и dotnet CLI, запустим отдельные инструменты напрямую. Мы начинаем с запуска компилятора C# (CSC). Я рекомендую запускать эти команды из “x64 Native Tools Command Prompt for VS 2019” — он находится в меню Пуск, если у вас установлена Visual Studio.
Перестроим IL с добавленным кодом и повторно запустим ILC.
Имя символа __managed__Main является контрактом с компилятором — это имя управляемой точки входа программы, созданной ILC. Но команда не работает:
Некоторые из этих символов кажутся знакомыми: компоновщик не знает, где искать вызываемые API Windows. Добавим библиотеки для них:
Выглядит лучше, всего 4 неразрешенных символа:
Остальные отсутствующие символы — это помощники, которые компилятор ожидает найти в библиотеке времени выполнения. Их отсутствие обнаруживается только во время связывания, потому что эти помощники обычно реализуются в сборке, и компилятор ссылается на них только по их символическому имени в отличие от других типов и методов, необходимых компилятору и предоставленных нами выше.
Помощники добавляют и удаляют кадры стека, когда машинный код вызывается управляемым или управляемый — машинным. Это необходимо, чтобы работала сборка мусора. Поскольку у нас нет GC, давайте заглушим их кодом C# и другим волшебным атрибутом, который поймёт наш компилятор:
После перестроения исходного кода с этими изменениями и повторного запуска ILC, связывание, наконец, будет успешным. Мы сейчас на 27 килобайтах. Игра работает!
Возня с линкером
Оставшиеся килобайты можно получить с помощью трюков, которые используют разработчики нативного кода, чтобы уменьшить свои приложения. Мы собираемся:
Ещё меньше?
Исполняемый файл ещё содержит несущественные данные — компилятор ILC просто не предоставляет параметры командной строки, отключающие их генерацию.
Одна из этих избыточных структур данных — информация GC для отдельных методов. В CoreRT есть точный сборщик мусора, требующий, чтобы каждый метод описывал, где находятся ссылки на кучу GC в каждой инструкции тела метода.
Поскольку у нас нет сборщика мусора, эти данные не нужны. Другие среды выполнения — например Mono — используют консервативный сборщик, не требующий этих данных. Он просто предполагает, что любая часть стека и регистров процессора может быть ссылкой GC. Консервативный сборщик торгует производительностью GC ради экономии размера. Точный сборщик CoreRT также может работать в консервативном режиме, но он еще не подключен. Это потенциальное будущее дополнение, которое мы могли бы использовать, чтобы сделать программу ещё меньше. Может, однажды мы сможем сделать упрощенную версию нашей игры в 512 байт загрузочного сектора. А до тех пор — счастливого кода!
Пишем игровую логику на C#. Часть 1/2
Всем привет. В связи с выходом моей игры SpaceLab на GreenLight я решил начать серию статей о разработке игры на C#/Unity. Она будет основываться на реальном опыте её разработки и немного отличаться от стандартных гайдов для новичков:
Во-первых, я не буду повторять документацию иными словами.
Во-вторых, необходимо знание программирования, чтобы понять о чем я пишу.
К сожалению, эта статья не сможет вам помочь, если вы хотите создать свою казуальную игру используя лишь мышь.
Зато я шаг за шагом расскажу о создании движка, на котором будет работать игровая логика нашей экономической стратегии.
Для тех, кто любит спойлеры или просто хочет почитать код — в конце есть ссылка не репозиторий, где каждый пункт добавлен отдельным коммитом.
Кого заинтересовало узнать, что за игра — внизу есть видео и ссылка на бесплатное скачивание.
Сразу предупрежу — у меня нету цели идеально применить огромное количество паттернов или описать подход к методологии TTD. В статье я стараюсь писать читабельный, поддерживаемый и безбажный код, как он писался бы в жизни. Возможно, людям имеющим огромный скилл в C# и написании игр данная статья покажется очевидной. Тем не менее, вопрос о том, как писать гейм-логику я слышал довольно часто и эта статья прекрасно подойдет и тем, кому интересно написание сервера и тем, кому интересно написание клиента на Unity.
Краткое описание GD, которого мы хотим достичь
1. Игрок управляет кораблем. В корабле можно выстраивать комнаты, в комнатах можно добавлять в слоты модули.
2. Для постройки чего-либо необходимо потратить ресурсы и подождать время.
Через полгода разработки результат должен выглядеть как-то так)
План работы
1. Настраиваем проекты
2. Создаем ядро — базовые сооружения
3. Добавляем и тестируем первые команды — построить строение и модуль
4. Выносим настройки строений и модулей в отдельный файл
5. Добавляем течение времени
6. Добавляем Constructible, строения теперь строятся некоторое время
7. Добавляем ресурсы, для постройки необходимы ресурсы
8. Добавляем цикл производства — модуль потребляет и выдает ресурсы
Статья получилась очень объемной, потому пришлось разделить ее на две части. В данной части мы сделаем первые пять пунктов, а во второй части закончим
1. Настраиваем проекты
На первых порах Unity Editor нам не понадобится — мы пишем ГеймЛогику. Открываем VS и создаем два проекта: GаameLogic и LogicTests (Unit Tests Project). В первом мы будем писать собственно логику игры на чистом C# не используя namespace Unity, второй будет тестить нашу логику встроенной тест-тулзой. Добавим в GameLogic первый класс Core и напишем первый тест, чтобы проверить нашу связку:
2. Создаем ядро — базовые сооружения
Что ж, это указывает, что настроили мы корректно и можно переходить к программированию логики.
Итак, разберемся с нашим гейм-дизайном. У нас есть корабль (Ship), в нем комнаты (Room), в каждую комнату может быть построено строение (Building), а в каждом строении могут быть модули (Module). Конечно, Room и Building можно было бы объединить в одну сущность, но далее такое разделение нам только поможет.
Для всех этих сооружений я создам отдельный namespace Architecture и базовые классы. А так же enum для индексов комнат. Многие вещи, которые мы сейчас делаем — временные и необходимы, чтобы запустить первый тест гейм-логики.
3. Добавляем и тестируем первые команды — построить строение и модуль
Теперь мы сможем написать первую «фичу» — постройка строения и постройка модуля в нем. Все подобные действия я буду описывать отдельным классом, который будет наследоваться от класса Command:
И хотя сейчас даже такая маленькая структура излишня — чуть позже благодаря ей мы прикрутим необходимые нам события. А существование каждого атомарного действия в отдельной команде позволит нам их комбинировать. Напишем наши первые два действия:
Пришло время посмотреть, работает ли наш движок. В тестах создаем ядро, пробуем построить комнату, а в нее пытаемся построить модуль. Кроме этого стоит добавить проверку, что нельзя построить то, чего гейм-логика не должна позволять строить:
4. Выносим настройки строений и модулей в отдельный файл
К счастью, наши тесты прекрасно проходятся. Теперь нам необходима возможность линейно расширять количество строений и модулей — для этого необходимо сделать следующее:
Как можно понять, теперь наш код нерабочий. Для того, чтобы не таскать каждый раз с собой конфиги создадим фабрику, которая будет выпускать наши сооружения зная только их тип. Я знаю, что название пока слишком общее, но мы всегда с легкостью можем его переименовать благодаря IDE, так же, как и разделить на две фабрики:
Я сразу добавил несколько строений и модулей, чтобы можно было покрыть тестами. И сразу скажу — да, хранить все эти настройки в фабрике нету никакого смысла. Они будут лежать отдельно в JSON файлах, по одному на структуру, парсится и передаваться в фабрику. К счастью, у нас движок даже не заметит этого изменения. Ну а пока нам не так критично вынести их в ЖСОНы, как запустить тесты и проверить все ли корректно работает. К счастью, да. Заодно допишем тесты, что нельзя построить модуль не в той комнате, например, Furnace в PowerPlant.
Увы, как вы можете догадаться, никто логику проверки не писал. Добавим условие валидации в команду постройки модуля и после этого успешно пройдем тест:
Что ж, теперь все корректно. Заодно добавим тесты на корректную работу лимитов и пойдем дальше.
5. Добавляем течение времени
Компьютеры дискретны. И все игры дискретны. Если говорить просто, то представим, что все игры — пошаговые. У большинства игр шаги пропускаются автоматически и 60 раз в секунду. Такие игры называются риалтайм. Я понимаю, что это очень грубо, но для реализации гейм-логики довольно удобно представлять, что ваша игра — пошаговая и мыслить такими категориями. А потом уже на клиенте можно запустить tween между двумя состояниями и юзеру будет красиво и игра будет работать быстро. Для начала введем понятие хода:
А также введем команду, которая позволяет переключать хода. Я сразу добавил команду, которая позволяет переключить несколько ходов — будет довольно удобно во время тестирования. В тестах одним выстрелом покроем сразу двух зайцев.
Забегая далеко вперед напишу, как сделать переключалку скоростей в игру, которая позволит нам запускаться с разной скоростью:
Теперь в Unity достаточно будет подвесится на любой Update и передавать дельта время в наш TimeWarp:
Продолжение следует.
В следующей статье мы закончим создание работоспособной основы для нашего движка, реализовав следующие пункты:
6. Добавляем Constructible, строения теперь строятся некоторое время
7. Добавляем ресурсы, для постройки необходимы ресурсы
8. Добавляем цикл производства — модуль потребляет и выдает ресурсы
Для тех, кто просто любит код — есть отдельный репозиторий на ГитХаб
Кроме этого, если вас интересуют вопросы по разработке SpaceLab — задавайте, отвечу на них в комментариях или в отдельной статье
Скачать для Windows, Linux, Mac бесплатно и без СМС можно со страницы SpaceLab на GreenLight
Пишем игровую логику на C#. Часть 2/2
Это продолжение предыдущей статьи. Мы шаг за шагом создаем движок, на котором будет работать игровая логика нашей экономической стратегии. Если вы видите это впервые — настоятельно рекомендую начать с Части 1, так как это зависимое продолжение и требует ее контекста.
Как и раньше — внизу статьи вы можете найти полный код на ГитХаб и ссылку на бесплатное скачивание.
План работы
1. Настраиваем проекты
2. Создаем ядро (базовые сооружения)
3. Добавляем и тестируем первые команды — построить строение и модуль
4. Выносим настройки строений и модулей в отдельный файл
5. Добавляем течение времени
6. Добавляем Constructible, строения теперь строятся некоторое время
7. Добавляем ресурсы, для постройки необходимы ресурсы
8. Добавляем цикл производства — модуль потребляет и выдает ресурсы
Добавляем Constructible
Давайте теперь что-то привяжем к течению времени. Пусть постройки и модули строятся не сразу, а несколько ходов (зависимо от конфигурации). Для начала во все настройки добавим пункт ConstructionTime. Если ConstructionTime равно нулю — структуру построить невозможно.
Не забываем добавить настройки в фабрику:
Теперь создадим класс Progression, которым мы будем реализовывать любые прогрессии, которые текут во времени, например, строительство.
Теперь добавим в наши комнаты и модули возможность постройки.
И запретим постройку модулей в еще не построенной комнате:
Само собой после этого упали тесты, потому мы добавим в тесты CorrectConstruction, IncorrectConstruction, CantConstructInWrongBuilding и ModulesLimits после успешного выполнения команды BuildingConstruct вызов метода Complete (да-да, специально для этого мы его и создали)
А для проверки на невозможность построить в еще не законченной комнате напишем отдельный тест:
Добавляем ресурсы
Для того, чтобы что-то создать сначала необходимо что-нибудь разрушить и собрать металлолом. Давайте реализуем ресурсы, чтобы игроку пришлось оплачивать свои постройки. Ресурсов будет три — Энергия, Руда и Металл.
Также создадим Банк, где игрок будет хранить и откуда забирать ресурсы.
Теперь добавляем цену производства в настройки модулей и строений:
Теперь добавим команду, которая позволяет платить ресурсы и сразу же попробуем ее в деле (в тестах):
Оплата работает корректно и начать платить за постройки и модули довольно просто — добавим вызов команды Pay в качестве последней валидации (она должна быть последней, если мы не хотим, чтобы после оплаты другая проверка не дала построить конструкцию):
К счастью, у нас снова отвалились тесты (к счастью, потому что это значит, что они отлично выполняют свою работу).
В старых тестах добавим игроку ресурсы и напишем новый тест, который в будущем будет проверять, что внезапно не появилась возможность бесплатно построить конструкцию. Добавляем во все сломанные тесты поближе к началу:
И пишем тест на постройку с недостачей ресурсов:
Добавляем цикл производства
Забирать ресурсы, конечно, приятно, но давать значительно приятнее. Давайде запрограммируем возможность запускать производственные цепочки. Каждый модуль сможет скушать определенное количество сырья и потом выдать готовый материал. Снова начинаем с конфигурации:
Теперь добавим в каждый ход прогресс по производству:
Класс получился крупноват, но мы всегда можем его отрефакторить, если сложность будет завысокая. Теперь пишем тест. Он будет довольно длинный, проверять и корректность производства, и незапуск в случае недостачи ресурсов. Также я специально для теста создал отдельные настройки для модуля и строения (вдруг ГД их поменяет и у меня тесты упадут). В идеале все тесты можно было бы поменять на специальные тестовые настройки:
Конец
Итак, тесты запустились корректно и мы смогли сделать минимальную версию нашего продукта. Класс Factory получился раздутым, но если вынести настройки в JSON, то и он будет вполне ничего. Используя Json.NET нам необходимо написать что-то вроде этого:
Для тех, кто просто любит код — есть отдельный репозиторий на ГитХаб
Кроме этого, если вас интересуют вопросы по разработке SpaceLab — задавайте, отвечу на них в комментариях или в отдельной статье
Скачать для Windows, Linux, Mac бесплатно и без СМС, а так же поддержать нас можно на странице SpaceLab на GreenLight