что дает исходный код игры
Открытый исходный код — благо или троянский конь?
Сразу хочется сузить рамки — разговор идет о продаже программного продукта (php+MySQL).
Вопрос — (про)давать ли исходный код?
Аргументы в пользу закрытого кода.
— Подавляющему большинству клиентов нужно чтобы продукт работал и исходный код не нужен.
— При закрытом коде проще осуществлять тех. поддержку — клиент своими руками не залезет куда не надо и не породит новых уникальных ошибок, в которых хрен разберешься.
— Сложнее стырить исходный код. А точнее его можно получить, но вот что-то серьезное переделать в этом «исходнике» сложно — максимум сломать защиту, внести незначительные правки.
— Есть некоторая надежда разработчика, что закрытый код спасет от перепродажи его продукта лихими людьми.
— Есть легкая надежда, что купят продукт, потому как «сломать» не смогут, либо «ломанный» побоятся использовать.
— Народ (наш народ 🙂 ) привык что если код открыт, значит бесплатно!
Аргументы в пользу открытого кода.
— Иногда клиенту просто хочется иметь возможность взглянуть на код. То есть не обязательно даже его иметь, но чтобы возможность такая была. Это могут быть параноики безопасности в хорошем смысле или просто борцы за какие-то права.
— Клиент имеет возможность внести правки, причем весьма серьезные. Вплоть до потери совместимости с последующими версиями продукта (хотя вот это возможно уже в минус).
— Нет проблем с дешифратором закрытого кода. Не секрет, что такие проблемы встречаются (отсутствие Зенда и иже с ним, какие-то локальные глюки т.д.).
— Есть возможность построить сообщество разработчиков купивших скажем девелоперскую лицензию с доступом к открытому коду.
Добавлю немного конкретики.
Вопрос «открытого кода» интересует в связи с «внутрифирменной» дискуссией по поводу развития одного из наших продуктов (CNCat). Мы проходили разные стадии (открытый код, Зенд) и сейчас осуществляем обфрускейтивание (замену названий переменных на бессмысленные) и легкую шифрацию. Когда мы давали продукт в открытом коде и давали его бесплатно — много кто тырил код и на его основе делали свои продукты без всяких ссылок на нас. Что было немного обидно и сейчас не хочется на этом обжечься опять.
Однако правильное позиционирование открытого кода (АПИ, поддержка, контроль и т.д.) может дать нам приток сторонних разработчиков новых фич, мощную обратную связь, отладку — в общем новый импульс.
Дык хочется получить какие-то дополнительные аргументы или мысли по данному вопросу. Как бы Вы повели себя как клиент, как разработчик (конечно желательно чтобы Вы им являлись, чтоб не голословно)? Может есть какие в мире устоявшиеся теории и доказанные практикой подходы (типа фри версия закрыта, купленная открыта)?
От жёсткого диска на антресолях до Ransomware: как утекает исходный код игр
В начале июня компания EA сообщила о том, что её серверы взломали хакеры, похитившие 780 ГБ данных, в том числе исходный код игры FIFA 21 и движка Frostbite. Мы решили вспомнить, как на протяжении многих лет утекал в руки хакеров и широкой публики код различных игровых проектов.
Ultimate Mortal Kombat 3
Рекламные материалы порта игры для 3DO. На изображениях использованы скриншоты из версий для Sega Saturn и SNES
В своё время Mortal Kombat 3 получил огромную популярность, поэтому позже была выпущена его дополненная версия под названием «Ultimate Mortal Kombat 3» (UMK3), которую портировали на множество консолей, в том числе на Genesis, Sega Saturn и SNES. Разрабатывался и порт для Panasonic 3DO, но почти завершённый проект был остановлен (вероятно, из-за падения популярности консоли).
В 2010 году пользователь bitrate с форумов AssemblerGames каким-то образом получил диски с исходным кодом и графическими ресурсами порта UMK3 для 3DO. Он поделился с пользователями форума рипнутой графикой, однако исходный код никому не показывал.
Движок Dark Engine (Thief, Thief II, System Shock 2)
В 2006 году моддер игр для Dreamcast под ником game_player_s приобрёл онлайн комплект разработки Dreamcast, надеясь найти на его жёстком диске что-нибудь интересное, однако выяснил, что для подключения комплекта к PC требуется очень редкий адаптер. Спустя три с лишним года он всё-таки нашёл этот адаптер, но тот оказался сломанным. Ему всё-таки удалось изучить жёсткий диск и он нашёл там множество материалов Looking Glass 1996-2000 годов, в том числе и незавершённые порты Thief II и System Shock 2 для Dreamcast. Ещё через пару месяцев он решил проверить содержимое сумки, в которой к нему прибыл devkit. Внутри обнаружился CD с исходным кодом Dark Engine — движка, на котором разрабатывались Thief, Thief II и System Shock 2. Эта находка стала настоящим подарком для сообщества любителей игр компании Looking Glass, благодаря которой с тех пор фанатами было выпущено несколько важных апдейтов игр на движке Dark Engine.
Turok: Dinosaur Hunter
Star Wars Galaxies
В 2003 году Lucas Arts выпустила MMORPG Star Wars Galaxies, несмотря на критику получившую достаточно большую известность (число подписчиков доходило до 250 тысяч игроков). Спустя два года разработчики выпустили обновление, сильно упростившее боёвку и уменьшившую количество профессий, после чего количество пользователей значительно снизилось. Тем не менее, у игры оставались преданные поклонники. В 2011 году было объявлено о том, что проект закрывается в связи с выпуском новой MMORPG в мире «Звёздных войн» Star Wars: The Old Republic. Фанаты SWG, пытаясь сохранить жизнь любимой игры, начали писать эмуляторы серверов. Среди подобных проектов нам интересен один, который является не совсем эмулятором.
Сначала все проекты развивались обычным для фанатских инициатив образом — программисты работали с официальными серверами как с «чёрными ящиками», пытаясь добиться в эмуляторе максимально схожего поведения. Однако в 2013 году от одного из фанатских серверов откололась группа, с которой вышел на связь неизвестный сотрудник компании Sony Online Entertainment (разработчика игры). Этому отчаянному анониму удалось украсть исходный код Star Wars Galaxies в версии 2010 года. Там было практически всё: игровой сервер, клиент, инструменты. Новая группа создала проект SWG Reveniens. Спустя какое-то время из-за трений внутри группы исходный код утёк в открытый доступ. Юридически его использование подпадает под уголовную ответственность и поначалу фанаты опасались санкций Sony Online Entertainment и Lucas Arts, однако теперь проект развивается централизованно и имеет свою страницу на GitHub под названием SWG Source. Сегодня любой может поднять свой сервер Star Wars Galaxies, для этого достаточно только Oracle VirtualBox.
Home Alone 2: Lost in New York
В 2016 году архивист, историк и разработчик видеоигр Фрэнк Сифалди (Frank Cifaldi) обнаружил на старом жёстком диске исходный код версии игры для NES. По его информации, код игры основан на коде других игр по мультсериалу «Симпсоны», тоже разработанным студией Imagineering.
Пользователи форума nesdev изучили выложенные Сифалди материалы и обнаружили там код, документацию и несколько файлов EXE, среди которых были ассемблер процессора 6502, программы для сжатия текста, графический редактор и различные конвертеры. Одному из пользователей удалось частично скомпилировать образ картриджа NES, демонстрирующий экран заставки игры. В коде встречаются забавные комментарии:
«Ниже представлен альтернативный способ выполнения longcall. Примечание: Генри сказал поместить его сюда, но я (Марк Б.) не считаю, что это сработает. Увы, он выше меня по должности.»
Ransomware-атака на серверы CDPR
9 февраля этого года CD Projekt Red сообщила об утечке данных, которые позже были выставлены на аукцион хакерского форума Exploit. Среди похищенной информации были исходный код движка Red Engine, игр The Witcher 3: Wild Hunt, Thronebreaker: The Witcher Tales и выпущенной незадолго до этого Cyberpunk 2077, а также некие внутренние документы компании.
Начальная цена составляла 1 миллион долларов, а в результате торгов лот ушёл за 7 миллионов.
Заключение
Исходный код игр покидает стены компании-разработчика разными путями — иногда по доброй воле создателей, иногда случайно. Бывает, что этому способствуют злоумышленники. В целом, обществу следует стремиться к балансу между интересами частных компаний и сохранением исторического наследия, которое зачастую пропадает из-за убийственной комбинации — защиты авторских прав и пренебрежения прошлым. Нам остаётся только догадываться, сколько игр ушло от нас безвозвратно из-за смены владельцев франшиз, пожаров и банальной очистки винчестеров под новые проекты. Поэтому стоит отдать честь тем людям, которые стремятся бережно собирать и архивировать эту часть истории цифровой культуры человечества. Среди них упомянутый в статье Фрэнк Сифалди, ставший основателем Video Game History Foundation и спасший от забвения множество игр, и Джейсон Скотт, выложивший в Internet Archive и на GitHub исходный код таких игр, как Zork (1977 год), Stargate (1981 год), NBA Jam (1993 год) и Pinball Fantasies (1994 год).
На правах рекламы
Аренда Windows сервера на любом тарифе начиная с 2 vCPU, 4 ГБ ОЗУ и 20 ГБ хранилища. Создайте собственный сервер в пару кликов, максимальная конфигурация — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.
Почему никак не узнать исходный код игры?
Объясните пожалуйста, почему я никогда не узнаю исходный код какой-нибудь игры пока разработчики его сами не выложат в открытый доступ или хакеры его не сольют?
В обычных приложениях его можно узнать через DotPeek, но в большинстве игр нет.
Почему нельзя узнать исходный код, как например достать текстуры из игры?
Почему после компиляции всё?
Если это всё как-то шифруют, то как работает эта шифровка?
Я понимаю вопросы глупые, но объясните мне пожалуйста как дурачку. Я просто не могу этого понять. =(
(Объясните пожалуйста на простых словах, без википедии, я не понимаю что там написано)
Средний 2 комментария
Вот и как голодному студенту узнать рецепт? Да, продукт перед ним. Да, он может расковырять свою порцию, отсортировать кукурузки и нарезку, по форме кубиков узнать каким ножом резали, подсчитать в граммах каждый ингридиент, фигакнуть соус на центрифуге, просветить спектроанализатором на химические элементы, прикинуть примерно из чего оно могло состоять. Но на это уйдет уйма времени и средств.
Потому куда важнее дать пояснение чем просто посмотреть чужой код
Open Source Guides: Запуск проекта с открытым исходником
Предисловие переводчика
Пару месяцев назад на Гитхабе случайно наткнулся на ссылку «Open source guides» и не мог оторваться. Где-то за неделю я внимательно прочитал все 10 разделов. Конечно, я и раньше знал про open source: читал разные статьи (например, «Понять Open Source»), использовал такие проекты в работе, обращался с вопросами к сообществам, сообщал о багах, рыскал в issues и, даже делал неуклюжие попытки что-то улучшать, хотя бы документацию. И само собой, сердцем я был с этими ребятами, которые делятся софтом и знаниями по его использованию. Тем не менее, понятие об open source у меня было скорее смутное и обрывочное. А эта статья добавила ясности.
К тому же, у меня была пара проектов, которые я планировал запустить в этом формате, с надеждой на поддержку сообщества, и со многими сопутствующими страхами и сомнениями, и снова эта статья помогла мне утвердиться в намерении и подсказала практические шаги.
Вне зависимости от вашего отношения к open source, думаю, вы найдёте в этой серии из 10 статей много интересных идей и фактов: организационных, психологических, юридических, этических и технических.
Я дал прочитать этот текст нескольким непрограммистам, они сказали, что всё поняли. А в заголовке статьи я намеренно поставил «исходник» без «кода», потому что данная тема актуальна не только для программистов, а почти для любой интеллектуальной деятельности в формате открытого проекта.
Само это руководство также является open source и уже переведено на 14 языков. Мне выпала честь добавить русскую ветку и перевод первой статьи. Я планирую и дальше переводить по статье в неделю. Если кто хочет подключиться, вот репозиторий: Open Source Guides.
Если вдруг кому-то понадобится заставка из шапки статьи (иллюстрации + русские названия), то она есть в сверстанном виде на codesandbox.io.
Подбор терминов
Я заранее извиняюсь за огрехи в переводе. Некоторые, казалось бы банальные термины, не так легко подобрать на русском. Например, to contribute, pull request, issue, я чаще переводил как «участвовать в проекте, предлагать исправления и вопрос». Open source я пока оставил на английском. Мне уже сделали замечание и выслали ссылку на словарь терминов Гитхаба. Мне не понравилось там обилие транслитерация. Если пустить в статью все эти ишью, пулреквест, пуш, пул, форк, то она станет непонятной для всех, кто не работал с Гитхабом.
Оглавление
Открытый исходный код: что это и зачем?
Итак, вы думаете о запуске своего проекта с открытым исходным кодом (open source)? Поздравляем! Мир ценит ваш участие. Давайте поговорим о том, что такое open source и почему люди это делают.
Что означает «open source»?
Когда код проекта открыт, это означает, что любой может свободно использовать, изучать, изменять и распространять ваш проект для любых целей. Эти разрешения даются через лицензию с открытым исходным кодом.
Преимущество открытого кода в том, что он снижает барьеры для выбора вашей программы и сотрудничества, позволяя людям быстро распространять и улучшать проекты. Кроме того, это дает пользователям возможность контролировать код, в отличии от закрытого. Компания, использующая программное обеспечение (ПО) с открытым исходным кодом, может нанять кого-то для внесения улучшений в ПО, а не полагаться исключительно на решение поставщика с закрытым исходным кодом.
Свободное ПО (Free software) ссылается на те же проекты, что и открытое ПО (open source). Иногда вы можете встретить комбинации этих терминов: «Свободное и открытое ПО» (free and open source software FOSS или free, libre, and open source software FLOSS). Слова free и libre здесь означают «свободное», а не «бесплатное».
Почему люди делают свою работу открытой?
Одно из самых больших вознаграждений, которое я получил от open source — это отношения, установившиеся с другими разработчиками, столкнувшимися с такими же проблемами как и я.
@kentcdodds, «Как мне было здорово войти в Open Source»
Есть много причин почему индивид или организация открывают исходники своего проекта. Вот некоторые из них:
Open source — значит бесплатно?
Бесплатность open source — это одно из его самых больших преимуществ, но не единственное, а скорее — побочный продукт его совокупной ценности.
Поскольку открытая лицензия предполагает, что кто угодно может использовать, модифицировать, и распространять ваш проект почти для любых целей, то в большинстве случаев это подразумевает бесплатность. Потому что, если бы вы просили плату, то люди бы скачивали проект и использовали его бесплатно, абсолютно легально.
Поэтому большинство open source проектов бесплатны, но это не входит в определение open source. Существуют способы взимания платы за проекты с открытым исходным кодом косвенно, через двойное лицензирование или ограниченные функции, но при этом они соответствуют официальному определению open source.
Стоит ли мне запускать свой open source проект?
Краткий ответ — да, потому что независимо от результата, запуск своего проекта — это хороший способ понять, как работает open source.
Если вы никогда прежде не запускали подобных проектов, вы можете переживать: «что скажут люди?», «а вдруг вообще никто его не заметит?». Если вам это знакомо, не беспокойтесь, вы не один такой!
Open source, как и любая творческая работа, будь то писательство или рисование, вызывает волнение прежде чем поделиться ей с миром. Но единственный способ улучшить её — практиковаться, даже если у вас не будет аудитории.
Если вы ещё не решились, найдите время подумать о ваших возможных целях.
Постановка целей
Цели помогут вам определиться, над чем работать, от чего отказаться, и где вам понадобится помощь со стороны. Спросите себя: «зачем я опенсорсю этот проект?».
Единого ответа на этот вопрос не существует. Вы можете иметь много целей для одного проекта, или разные проекты с разными целями.
Если ваша цель просто показать свою работу и нет нужды в сотрудничестве, вы можете так и написать в файле README. С другой стороны, если вы заинтересованы в помощниках, то вам следует вложить своё время в написание понятной документации и проявлять заботу о новичках.
mavris@mavris, «Программисты самоучки: Почему Open Source важен для нас»
По мере роста проекта ваше сообщество будет нуждаться не только в коде. Ответы на вопросы (issues), проверка кода, распространение информации о себе — всё это важные задачи open source проекта.
Хотя количество времени на непрограммистские задачи зависит от размера и масштаба вашего проекта, вы должны быть готовы решать их сами или найти для этого помощника.
Если вы — часть компании, запускающей open source проект,, убедитесь заранее, что вы имеете внутренние ресурсы для его развития. Назначьте ответственного за сопровождение после запуска и определите, как будут распределяться задачи внутри сообщества.
Если вам нужен выделенный бюджет или персонал для продвижения, эксплуатации и поддержки проекта, обговорите это как можно раньше.
@captainsafia, «Чё, хочешь открыть код проекта?»
Участие в чужих проектах
Если ваша цель — понять как взаимодействовать с другими и как работает open source, рассмотрите возможность участия в уже существующем проекте, который вы используете и любите. Вашим участием могут быть такие простые вещи, как исправление опечаток и обновление документации.
Если вы не понимаете, как начать участие в чужом проекте, ознакомьтесь с нашим руководством Как участвовать в open source проекте.
Запуск собственного open source проекта
Нет идеального момента, чтобы открыть исходники своей работы. Вы можете открыть их на стадии идеи, в процессе работы или после нескольких лет закрытости.
В общем случае, открывать исходники можно, когда вы чувствуете себя уверенно настолько, чтобы показать свою работу посторонним людям и получать их отзывы.
Каждый проект вне зависимости от стадии, на которой вы решили открыть исходники, должен иметь следующую документацию:
Если ваш проект на Гитхабе и вы разместите эти файлы в корневой категории с рекомендованными названиями, Гитхаб распознает их и будет автоматически отображать для ваших читателей.
Выбор лицензии
Лицензия для открытого исходного кода гарантирует, что другие могут использовать, копировать, изменять и вносить правки в ваш проект без каких-либо последствий. Она также защищает вас от неприятных юридических ситуаций. Вы должны включить лицензию при запуске проекта с открытым исходным кодом.
Юридическая работа — не из легких. Но есть хорошие новости: вы можете скопировать существующую лицензию и разместить её в своём репозитории, за одну минуту защитив ваш тяжелый труд.
MIT, Apache 2.0, и GPLv3 — это самые популярные лицензии, но есть и другие варианты для выбора.
Когда вы создаёте новый проект на Гитхабе, вам дается на выбор несколько лицензий. Выбрав open source лицензию, вы сделаете свой проект — открытым.
Если у вас есть другие вопросы или беспокойства относительно юридических аспектов open source, мы описали их здесь.
Составление README
Файл README («прочитай меня») не только рассказывает, как использовать ваш проект, но и объясняет, почему он важен, и что пользователи могут с ним делать.
Постарайтесь ответить в README на следующие вопросы:
@tracymakes, «Писать так, чтобы ваши слова читали (видео)»
Иногда люди откладывают написание README, потому что чувствуют, что проект не завершен, или не хотят принимать доработки других людей. Но это как раз хороший повод написать об этом.
Когда вы добавляете файл README в корневую директорию проекта, Гитхаб автоматически отображает его на главной странице репозитория.
Написание руководства для участников
Файл CONTRIBUTING говорит вашей аудитории, как стать участником вашего проекта. Например:
В первую очередь хотим выразить вам благодарность за то, что подумываете об участии в развитии Active Admin. Именно такие люди как вы делают Active Admin прекрасным инструментом.
На ранних стадиях проекта ваш файл CONTRIBUTING может быть простым. Вы всегда должны объяснить как сообщать об ошибках и оформлять вопросы, а так же описать технические требования к правкам участников (например, тесты).
Со временем вы можете дополнить его ответами на часто задаваемые вопросы. Благодаря этому меньше людей будут спрашивать вас об одном и том же снова и снова.
Чтобы вам было проще составить файл CONTRIBUTING, ознакомьтесь с @nayafia’s шаблоном руководства по сотрудничеству или mozilla’s «Как составить файл CONTRIBUTING.md».
Поставьте ссылку на файл CONTRIBUTING внутри README, так больше людей увидят его. Если вы разместите файл CONTRIBUTING.md в корне вашего проекта, то Гитхаб будет автоматически ссылаться на него, когда кто-то открывает новый вопрос (issue) или добавляет правку в проект (pull request).
Разработка кодекса поведения
@mlynch, Делаем open source более счастливым местом
В итоге, кодекс поведения задаёт базовые правила поведения для участников вашего проекта. Это особенно важно, если вы запускаете проект для компании или сообщества. Кодекс поведения способствует установлению здорового, конструктивного поведения в сообществе, что снижает стресс для вас, как для ответственного за проект.
Помимо описания каким вы хотите видеть поведение участников, кодекс поведения также разъясняет, к кому и когда он применяется, и что будет в случае его нарушения.
По аналогии с лицензией, вам не обязательно писать кодекс самим, а можно скопировать один из существующих вариантов. Соглашение участника используется в более 40,000 open source проектах, включая Kubernetes, Rails, и Swift. Какой бы кодекс вы не использовали, вы должны быть готовы применить его при необходимости.
Поместите файл CODE_OF_CONDUCT.md в корень вашего проекта, так его будет проще находить и ссылаться на него, например, из README.
Именование и брендирование вашего проекта
Брендирование — это не только броский логотип и запоминающееся название, но и то, как вы говорите о своём проекте и до кого доходит ваше послание.
Выбор правильного названия
Выберите название, которое легко запомнить и, в идеале, даёт представление о сути проекта. Например:
Выбирайте в пользу понятности. Каламбуры могут быть забавными, но подумайте о людях из других культур или с отличным от вашего опытом, которые могут не понять шутку. Ваши потенциальные пользователи могут быть работниками компаний, которые будут рассказывать о вашем проекте начальству. Не заставляйте их краснеть при этом.
Конфликт имён
Проверьте наличие open source проектов с таким же названием, особенно если вы используете один и тот же язык или экосистему. Если ваше название совпадёт с популярным существующим проектом, вы можете запутать свою аудиторию.
Если вы планируете завести сайт, твиттер или любую площадку для публикаций, убедитесь, что нужное вам название там свободно. И лучше зарезервируйте эти имена сейчас для душевного спокойствия, даже если пока не планируете ими пользоваться.
Убедитесь, что вы не посягаете на торговую марку какой-нибудь компании. В будущем она сможет попросить вас закрыть проект или даже подать в суд. Это неоправданный риск.
Вы можете проверить конфликт брендов по всемирной базе брендов WIPO. Если вы делаете проект от лица компании, то юридический отдел может помочь вам с этим.
Напоследок, сделайте быстрый поиск в Google по названию вашего проекта. Смогут ли люди по нему легко найти ваш проект? А может быть, по этому запросу появляется что-то нежелательное?
То, как вы пишите (и кодите) тоже влияет на ваш бренд!
За всю жизнь проекта вы будете много писать: README, руководства, документы сообщества, ответы на вопросы, возможно даже информационные бюллетени и списки рассылки.
Будь то официальная документация или обычное сообщение, ваш стиль письма — это часть бренда проекта. Подумайте о том, в каком свете вы выглядите перед аудиторией, и правильный ли подобрали тон.
@janl, CouchDB, «Устойчивый Open Source»
Добрый и вежливый язык создаст приятную атмосферу для новых участников. Следите так же за простотой изложения, так как для многих читателей английский может быть не родным.
Не только слова, что вы пишете, но и стиль кода может стать частью бренда вашего проекта. Angular и jQuery два примера проектов со строгими стилями и рекомендациями.
Нет необходимости составлять руководство по стилю, когда вы только начинаете, и в любом случае вы наверняка захотите включать в свой проект разные стили. Но вы должны заранее понимать, что ваш стиль письма и кода будет привлекать одних людей и отталкивать других. Ранние стадии проекта — это возможность создать прецедент, из которого будет расти проект в желаемом для вас виде.
Проверочный лист перед запуском
Вы готовы открыть свой проект? Вот вам проверочный лист в помощь. Когда отметите все пункты, нажмите «опубликовать» и похвалите себя.
Документация
Если вы частное лицо: