используй единство
юпити
Двачую Юнити, хоть сам его ни разу не использовал.
Construct 2.
Ну или первая, фриверная. Любую хуергу сделаешь изи, прогать не нужно почти. Те куски, что есть - питон, но тащемта на форумах всё без тебя решено
Store.myGame.price=0
Ну или первая, фриверная. Любую хуергу сделаешь изи, прогать не нужно почти. Те куски, что есть - питон, но тащемта на форумах всё без тебя решено
Store.myGame.price=0
Чувак, смотря какая у тебя задача. Если тебе надо написать игруху для старого пердуна в универе - вообще не проблема, однозначно Юнити. Если у тебя стоит задача разобраться, как вся херня работает, то не слушай этих даунов.
Проблема Юнити в том, что ты нихера от неё не получишь. На ней собирается куча инди-говна именно потому что для этого не надо иметь ни архитекторский скилл, ни девелоперский. Хуяк-хуяк - и в релизную ветку.
В первую очередь вкачай понимание ООП, хабра тебе в помочь. Игры сложны потому что их чрезвычайно сложно продумать архитектурно.
Посмотри практики чистого программирования: Clean Code, "Рефакторинг" Фаулера, "Принципы, паттерны" Мартина - маст хэв.
Если будет мультиплеер - рассмотри CQRS, если не будет - забей, простого текстового файла с json хватит.
Потом смотри уже в сторону движка. В прицнипе, всё достаточно понятно: смотри на чём сделаны игры от серьёзных контор типа Valve и иже с ними.
На Шарпе могу посоветовать Моногейм. Он достаточно лоулвл, чтобы вкачать понимание того, что происходит, но достаточно высокоуровневый, чтобы на нём запилить игруху. К примеру, на нём сделана Terraria (говнокод, кстати) и Transistor (поразительно красивый код).
Отдельный плюс таких игр в том, что можно их открыть декомпилятором типа ilspy и посмотреть, как они сделаны. Оч помогает.
Сегодня ещё посижу в треде, задавай свои вопросы.
Проблема Юнити в том, что ты нихера от неё не получишь. На ней собирается куча инди-говна именно потому что для этого не надо иметь ни архитекторский скилл, ни девелоперский. Хуяк-хуяк - и в релизную ветку.
В первую очередь вкачай понимание ООП, хабра тебе в помочь. Игры сложны потому что их чрезвычайно сложно продумать архитектурно.
Посмотри практики чистого программирования: Clean Code, "Рефакторинг" Фаулера, "Принципы, паттерны" Мартина - маст хэв.
Если будет мультиплеер - рассмотри CQRS, если не будет - забей, простого текстового файла с json хватит.
Потом смотри уже в сторону движка. В прицнипе, всё достаточно понятно: смотри на чём сделаны игры от серьёзных контор типа Valve и иже с ними.
На Шарпе могу посоветовать Моногейм. Он достаточно лоулвл, чтобы вкачать понимание того, что происходит, но достаточно высокоуровневый, чтобы на нём запилить игруху. К примеру, на нём сделана Terraria (говнокод, кстати) и Transistor (поразительно красивый код).
Отдельный плюс таких игр в том, что можно их открыть декомпилятором типа ilspy и посмотреть, как они сделаны. Оч помогает.
Сегодня ещё посижу в треде, задавай свои вопросы.
Хороший совет: только Vector2 в текущей реализации не используй, кстати, напиши свой.
Предмет курсача?
Я бы в общем случае сценарий к wc3 писал. Какую-нибудь хуйню типа:
- 2 игрока
- вырубаем лес квадратами
- кто больше вырубил леса тот сильнее
- лес отрастает через 2 хода
- на вырубленные участки можно ставить мины
> кукарекает что-то о знаниях
> советует учить ООП
Поясни за ООП, что не так.
ООП - это хайпнутый костыль для уток. Годится только интерфейсы писать.
Ну и для хуяк-хуяк-и-в-продакшена тоже норм. На предложение это потом поддерживать или отлаживать следует либо предложение всё переписать, либо прощание разной степени вежливости. Своего кода в том числе.
Ибо. ООП-реализации не замкнуты и не компактны.
По длительному просмотру голливудского кинца и отсутствию функционального воспитания у людей может складываться впечатление о том, что любое висящее на стене ружьё должно выстрелить, а любой костыль надо подобрать и приладить к своим поделиям, но это не так. Из говна и палок получится дом укаинца и прекрасная компостная куча, но это не делает их хорошим стройматериалом. Из ООП можно сделать хелоуворлд и даже выходят красивые кнопочки, но это не делает его методом полноценного программирования логики.
Неизбежно получающийся зООПарк оправдывается любителем зоофилии тем, что там везде бинарщина, что якобы экономит ресурсы, на деле это просто делает ПО неотлаживаемым. Если же модули общаются человекочитаемыми инструкциями, то вопрос отладки лёгок и приятен. Что позволяет быстро перейти к процессу оптимизации.
Зоофил же хотя бы подсоснательно понимает что до оптимизации он никогда не доберётся и начинает оптимизировать дизайн, выкидывая на ходу всё, что в принципе могло представлять интерес к его поделкам.
ООП прекрасно отлаживается, видимо, ты не умеешь его готовить.
Суть его не в том, что есть какие-то интерфейсы, а в том, что ты проектируешься систему так, что замена части системы не вредит остальной. Код становится модульным.
Хочешь полностью заменить реализацию отрисовки игрока? При правильной архитектуре через ООП это сделать на несколько порядков проще и быстрее.
С другой стороны, надо понимать, что ООП - это инструмент, и писать на нём хеллоуворлд как раз не надо. Равно как и не надо вызывать виртуальные функции в Draw/Update методах.
Более того, в кривых руках, коих большинство, ООП превращается в ядерный снаряд, который разрывается каждый раз заново с каждым изменением системы.
Если ещё кратче, то ООП не относится к программированию определённой части системы, но к архитектуре системы вообще. Как и (T/D/B)DD. Неплохие практики же.
Ох уже эти откровения Кирилла из 6А
> ООП прекрасно отлаживается
Давай, зачитай последний багрепорт своего ООП-поделия.
> Суть его не в том, что есть какие-то интерфейсы, а в том, что ты проектируешься систему так, что замена части системы не вредит остальной.
Вот. А должны быть модули и интерфейсы, а не "части поделия". Если конечно кто-то собирается подняться над бейсик-уровнем.
> Хочешь полностью заменить реализацию отрисовки игрока?
Хочу, чтобы изменения отрисовку игрока не ломали физику. А если модуль физики что-то говорит модулю игрока, а модуль игрока этого не делает, то в логе была надпись человечьим языком "модель игрока неправильно машет елдой, а в конфиге игрока не хватает параметра длины". Чтобы когда у кого-то дойдут руки до модуля отрисовки игрока и его конфигов, ему не надо было бегать за таском или ждать пока вопрос появится в багтреке.
> не надо вызывать виртуальные функции
Тем не менее они там есть. Заставляет задуматься?
> ООП не относится к программированию определённой части системы
Именно что относится. К модулю интерфейса.
> Неплохие практики
Хайпоназвания уже должны насторожить. Нахуя мне рекламировать метод, сочиняя ему рифмованные названия, если он такой замечательный? Нахуй городить забор из терминов, которые сводятся к "проектируем сверху" или к "проектируем снизу", мешая в процессе в кучу-малу БД, логику и интерфейс, лишь бы под моднявый термин подошло?
Конечный дизайн приложения в принципе не является проблемой уже дольше, чем мы живём, именно поэтому там разводятся всякие клоуны. Проблема сегодня в том, как обкорнать конечный дизайн до прототипа и регулярно определять - какой дальше модуль или часть модуля писать, чтобы и у разработчиков, и у потребителей было основанное на реальности ощущение, что всё куда-то движется, но не в сторону помойки для багоподелий.
Помни, карманов как ты начинал.
>третий курс погромиста
>просит помощи у двача в написании сраного тамагочи
>и это не джем на два вечера, этоблядь курсовая, два семестра работы
>несколько десятков страниц пояснений кода, манятеорий, цитат из учебников
>научрук в восторге, завкаф хвалит и пророчит великое будущее, курсовая постепенно перерастает в диплопмную, по тамагочи готовятся доклады и оп ездит по конференциям, повышенная стипендия, фото на стенде "гордимся факультетом"
>оп заканчивает магистратуру и рассылает свое резюме по всем ААА-студиям, с рекомендательным письмом от декана и скриншотами тамагочи
Курсачи никому не всрались, так что писать лучше для себя.
WC3-редактор на котором был написан первый товер-дефенс, на котором была запилена первая дота, первые относительно полноценные сурвайвалы. Это охуенный удобный редактор, который дал путёвку в жизнь сотням разработчиков и ОПу попробовать на нём написать простейшую игрулину для себя будет полезно.
А что даст ему таскание всякого кала из книг в юнити?
Даже если он с этим потом выйдет в науку, где у нас сильная компьютерная наука? Её нет. Ни грантов, ни направлений, ни индустрии которой это было бы нужно. Процы кое-как на пердячем пару ещё проектируют, но и то давно не ради прогресса, а просто чтобы в войсках проц без анальных зондов был во время ядерной войны.
Пиздец, лучше уж юнити учить, чем тратить время на всякое древнее говно, поделия на котором нельзя продать.
Мань, там что ни сценарий - то игра.
И они либо сейчас охуенно продаются, либо могут охуенно продаваться, если их запихнут в стендалон.
https://www.youtube.com/watch?v=svwYOLbO6lQ
https://www.youtube.com/watch?v=4uJwquxvQvg
https://www.youtube.com/watch?v=Sfnx1mBFDEc
https://www.youtube.com/watch?v=vTteX2gWIZc
https://www.youtube.com/watch?v=wistREUvKqY
https://www.youtube.com/watch?v=NMIe7RmIwXY
Этот редактор (с некоторым влиянием Valve Hammer) породил юнити-хуюнити и т.д. Что там породило юнити? Оно до сих пор не может родить дееспособное SDK для VR, не смотря на то что 70% пользователей смартфонов уже имеют картонку или хотят её попробовать.
>нельзя продать
Что тебе непонятно, хуйло с двача?
Как же с тобой всё плохо. Даже по фразе "дизайн приложения не является проблемой". Давай, расскажи мне, какая CQRS не проблема.
В чём-то я тебя понимаю: в своё время я писал на C и думал совершенно так же.
По ООП советую найти лекции epam: там годно рассказывается, больше нигде интересного объяснения не видел. Про TDD есть раздел в "Принципы, паттерны ..." Мартина.
>там что ни сценарий - то игра.
Проиграл с этой обезьяны.
Я, думал, на свете не существует говноедов, которым по нраву школьные высеры в ворлд едиторе, ну или, по-крайней мере, не ожидал встретить их тут
> Давай, расскажи мне, какая не проблема будет если мы выдумаем что функцию надо обкарнать до половины её способностей просто потому что мы можем, при этом на хуй убив такую базовую концепцию любой (СУ)БД как "транзакция".
Ну если вы ебанутые, то это проблема конечно. Я конечно специалист по всему, но не буду вдаваться в решение этой проблемы, чтобы не уводить дискуссию в оффтопик. Что крайне вероятно, учитывая природу понимания психологии в русскоязычных сообществах и тот факт, что это больная тема.
> В чём-то я тебя понимаю: в своё время я писал на C и думал совершенно так же.
А потом настало время делать хуяк-хуяк-и-в-продакшен, я понимаю. Но это можно делать ничему не учась, как это делаешь ты. Берёшь справочник, читаешь википедию и чистишь - раз-раз-раз.
> советую лекции клоунов, где они рассказывают как решать то, что не является проблемой уже несколько декад, если вы ебанутый, которым вы должны быть, ведь сегодня текущий год, а не какое-то там си
Всё же скажу один психологический принцип. Тем более что дискуссия судя по всему сдохла, ведь мы не увидели ни твоего читаемого ооп-багрепорта (ошибка стоп 00000А это же очевидно как её решить), ни человеческой реакции на декомпозицию abcdefg-dd до двух типов действий во всех случаях.
: человек склонен защищать любое говно, попавшее ему в голову, не зависимо от пути, по которому оно туда попало.
Если бы ты знал заранее, то мог бы критически оценить чушь от епам-клоунов. Но увы.
Характерная деталь клоунов - они никогда не вылезают из iso/osi за уровень приложений, поскольку на других уровнях их говно приведёт к полнейшему пиздецу. Весь интирпрайз украл свой сетевой стек у отсталых сишников.
Ждём пример твоего шедевра в юнити, который лучше "школьных высеров в ворлд едиторе".
>Вася Пукин с дивана рассуждает какую-бы он классную программу написал, если бы Страуструп ему говно в жопу не залил.
> образованный рэволюционер маня не нашла ни своего, ни вообще какого-нибудь относительно местного высера на юнити, который тянул хотя бы на мейз в ворлд-едиторе
>Код становится модульным.
Даже не знаю, как тут спорить. Ну, то есть, суть-то такая, но никто подобного ещё не достиг в реальности.
>При правильной архитектуре через ООП это сделать на несколько порядков проще и быстрее.
По сравнению с чем? Потому что у меня есть немного опыта за пределами ооп, и я могу сказать, что ни в сишном варианте, ни в ецс, ни в функциональщине это не является чем-то сложным. А вот когда тебе нужно поменять что-то более масштабное, то тут-то в ооп проблемы и начинаются.
Алсо, вы, оопешники, сначала бы договорились между собой, что от чего и когда наследовать, а до этого не лезли бы со своими советами туда, где не просят.
>что от чего и когда наследовать
Есть же паттерны (ецс можно туда же вписать), раскуривай да используй.
>сравнивает карту для стратегии и game engine
Ага. Паттерны. И в голову тебе не приходит, что это немного странно, когда приходится обмазываться костылями, чтобы замечательный подход ооп работал. Почему-то в процедурщине и функциональщине нет такого дроча на паттерны как в ооп. Это, наверное, потому, что они являются говном (то есть, позволяют решать задачи там, где оопшникам хочется дрочить на архитектуру). А в итоге у нас в учебнике class Oval extends Shape и Shape oval = new Oval().draw(), а в реальности AbstractSingletonProxyFactoryBean через AbstractAwareTransientConsumerAdapterFacadeFactory; в книжке "ооп - это подход моделирования мира объектами, которые взаимодействуют друг с другом через сообщения методы", а в реальности менеджеры менеджеров, обрабатывающие менежеров менеджеров.
Всё настолько хуёво, что это даже не смешно. Спроси у нескольких оопешников, как правильно string.print(screen) или screen.print(string), и ты получишь минимум четыре разных ответа. Спроси это в публичном месте, и все друг с другом пересрутся, накидают ссылок на "великих мыслителей ооп", но так и не придут к какому-то общему мнению.
>И в голову тебе не приходит, что это немного странно, когда приходится обмазываться костылями, чтобы замечательный подход ооп работал.
Потому что инструмент очень гибкий и с большим количеством возможностей, от этого и разнообразие взглядов, подходов и т.д.
>string.print(screen) или screen.print(string)
Зависит от контекста, очевидно. Надо просто понимать суть, смысл, где и что должно использоваться, и это напрямую связано с пониманием паттернов.
Я вот дипломную на UNITY сделал, как и половина курса.
Съебите в /pr/, тупорылые дегенераты.
Спор двух блондинок о черной материи
>Потому что инструмент очень гибкий и с большим количеством возможностей
Это такой завуалированный способ сказать, что инструментом невозможно пользоваться без этих костылей. В следующий раз пиши прямо, как есть, не стесняйся.
>Зависит от контекста
Охуенно. А завтра к тебе приходит начальник/заказчик/тимлид/геймдиз/друган и говорит, что они там посовещались, и теперь вам нужна вот такая вот йоба. Внезапно, контекст изменился, и тебе теперь всё надо переписывать. Такие-то удобство, модульность, переиспользование кода, и что там ещё было. И это я ещу молчу о том, что у тебя такие фундаментальные вещи "зависят от контекста".
>это напрямую связано с пониманием паттернов
)))))xDDD))))
Чувак, который не осилил ООП и несколько паттернов баттхертит на ООП, вообще найс.
Тебе надо подрасти и книжечек побольше почитать. Программирование это, конечно, весело, но когда дело доходит до больших проектов, то естественно васянам без знаний и опыта его не осилить.
Съеби, жирный.
>черной материи
>ad hominem
>у вас баттхёрт
>вообще найс
>дорасти сначала
>ни слова по-существу
Никого не слушай, пиши на крестах.
От тебя же действительно не было слов по существу, чего бесишься?
Нормально общайся - нормальные ответы получишь.
>NO U!
Тамагочи? Звучит как игра моей мечты.
Были бы пиксели, я б тебе графен делала.
/gd/ - второй /b/, тут по существу редко что когда бывает.
А я идеи для геймлогики могу придумывать (реализовывать тоже могу, если топикстартер отвалится, можем объединиться)
Ок, давай.
> на эдиторе написали доту, первый товердефенс и родили ещё пачку менее рельефных жанров
> думает что эдитор это редактор карт
> все друг с другом пересрутся
При том что баги, как известно, копятся на стыке интерфейсов, написанных разными людьми. Так что эта клоунада в более-менее объёмном проекте будет длиться вечно.
> Тебе надо подрасти и книжечек побольше почитать.
Ты про дристню от епам, торгующего ООП-сертификацией?
> Программирование это, конечно, весело, но когда дело доходит до больших проектов, то естественно васянам без знаний и опыта его не осилить.
ИМХО лучше васян, чем епам-дебил.
Васяну я дал справочник, дал ему пачку юз-кейсов и рыбу теста и через неделю он уже что-то умеет и пишет репорты.
Епам-дебилу я дал пачку юз-кейсов, через день он прибегает с крошащимся комбайном под который хочет место в репозитарии и пишет в багтрек своё мнение о том как надо использовать функции в проекте.
Все с тобой понятно, диванный оппозиционер :)
> а ты! а ты! диванный оппозиционер :)!11
ой всё
Ну да, когда не знаешь предмета разговора и нечего сказать - тогда действительно ВСЕ. Не знаю для чего ты весь этот флуд затеял.
> когда свиня не знает предмета разговора
> это же очевидно как её решить:
> ты диванный оппозиционер!)))))
Ясно.
Эй, мудила. Констракт 2 в руки и вперёд
>Констракт
>написать
ну все, надо писать на констракте теперь
нахуя он вообще нужен?
>Был только с++
самое простое решение apt-get install liballegro5-dev ибо даже первокурсник разберется
Секунду, он же не игру делать собрался. а говноподелку на оценку. С хуёвым знанием программирования. Констракт - лучший вариант. Под любую систему, почти без программирования, лишь бы ООП-парадигму понимал маленько. Там конечно можно самому писать скрипты - но ему не понадобится. И сделать легко, и получится не так уж дерьмово (как, скажем, если он возьмёт базовую графику на тех же крестах и попробует ей тамагочи отрисовывать)
Опять же, если не тамагочи, а, скажем, платформер, то даже логику прописывать не придётся. Кликнул->выбрал->Марио скачет, разбивает блоки, запрыгивает НА платформы и не проходит через солиды.
но ведь он учится на программиста, следовательно обязан продемонстрировать скиллы преподу, показать сорцы на крестах или решетке, как я понимаю
иначе препод обидится, если увидит онли откомпиленный екзешник
wc3 врот эдитор идеальный инструмент для того чтобы констрактить мир и применять свои скиллы программирования любого уровня
даже вов по сути из того же редактора вышел
Тогда две концепции на выбор:
- Тамагочи для детей: милый персонаж, сложно убить, можно учить всяким трюкам
- Тамагочи для двачеров: гипермилый персонаж, легко убить (заболевает при любой твоей ошибке), умирает мучительно.
Берешь SFML под C++ и пилишь игру
> меню создай
> карту создай
> сладкий хлеб создай
> 3,5 кривых примера в паблике на то чтобы посмотреть как оно вообще
Какой-то стрёмный совет для троечника.
а поцчему не иррлихт? за тридэ сразу в зачетку насрут плюсик поставят
> меню создай
SFGUI. Или Qt, только успевай формошлёпить.
> карту создай
Вот тут хз, но вроде есть интеграция с каким-то редактором тайловых карт.
> сладкий хлеб создай
90% уже готово в Thor или SFGUI. Прикручиваются одной строчкой анимации, физика, партиклы, скрипты. Что еще нужно?
> 3,5 кривых примера в паблике на то чтобы посмотреть как оно вообще
У нас разный SFML. У моего - отличная читаемая документация, вменяемый форум, на котором уже сто раз всё обсосали и есть исходники пары-тройки полноценных игр.
Дисклеймер: я его по работе использую для визуализации, так что в нём немного разбираюсь. Игры на нём не писал, хоть и хочется. Но вообще SFML на порядок удобнее SDL и Иррилихта, насчёт SDL2 не уверен, двоякое ощущение от него. Определённо посоветовал бы новичку SFML из всех аналогов.
Берёшь гамак и делаешь на нём тамагочи, всё просто. Если надо именно кодить, пишешь там код на гмл, а не таскаешь либы ассетов. Да и всё равно скорее всего придётся именно кодить.
>Если надо именно кодить, пишешь там dll-ку на крестах, а не дрочишь сраный гмл.
fixed
Курсовая - написать игру.
Задумка сделать тамагочи 2д с простой анимацией и тд.
ПОДСКАЖИТЕ на чем можно написать без проблем(показывать первые заготовки надо в ноябре).
Был только с++ и с#