Консольная игра
Ребята помогите плииз, как это написать. Учусь с нуля.
Написать игру, в которою могут играть два игрока.
При старте, игрокам предлагается ввести свои никнеймы.
Никнеймы хранятся до конца игры.
Программа загадывает случайное число 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#. Часть 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# игру «Змейка».В качестве интерфейса.
Змейка в консоли: неправильное поведение функции
Всем привет! Пишу консольную змейку. Есть класс Snake и метод isSnake(), который работает.
Змейка в консоли(баг при повороте)
Доброго времени суток, не могли бы подсказать как исправить один баг в моей игре в консоли. Когда.
А вот это меня улыбнуло, горбатая змейка. Как говорится, не баг, а фича.
Glitch, А что догадываться, если это прописаны в этом клочке.
Glitch, Просто, вы начали кричать на человека, не читая его код, даже не пытаясь вникнуть. У человека всё работает, да он это написал. Он спросил конкретный вопрос: «как сделать так,чтобы не моргало?», а вы начали обсуждать и осуждать, то что у него что-то не работает в программе, а по его проблеме в итоге тишина.
Добавлено через 3 минуты
в коде 4 доп. функции.Это setup(устанавливает начальные параметры),draw(выводит все элементы игры),input(отвечает за ввод клавиш), и logicOfGame(логика игры).
Добавлено через 37 минут
И если кто-то найдет причину того,что змея горбатится,то отпишитесь
и еще всякого по мелочи над исправлять, особенно неприятно, когда при быстром нажатии нескольких клавиш засчитывает поражение
Добавлено через 5 минут
логика тоже местами хромает. если фрукт возле стены и заходит на него перпендикулярно стене, проигрываешь, потому что змейка мгновенно вырастает и врезается в стену)
крч мигание не главная проблема)
Представляю вашему вниманию, почти идеальный(на самом деле нет) движок змеики на c# в консоле. Полностью переписал отрисовку. Вынес игру в отдельный поток, дабы Sleep на отрисовке не мешал нажимать клавиши. Ну и остальное по мелочи пришлось переработать в связи с этими изменениями. Багов вроде не заметил серьезных. Один глюк есть, иногда еда появляется на теле змеи, хотя по идее не должна. Где моя ошибка не вижу, нужно дебажить. Но я уже устал пилить эту игру. Кому нужно исправите. Осталось только уровни в аркадном режиме доделать, оптимизировать, ну и проверок добавить в разумных пределах.
Критикуйте крч)
Вложения
 | SnakeConsoleExe.7z (4.7 Кб, 44 просмотров) |
Можно(Нужно) убрать. Ничего полезного не делает.
Создал игру(змейка в консоли) есть несколько неточностей
Проблемы: 1. при съедании фрукта игра заканчивается 2 всё мигает настолько, что у меня.
Игра «Змейка»: чтобы змейка не съедала сама себя
Здравствуйте! Пишу змейку на VB 2010. Не получается составить условие того, что бы змейка не.
Отобразить в консоли:увеличить и уменьшить длину массива на заданное ранее из консоли число
Доброго дня суток, исходный код и задача есть Подскажите пж, не получается реализовать некоторые.
Как запустить программу из консоли без блокировки консоли?
Вводу например firefox в консоль открывается приложение и в консоль больше ничего ввести нельзя.
Клавиши F1-F12 в консоли, и работа с мышкой в консоли
Я искал на сайте, но не нашел упоминания о том как обрабатывать и или узнавать где находится курсор.
Вызов консоли для другой вкладки из консоли js
Всем привет! Пишу скрипт для авто нажатия определенных элементов на сайте в определенной.
Игра на 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 байт загрузочного сектора. А до тех пор — счастливого кода!