Желаю удачи в непростом пути геймдевелопера!

Совет от опытного разработчика: посмотри как пользоваться гитом, ибо это механика сохранения как в играх но для кода, теория простейшая и даже для мелких проектов сохранит время и нервы, ибо появится возможность вернуться в прошлое к другим сохранениям

Привет-привет) Чувак, ты очень крут, что так перешагнул через себя и решил изучать программирование - безумно напомнило меня самого, когда я только начинал писать игры ещё в школе на Pascal. Также делал нечто навроде рогалика, и, даже получалось делать процедурную генерацию островов, очень недурно выглядящих, пхп Сам уже почти 6 лет работаю на Unity + C#, и, могу от себя дать несколько советов. 1. У тебя сейчас очень начальный уровень знания программирования - в этом нет ничего плохого, все мы с этого начинали, но, главное не вляпаться на этом этапе в ошибки, которые допускают огромное количество новичков. А именно: 1.1. Не занимайся лишней оптимизацией, не гоняйся за мнимыми улучшениями производительности до тех пор, пока не поймёшь, что это на самом деле нужно. Оптимизировать код по мере необходимости легко, а тратить время на оптимизацию в самом начале, когда плохо разбираешься в теме - очень серьёзная ошибка, которая может убить огромное количество времени. 1.2. Очень скоро проект начнёт становиться огромным, в одном файле будет адовое количество кода, но, что куда ужаснее, весь этот код будет в основном методе (Main). Для того, чтобы в дальнейшем было проще поддерживать игру, старайся делить её логику на методы по максимуму. Это называется декомпозицией - деление одной сложной работы на несколько работ поменьше. Чем больше таких маленьких кусочков будет, тем лучше, самое крутое, что их можно будет переиспользовать. В дальнейшем переноси такие методы в отдельные файлы, группируй их. Так у тебя самостоятельно начнёт формироваться представление, что код игры можно разделить на различные "модули" (например, модуль логики врагов, модуль логики предметов, модуль логики генерации карт и т.д.). 2. Веди диздок, записывай мысли, идеи. Почитай, что такое MDA (Mechanics, Dynamic, Aesthetics), попробуй разложить свою игру на эти составляющие, после части игры на эти составляющие, и т.д. и т.п. 3. Не пренебрегай литературой по программированию, особенно, от зарекомендовавших себя авторов. Для начала хорошим вариантом могут быть две книги - "чистый код" (очень полезна в начале) и "чистая архитектура" (потребуется далее) за авторством Роберта Мартина, он же Дядюшка Боб. Это, пожалуй, обязательный список литературы для каждого начинающего программиста, пхп. Также настоятельно рекомендую почитать "Паттерны программирования игр", за авторством Роберта Нистрема. Она может показаться чуть сложной, но, это крайне полезная литература для начинающих программистов в геймдеве. 4. Прочитай про паттерн MoSCoW - это о приоритетах и о том, как определять важность задач. Всегда старайся расписывать план работ, не обязательно подробный, но хотя бы примерный. Если в процессе программирования понимаешь, что тут классно было бы реализовать ту или иную идею, поправить код или пр. - обязательно вноси в список задач, а после, как будет время, раскидывай их по приоритетам, что более важно, а что менее. 5. Как уже писали выше, GitHub в процессе разработки - наше всё. Как минимум, это постоянный бэкап, на случай, если вдруг с ПК или жёстким диском что-нибудь случится. Есть много ещё всего, что можно описать, но также если тебе самому интересно что-нибудь - пиши, может, что подскажу, смогу чем-нибудь быть помочь. Формат классный и ламповый, однозначно лайк и подписка)

Замечательная идея насчет аккумуляции знаний в экселе! Для моего текущего изучения прекрасно, и я возьму это на вооружение. Изучаю С++, пока в самом начале пути, уроки конспектирую в IDE с помощью комментов. Но еще я в данный момент осваиваю программу Obsidian в частности и метод Зеттелькастен в целом, и общую базу знаний планирую полностью вести там. Если вкратце, составляю личную Вики по интересным областям знаний. Крайне советую хотя-бы ознакомиться) И я тоже хочу заниматься геймдевом. Вообще, я инженер по медицинской технике, и геймдев для меня-отправная точка для воплощения идеи максимум-создания своего аналога хирургического робота ДаВинчи, максимально крутой и безумно дорогой штуки) Первый шажок для этого сделан-выклянчил у хирургов на работе использованный инструмент от этого робота😅 Это, фактически, тоненькая рука, которая может двигаться как кисть человека, только с двумя пальцами.

Cool!Keep going!

Круто у тебя namespace назван. Но проект прикольный)

Чувак, очень классное и ламповое видео. Хочу сказать - изучи как работает гит, пойешь все за два-три дня и тогда сможешь создавать версии и откатывать назад, то есть ты говорил что ты забросио игру из за того что не смог доделать фичи, а с гитом ты бы просто вернулся назад по ветке и норм😊😊

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

Очень хочется посмотреть что получиться в конце. Такой вопрос, знаком ли с каналом Романа Сакутина, он программист с 10 летним стажем, у него есть бесплатные курсы по С# и Unity на ютуб канале, может они тебе помогут в будущем. Не сдавайся, очень хочется посмотреть на конечный результат.

3:13 на какой графике? USQL? если ты про ASCII то она произносится как "аскии" западные гейм дев блоггеры рекомендуют не начинать свой путь с двух вещей: ммо и рогалики. ммо потому что неткодинг это адский ад, а рогалики потому что в них много подводных камней. например случайная генерация в играх не должна быть случайной. заметил как у тебя генерируются недоступные для игрока пустоты? это крайне неэффективно. рекомендую поискать про генерацию подземелий в TES Daggerfall. да и в принципе максимально изучать тему перед тем как её реализовывать. хорошая генерация должна быть как в dwarf fortress - очень многоуровневая и зависящая от тысяч параметров на многих слоях. надо ли говорить сколько лет на это нужно потратить? опыт, опыт, и ещё раз опыт. набивать шишки, и учиться. универсальный совет 1: учись кодить так чтобы вернувшись к свему коду через месяц или год ты смог бы его понять. преставь себе что ты в будущем будешь это читать напрочь забыв что для чего и как. заранее объясняй будущему себе каждую строчку кода. но не в комментарии рядом, конечно же, а просто делай прозрачную логику. универсальный совет 2: сначала релиазуешь гипотезу. любой ценой. грязный огромный нечитаемый код - нармальна. проверяешь гипотезу, правишь баги. как только она работает и работает правильно - остановись. сходи отвлекись, подыши воздухом, понаблюдай за улицей, разомнись. возвращаясь к коду не приступай к следующей задаче. перепиши всё красиво и понятно для будущего себя. это то что мы называем рефакторингом. чем дальше откладываешь момент рефакторинга тем большую яму ты себе выкапываешь. в процессе этого ты заодно и будешь пассивно учиться критически важному навыку - пониманию архитектуры кода и проектированию систем. универсальный совет 3: стремись к минимальному дубляжу кода. если один и тот же код встречается два раза - остановись и подумай. возможно здесь нужен метод. возможно в будущем этот же код понадобится третий и четвёртый раз. будущий ты получит маленькую но приятную и очень нужную дозу дофамина когда поймёт что не нужно ничего писать ещё раз или копипастить. из этого вытекает совет 3,5: думай об универсальности. generic код это то к чему индустрия стремилась десятилетиями. а люди скипают эту тему из-за лени разбираться. зря. универсальный совет 9001: не существует ПРАВИЛЬНОГО способа погромировать. серьёзно. все эти советы, практики, принципы, парадигмы, паттерны, etc - всё это лишь инструменты. гвоздь можно забивать молотком. а можно и плоскогубцами. а можно и просто чем-то твёрдым. кто-то даже руками умеет. никогда не придерживайся строго чего-то одного. человек который говорит тебе кодить вот ТАК, и ТОЛЬКО так, и никак иначе - это человек просто загнавший себя в уютные ему рамки и который боится развиваться и расти над собой. когда тебе навязывают строго что-то одно, например что "основной конструктор должен быть самым последним в списке конструкторов", включай скептика. в целом скептика лучше вообще не выключать. кодинг это безграничный космос. если будешь летать строго по отмеченным путям - можешь никогда не найти космическое чудо которое изменит всю твою жизнь.

Лучше хорошо ООП освоить, классы всех типов, перегрузки методов и тому подобное. Практиковаться на чем-то мелком, чисто руку набить и запомнить. А вот проекты сложные начинать уже после, иначе постоянно будут затыки как с первой игрой.

Добрый день, чисто теоретически с алгоритмами и кодом могу помочь) дело интересное делаешь, продолжай в том же духе!) думаю если посмотрю на код этой игры, смогу пофиксить, у вас есть акк на гитхаб?

похоже на Dwarf Fortress немного)

Скинешь Excel таблицу? Интересно было бы почитать

если нет цели стать Кадзимой, то лучше её поставить, а иначе шляпа получится)

что с кодом в начале? зачем проверка на наличие врагов? если врагов 0, то цикл не запустится