Абсолютно необходимые советы из Game Jam Survival Guide

Ludum Dare

Тема — You are the Monster

Картинки взяты с Омского собрания ЛД.

Ремарка для сомневающихся: если вы прямо сейчас не владеете функциональным программированием, и/или уже владеете ООП, не суйтесь в функциональное программирование - весь джем потратите на переобучение. Этим надо заниматься до джема.

Похожие статьи

55 комментариев
Kozinaka
Кажется, под функциональным имелось в виду не функциональное, а процедурное. Короче, классы не нужны, на функциях, глобальных и статических штуках всё быстрее и проще. Это к быдлокоду примета, но действительно проще и быстрее.
Xitilon
Может быть, но — почему тебе так кажется? Есть под рукой исходный текст?
Kozinaka
Потому что функциональное программирование замороченней ООП и гораздо менее распространено.
Xitilon
Нет, это я знаю, и поэтому написал ремарку. Я думал, ты смотрел в исходный код текст и читал там что-то вроде «функцие-ориентированного программирования», а не функциональное.
qb60

Исходный текст:

Tip

Fewer components mean fewer bugs
One large class versus many small ones
A small number of larger source code files instead of many, many small ones
Functional programming versus object-oriented programming
Standalone (compartmentalized) classes vs. many dependencies
AI that uses the same functions as player control
Art assets that spawn gameplay versus hardcoding behaviors or levels
Single platform versus cross-platform codebases
Game engines that require no third-party «plugins»
Compiled games with everything in one exe versus many DLLs
Art creation tool-chain with as few steps to import as possible
Development environments that are all-in-one versus many tools
Solo efforts versus team efforts

Но дальше:

Rebel against conventional wisdom: most of these well-known rules (for example, object-oriented is better than functional programming) work best in large projects that have the luxury of long project lifecycles. The over-engineered codebase is the «ideal» when you can take as long as you want on something. Object-oriented design is fine, but never feels guilty for using a global variable, or a single function that is 20 lines long instead of a generic, abstract OOP class, that requires several new files and a hundred extra lines of «glue code» to work in your project.

Автор использовал чуток не тот термин.

Xitilon
Да, теперь это понятно. Ну, в ГМ вообще нет разных файлов в одном проекте, но количество сущностей может расти в зависимости от кривизны рук мозга кодера.
Hrenzerg
Ну блин, функциональное программирование ни разу не годится для игр. Так скажем неформат. ЯП нужно использовать исходя из задачи. Игра — это штука отражающая в каком-то смысле реальный мир и оптимальнее использовать ООП который зудмывался как парадигма отрадажающая реальный мир. Функциональное программирование нужно совершенно для другого, скорее для отражения и упрощения абстракций таких как бесконечные множества, математические ряды, интерпретаторы и т.д.
Xitilon
Так реальный мир полон математики. Как же все эти спирали с золотым сечением в ракушках, фракталы в деревьях и всяких там колосьях?
сб3

Эй, что вы творите? Вы же тут все мои секреты мастерства перечислили! Особенно в втором списке.

Вот так, наживаешь секреты годами, а потом их разом сливают.

mrrk

Это просто многолетний опыт до которого ты пришёл сам)

сб3

Это просто многолетний опыт до которого ты пришёл сам

Угу, свой опыт всегда ценнее. Потому что в нём уверен, а в советах интернета ты не можешь быть уверенным. Вот я помню показал Козинаке файл исходного кода в полтора мегабайта, он сказал, что таких не бывает. :) Люди не поверят, что это работает, просто не поверят если это не их личный опыт.

Так что в итоге ничего страшного. Люди думают, что это лишь для ЛД хорошие советы, поэтому не станут применять их на полноразмерную игру.

Xitilon
Это был код какой-то твоей игры или нет? Или что-то по работе?
сб3
Движок же, сухарь ванильный.
Xitilon
Правда полтора мегабайта? Это чтоб на дискете места свободного не осталось?
mrrk
Кто-то ещё пользуется дискетами?
Xitilon
Не думаю, но размер символизирует.
qb60
У меня вот Спектрум на дискетах.) Правда, пятидюймовые, по полполтора мегабайта.)
сб3
Уже больше, конечно.
buntarsky
Любопытно, а почему для текста выбран JPEG? FLV же лучше. Или, на худой конец, AVI. They are monsters.
По теме, советы какие-то сомнительные. И речь из контекста, действительно, о процедурном программировании.
Xitilon
Это такой замаскированный вопрос, почему не PNG?
mrrk
Это такой явный вопрос почему не текст)
Xitilon
Ну была уже картинка, не перепечатывать же мне её вручную.
andreymust19
Я молчу про то как обычно сканируют документы и во что сохраняют. Ты бы повесился.
Xitilon
Плюсую. Это печально.
Hrenzerg

Не соглашусь с первыми двумя пунктами первог оманифеста:

1) Иногда лучше сделать игру красивее на ранних этапах чтобы не посеять энтузиазм.
2) Обощённый код иногда очень сильно выручает и позволяет сделать больше контента. Но это уже навык — заранее спроектировать универсальный кусок кода. У меня получается с каждым новым участием в лудуме всё лучше и лучше. Я стараюсь сперв набросать основу и обобщённый фнукционал а потом конкретизировать. Экономлю кучу времени.

В остальном вроде верно начиркано.

Xitilon

1) Серьёзно?
2) Я считаю, обобщённый код должен быть в той части, которая уже взята из ранних наработок. Там — да. Всё новое что пишется — можно и делать обобщённым, но по минимуму. Это ведь получается не рационально — проектируешь систему, приспособленную для разных внутренних механизмов разных игр, чтобы создать… одну игру в конкретный интервал времени. Ты ведь сам ре-используешь старую фигню, и это правильно — вот она действительно должна быть таковой.

buntarsky
Забавно, но совет «пишите под задачу, а не универсально», наоборот, мне показался дельным. Да и «сперва чтоб работало, потом красиво» тоже. А вот что меня смутило:
Если есть выбор — отказывайся от физического движка.
Если мне что-то не нужно, я уже от этого отказался, капитан. А если нужно? Чем можно заменить физдвижок не предложено. Пустой совет.
Как и прочие подобные: не используй то, не используй это, короче делай наипростейшую фигню — зато поучавствовал.
Малое количество файлов исходников.
Свалка кода — это плохая навигация, неудобно редактировать, легко что-то пропустить или незаметить. И замедление времени сборки. Плюсы? Их нет. Вредный совет.
Один большой класс вместо множества маленьких.
Отказ от разбиения кода на отдельные самодостаточные сущности, по сути, нарушает идею инкапсуляции. Которая, как раз, придумана не только, чтобы усложнять разработку «многоклассами», но еще, чтобы облегчать ее, перекладывая проверку ошибок по невнимательности с разгильдяя-программиста на надежный компилятор. Из той же оперы: «процедуры(+структуры) против классов» и, даже, «нетипизированные языки против строготипизированных». Быстрее для прототипирования — возможно. На очень маленьких проектах. С низкими требованиями к непадучести. При большой внимательности программиста. Безбажнее — нет, это мина замедленного действия. А отлов такого характера багов — задачка неприятная и времязатратная. Полезный совет с точностью до наоборот.
Независимость от сторонних DLL.
Остается только гадать, чтобы это значило?
Толи не используйте проверенных временем сторонних библиотек, пишите свои велосипеды. Долго и бажно. Совет вредный.
Толи используйте статически собранные библиотеки, а не динамически. А разница? Чем оно «безопаснее»? Совет пустой.
Толи встраивайте код сторонних библиотек в кодовую базу игры. Тут две проблемы. Настройка сборки чужой библиотеки может быть нетривиальной и затратной в условиях ограниченного времени. (Хотя сейчас много где CMake и Ко, и все не так страшно.) Если библиотека большая — долгая сборка обеспечена. (Несмертельно, да и только в первый раз). Но какой выигрыш «уменьшения багов» от всей этой траты времени? Непонятно. (Разве что, становится удобно редактировать код библиотеки для собственных нужд. Что необязательно еще потребуется). Совет снова пустой.

В общем, советы из разряда «делайте как попало, так быстрее и проще» (и, почему-то, по мнению написавшего, меньше багов). А лучше бы советовали «учитесь писать сразу хорошо — это нетрудно». ИМХО.
andreymust19

На мой взгляд:

Если есть выбор — отказывайся от физического движка.

Имеется ввиду «стараться выбирать идею, для к-й физический движок не понадобится». Это просто еще один компонент игры. Если от него получится отказаться, значит на него вообще не понадобится тратить время.

Малое количество файлов исходников.

Один большой класс вместо множества маленьких.

Если планируется простой геймплей и кода в игре немного, то — да. Если кода будет много — то лучше разбивать на файлы и писать классы. Немного больше времени, зато не будет путанницы из-за пересечения пространства имен.
Не представляю как свои 43 Кб кода я бы писал в одном файле. Да я бы на середине запутался. И искать в одном таком большом файле тяжело и долго.

Независимость от сторонних DLL.

Скорее всего «ваша игра должна все тащить с собой». Если для запуска требуется установить какой-то Visual Studio пак, .NET, OpenAL, либо еще что-то — это вина разработчика. Игрок в такую игру не поиграет с вероятностью 90%. Игрок и так будет играть 1-2 минуты, а у него еще уйдет пара минут на установку какой-то фигни.

Xitilon
Свалка кода — это плохая навигация
Я думаю, автор имел в виду что нужно 10 файлов, а не 100. Граница между свалкой и не свалкой кода может быть разной.
«нетипизированные языки против строготипизированных». Быстрее для прототипирования — возможно. На очень маленьких проектах. С низкими требованиями к непадучести.

Но ведь ГМ не имеет строгой типизации, а ООП в нём можно игнорировать, создав один объект на всё. И что? Очень маленькие проекты? Смешная шутка.

Остается только гадать, чтобы это значило?

С высоты всё того же ГМ (да и почти любого состоявшегося геймдев-движка) это очевидный совет. Если тебе не нужен SUPERSOUND.DLL (реальная библиотека, если что, с которой я работал) для того чтобы играть звуковой файл с произвольного места, а не один раз с начала и до конца, то не используй его. Потому что когда библиотека перестанет работать, ты останешься без звука. Правда, если она таки нужна, то на случай фейла уместно запрограммировать ещё и переключение с неё на встроенную звуковую систему — так будет лучше.

«учитесь писать сразу хорошо — это нетрудно».

Это как раз трудно. Посыл советов в том, что это уже не учёба — это практика. Учиться надо в остальное время, а тут — выдавать что уже научился. Конечно, есть люди, которые и на ЛД занимаются экспериментами — ну, обычно у них ничего особенного и не получается на выходе. А иногда выходит что-то новое.

buntarsky
когда библиотека перестанет работать
С чего бы это так вдруг? Это же не магия какая. Это технология. Есть баги — исправляйте. Хотя нет, лучше библиотек не использовать да код не писать, а то еще упадет ненароком, зашибет кого, а вам отвечать. Багофобия, не иначе.
Так что,
Если тебе нужен SUPERSOUND.DLL
то убедись, что это проверенная временем и открытая библиотека, чтобы редкие возможные ошибки можно было исправить самостоятельно, и пользуйся, ни в чем себе не отказывай.
Согласитесь, совет «используйте то и то» уместнее будет, чем табу «неиспользуйте ничего, от греха подальше»! Свят, свят, свят!
С высоты всё того же ГМ это очевидный совет.
Если качество библиотек для ГМ оставляет желать лучшего, вы выбрали этот кактус, так кушайте его на здоровье.
Но ведь ГМ не имеет строгой типизации
А жаль. Может быть хоть одна из игр, сделанных на нем, удивила бы меня, не упав с непонятной ошибкой через 5 минут с момента запуска. Остается только пожелать ГМ очень внимательных и ответственных программистов, которые исправляют баги, а не делают из них фичи или того хуже.
Это как раз трудно
Трудно, если вы полагаетесь только на себя и свою непогрешимость. Легко, если язык программирования предоставляет вам средства контроля кода (в том числе статическую проверку типов), а вы полагаетесь на принятые для него идиомы программирования.
Конечно, есть люди, которые и на ЛД занимаются экспериментами — ну, обычно у них ничего особенного и не получается на выходе. А иногда выходит что-то новое.
Вот ради этих «иногда» стоит экспериментировать. Странно, что я говорю об этом на сайте, посвященном авторским играм, не находите?
Учиться надо в остальное время, а тут — выдавать что уже научился.
Кто вам сказал? И то и другое. И можно без хлеба.
Xitilon
Я так сказал себе и другим, это моё мнение.
С чего бы это так вдруг? Это же не магия какая.

Смена ОС или конфигурации системы. Баги в чужих библиотеках исправлять — странный совет.

проверенная временем

Не помогает. Да и вообще, то что в IT «проверено временем» — скорее всего уже просто устарело.

Нет никаких библиотек «для ГМ», он использует такие же DLL как и все. Есть разные врапперы, но в них багов обычно нет.

идиомы программирования

Что это?

Странно, что я говорю об этом на сайте, посвященном авторским играм, не находите?

Не-а.

buntarsky
Смена ОС..
Кроссплатформенность — это вообще отдельная тема. Она не имеет отношения к «падучести» конкретной DLL, собранной под конкретную систему (или семейство систем). А как вы собираетесь загружать Windows DLL под Linux, любопытно?
или конфигурации системы.
Что это? Скажем, какое отношение обои на рабочем столе или настройки отображения папок в проводнике могут иметь к библиотеке, работающей со звуковой подсистемой конкретной такой Windows через конкретный такой API?
Баги в чужих библиотеках исправлять — странный совет.
А ничего не делать — вредный. Но участие в конкурсе предполагает, что что-то делать все-таки придется. Третий раз я повторяю эту мысль, но вы ее будто не слышите. Троллите, наверное.
то что в IT «проверено временем» — скорее всего уже просто устарело.

Ну, разве что хипстерские веб-технологии, что плевать хотели на совместимость, на сопровождение, на стандартизацию, могут закрываться/открываться/переписываться хоть каждый день. Там [пока еще?] заправляет юношеский задор и коммерческая смекалка. Системное/прикладное программирование такой «фигней» страдает редко (коммерция только).
Тут никто не спорит, разработка и поддержка библиотек — процесс непрерывный, без конца и края. Но, по моему мнению, это лишь закаляет код, делает его стабильнее и надежнее. Потенциально «опасные» нововведения у серьезных проектов принято разрабатывать отдельной веткой, сохраняя при этом поддержку предыдущей, пока первая не пройдет, да, проверку временем.
А если приглядеться, окажется, «низкий уровень» всех этих новомодных движков лежит на тех самых «устаревших» библиотеках, разрабатываемых уже по 5-10 лет. И ничего. Никто не умер ни от приступа консерватизма, ни от нонконформизмонедостаточности.

Что это?

Надеюсь, у вас Википедию не заблокировали (в свете последних событий).

Xitilon
А как вы собираетесь загружать Windows DLL под Linux, любопытно?

Через Wine, разумеется.

Речь вообще-то шла о новых версиях тех же линеек ОС, но так ещё смешней.

Что это?

Разные версии сборок .NET, DirectX, вообще всего с приставкой Direct-, шейдеров, подсистем аудио и видео типа ASIO, разные файловые системы на носителях разной степени твердотельности, именованные и безымянные каналы связи внутри ОС, мало ли что ещё.

А ничего не делать — вредный.

Такого совета не было. Копаться в DLL с закрытым кодом вовсе невозможно. Пока что таковых я видел большинство.

5-10 лет это нормально. С этой позиции ГМ проверен временем, например. А вот эти ваши C++ — с ними чего только ни происходит в последние годы, я-то видел.

А, так это называется «идиомы программирования». Как обычно, я знаю, что это, но не знаю, как это называется. Можно кодить совершенно разные вещи по-разному, и полагаюсь я на то, как сам пишу код уже который год. О чём тут аргумент-то? Трудно учиться сразу писать хорошо, если полагаешься на идиомы программирования? Из какого кармана это вообще вынуто?

 

buntarsky

Речь вообще-то шла о новых версиях тех же линеек ОС

Под «новые» версии писать будет проблематично в любом случае, если вы не Нострадамус.

5-10 лет это нормально. С этой позиции ГМ проверен временем, например. А вот эти ваши C++ — с ними чего только ни происходит в последние годы, я-то видел.
Не вы ли это все время жалуетесь, что старый ГМ зеленее и голубее нового? Может, ошибаюсь.
А что это там с С++ происходит? Стандарт есть. Реализация не отстает. Язык развивается, стандартная библиотека расширяется. Новые фичи добавляются, взамен старых программистских велосипедов и костылей. Совместимость со старым кодом сохраняется. Все прекрасно с Плюсами. А завтра будет даже лучше, чем вчера. Выбери меня! Чего вы там «видели», ума не приложу.
Трудно учиться сразу писать хорошо, если полагаешься на идиомы программирования?

Что-то вы все с ног на голову перевернули.

Итак, нам нужно реализовать какую-то функциональность для игры.
А) Мы пишем на Гамаке. Библиотекам мы не доверяем: они все бажные, сырцов нет, поддержка платформ никакая, от них одно зло. Отказываемся от физики, от звука, от графики… ОС, кстати, тоже дело ненадежное со своими синими экранами. И Гамак! Мы сырцов его не видели — в нем ошибки, бьюсь об заклад. Не используем, а то вдруг упадет посреди конкурса. Короче, нафиг это все, пойдем пива попьем.
Б) Мы пишем на С++. Пруд пруди отличных открытых библиотек. Делаем как надо. Баги? Исправляем! Игра готова, все как мы задумывали. Все счастливы и умерли в один день.
Как-то так получается, нас послушать.

Xitilon
Под «новые» версии писать будет проблематично в любом случае, если вы не Нострадамус.

Но тем менее проблематично, чем из меньше количества компонентов вообще и чёрных ящиков (сторонних DLL) в частности будет состоять проект. В этом же и была суть аргумента.

Не вы ли это все время жалуетесь, что старый ГМ зеленее и голубее нового? Может, ошибаюсь.

ГМ-Студия постепенно, семимильными шагами раз в год, получает преимущества, которые со скрипом можно обменять на старый ГМ8.1, который они, шельмы, даже убрали с сайта официального для скачивания. Оставив при этом (ха-ха) ГМ7 для Макинтоша. Но будет это уже всё равно не то, в отсутствие реалтаймовой интерпретации.

Но я говорил не про IDE, а про сам язык, GML. Его урезали вместе с переходом на новое IDE, а 90% осталась такой же.

Что до C++, то меняются конвенции, то есть договорённости о том, что синтаксически чем является, и как компилируется. Достаточно задать вопрос «Вы что используете: NULL, 0 или nullptr?», чтобы понять, сколько предстоит возни с кодом ради кода. А код на ГМ не работает только если в нём функция, которой в целевом движке уже нет (так же как и у C++ тоже меняется состав и набор стандартных библиотек).

А) Гамаку в 90% случаев библиотеки вообще просто не нужны (естественно, про 3Д вести речь не будем). Хейзер и другие грамотные ГМщики это могут подтвердить.

Б) Серьёзно, я пытался учить C++. Я пытался кодить на нём. Один раз я даже почти написал игру для GameBoy Advance. А потом я подумал, что за хернёй я маюсь?

buntarsky

Но тем менее проблематично, чем из меньше количества компонентов вообще и чёрных ящиков (сторонних DLL) в частности будет состоять проект. В этом же и была суть аргумента.

Меньше компонентов — меньше возможностей или больше своих компонентов-велосипедов. И то и другое — очень не очень.
Тут еще стоит оговориться, что DLL — это не черный ящик. Это скомпилированная библиотека, у которой может быть вполне открытый исходный код. Изначально, до того как мы нагородили тут новых смыслов, речь шла «компилируй в один exe-шник, не используй DLL», типа так «безбажнее». Но разницы-то нет.

Что до C++, то меняются конвенции, то есть договорённости о том, что синтаксически чем является, и как компилируется.

Что практически не касается конечного потребителя — программиста на С++. Особенно, если он не собирается использовать всех современных возможностей языка. Это проблема разработчиков компиляторов, и пока они с ней успешно справляются (GCC, по крайней мере).

«Вы что используете: NULL, 0 или nullptr?»

В том-то и дело, что С++ очень бережлив до сохранения совместимости. Используйте, что угодно (но лучше nullptr), старый код переписывать не придется.

Xitilon
Меньше компонентов — меньше возможностей или больше своих компонентов-велосипедов.

Мне супер-возможностей не надо, в космос летать не требуется.

DLL — это не черный ящик. Это скомпилированная библиотека, у которой может быть вполне открытый исходный код.

С точки зрения разработчика игр, а не программиста, DLL это нечто, что выполняет нужные или не очень функции для игры. И лезть в это нечто, даже если у него есть открытый код, разработчику игр нахрен не нужно, если он не программист в первую очередь. Поэтому я и не лезу. Игры-то кто будет делать?

А если NULL это переопределённый макрос? Точно не придётся?

buntarsky
Мне супер-возможностей не надо, в космос летать не требуется.
Вам не требуется, другим требуется.
А если NULL это переопределённый макрос? Точно не придётся?
NULL — это и так макрос, унаследованный С++ еще от С. Есть проблемы — с того, кто его переопределил и спрашивайте. Вообще, использование макросов — это всегда на свой страх и риск. Но в общем случае — нет, не придется.
Xitilon

Вам не требуется, другим требуется.

Для ЛД? Для джема на трое суток? Серьёзно?

Xitilon

Вернёмся, короче говоря, на круги своя. У меня есть устоявшаяся практика участия в геймдев-джемах (о чём и тема), причём в неё не входит копание в исходниках DLL-файлов, написание своих DLL-файлов, или тем более написание какого-либо [компонента] движка с нуля. Вы считаете, что тот совет — ерунда, что он вредный, неправильный. Вопрос — сколько у вас участий в ЛД?

У СБ, например, есть его Мухи во тьме. Это было не на ЛД, но параллельно ему и приурочено к нему. Что характерно, господин СБ и ухом не ведёт на это обсуждение!

buntarsky
У меня есть устоявшаяся практика участия в геймдев-джемах (о чём и тема), причём в неё не входит копание в исходниках DLL-файлов, написание своих DLL-файлов, или тем более написание какого-либо [компонента] движка с нуля.
Я уже и так и эдак объяснил, скоро даже сам себя пойму, а вы все про какие-то «DLL-файлы», черные ящики и прочее. Полагаю, что вы просто не понимаете, что такое DLL и с какой стороны к ней подойти, как и тот, кто советует их не использовать. Страх перед неизвестностью.
Объясняю на пальцах. Для игры обычно требуется — окно, картинка, текст, звук. Вы напрямую API системы дергаете? Вряд ли — это долго, непереносимо, хлопотно, бажно (а главное, там тоже эти чертовы dll, только системные). Вы берете распространенные библиотеки/прослойки/движки (libpng/libjpeg/libogg/zlib/pango/openal/glfw/sdl/sfml/clanlib/черта-лысого). Будете вы все это добро в один exe-шник компилять, только потому, что кто-то посоветовал? Нет, вы уже собранное скачаете/установите («sudo pacman -S libSHLYAPA libSHNYAGA libSHNOBEL» или как там у вас в каменном веке Виндах принято — гуглом искать и браузером качать). Ведь это лишняя работа: самостоятельная сборка на всех известных человечеству ее системах (make/cmake/scons/autotools/..), при сомнительных преимуществах для конкурса (вроде ненужного вам ковыряния в чужом коде).
Библиотеки эти уже собраны под конкретную систему (семейство систем) и архитектуру, от «конфигураций» (чего бы то ни было) не зависят. Положите их в папочку с игрой (или даже отдельный установщик сделайте) и будет вам счастье. Какие с ними могут быть проблемы? Вот в чем вопрос.
Вопрос — сколько у вас участий в ЛД?
Участие в ЛД — это такой тест на правоту в любом техническом споре? Да там даже мой кот участвовал с клоном Энгрибердс, но я его пару раз ловил на наглой бессовестной лжи. Но если для вас это так важно, у меня три неформальных участия в ЛД, два из которых я довел до полностью рабочего прототипа. Оба раза я публиковал исходники (и сборки под Лин и Вин) только на Битбакете без анонса на сайте ЛД. Соответственно, в голосовании участия не принимал. С другой стороны, я много раз собирал и линковал в свои проекты свои же библиотеки, собранные как статически, так и динамически, как под Виндоус, так и под Линукс, как с отладочными символами, так и без, как молча, так и припеваючи. Если это чего-то значит. Да! Еще я пою. Правда, отвратительно. Но с большим удовольствием. Так и запишите.
Xitilon
Я в 95% случаев использую просто ГМ, который использует DirectX. В остальных случаях я использую вообще HTML+JS. Никаких исканий Гуглом и качаний браузером. Вот если мне нужен тот самый SUPERSOUND.DLL, то я ищу — внимание — нифига не сам файл. Я ищу дистрибутив со скриптовой обёрткой для GML. Сам файл найти — это ерундовое дело. Ну а там при обёртке он уже точно есть.
Участие в ЛД — это такой тест на правоту в любом техническом споре?

Нет, просто сейчас мы обсуждаем именно его.

…А в чём прикол участия-неучастия в ЛД? Слишком инди?

Отладочные символы я сам включать умею, это понятно всё.

buntarsky
Я в 95% случаев использую просто ГМ, который использует DirectX.
Окей, вы используете Гамак, вам нужен суперзвук, вы берете проверенную SUPERSOUND.DLL, и готово. Или не берете и остаетесь с тухлозвуком. Но тогда и от DirectX (тоже DLL и без сырцов) стоит отказаться, мало ли что случится, делайте в текстовом режиме.
Чтобы убить медведя, идите в лес, но ружье с собой не берите, а то застрелитесь ненароком. А чем зверя тогда убить, руками голыми? Так, правда, безопаснее? Или ружьишко лучше таки освоить? Вся суть.
А в чём прикол участия-неучастия в ЛД?
Да нет никакого прикола. Просто так получается. Либо два дня уходит на придумку интересной идеи, и времени на реализацию не остается. Либо делаю без раздумий, с наскока, в итоге получается неинтересно и неоригинально — смысл такое тащить на голосование. Если бы я проводил конкурс, я б сделал его недельным, тогда: Чт, Пт — идея и план, Сб, Вс — код и контент, Пн, Вт, Ср — лоск и промо. Двух дней мне на что-то стоящее не хватает. Видать, обмазался своими DLL, просвещенных людей не слушаю, и вот результат.
DarkDes

Всю писанину не читал, но что-то подсказывает мне, что, возможно, первоисточник имел ввиду что-то вроде «не начинайте изучать новую библиотеку на ЛД».

Хотя… лучше наделать своих ДЛЛ на каких-нибудь С-ях

Xitilon
Ну если ты метишь на 3Д или яростно-физическое 2Д, то тут я бы ещё поразмыслил. А так думать-то не о чем. К кросс-платформенности кстати тоже непрямое отношение имеет. Чтобы кодить кросс-платформенно, нужно ещё вагон всего читать и проектировать сугубо правильно, приспособленно под абстрактное современное всё.
DarkDes

Ничего не понял что ты написал там

Тут ведь про случаи ДЛЛ==библиотека во время ЛД. Вообще наверно плохая идея что-то изучать на конкурс с таким временем.

Хотя делая Люка Бункера параллельно изучал Юнити и небольшие особенности C#.

Xitilon

Ты ж его не на ЛД делал.

Я написал, что если тебе не нужно 3Д или 2Д с узкоспециализированными системами/расчётами, не надо вообще связываться с подключениями всяких штук — идёт игре только во вред.

DarkDes

Ну да, не ЛД.

Ааа, ну т.е. по сути отказаться «просто потому что могу подключить»? Это наверно было логичным с самого начала.

Xitilon
Ничего не понял что ты написал тут 
DarkDes

Ну в смысле, если нет необходимости в БиблиотекаХ, то и не надо подключать её. Или я не понял суть. Короче. Не пишите комменты — пишите игры

В любой непонятной ситуации говори про создание игр!

Xitilon

Действительно. Если нет нужды и «просто можешь» — не надо этих просто-движений ради простоты и без смысла.

В любой непонятной ситуации говори что тема плохая.

Xitilon
Двух дней мне на что-то стоящее не хватает. Видать, обмазался своими DLL, [...], и вот результат.

Но ведь… Как бы да?..

Ну опять двадцать пять старые споры о том, что ружьишко я уже освоил, но копаться в технологии Майкла Пупкина не собираюсь, вне зависимости от того, открытая она или закрытая (а в мире оружия она таки чаще закрытая [и хорошая], чем открытая [и хорошая]).

andreymust19
По итогам Людума сделал вывод что лучше сделать более короткую, но законченную игру (с графикой, уровнями, музыкой, звуками, вступлением), чем делать прототип, в к-м будет что-то одно. Игра получается более презентабельной.
То есть получается что лучше потратить больше времени на то, что ты плохо умеешь, но чтобы в игре обязательно было, вместо того чтобы бросить все силы на то, что получается лучше всего? Как считаете?
Xitilon
Я считаю, что публиковать нужно игру, в которую уже можно играть. Даром что ранее я сам пихал на ЛД полуиграбельные прототипы — больше этого делать не собираюсь.
andreymust19
Ну это само собой. Игра должна быть играбельной. Просто на мой взгляд стоит равное внимание уделять всем аспектам, а не только одному.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.