Есть пример программы aseprite, которая есть на github, но также продаётся и в steam. Готовы ли вы выложить код на github, чтобы любой желающий мог понять как ваша игра работает? В таком случае возможно что её никто не будет покупать, все будут качать на github. Я бы например не хотел бы выкладывать код. Пусть мне и нравиться как код написан, но я всё равно не хочу, чтобы кто нибудь его читал и играл бесплатно, кроме меня.
чтобы любой желающий мог понять как ваша игра работает
Если в коде нет какого-то know-how (секретный трюк, о котором мало кто знает), который ты хотел бы использовать в своих будущих проектах – то почему бы не выложить? Уверен, 99% игровых проектов не представляют ценности в плане кода...
Цитатаafq ()
В таком случае возможно что её никто не будет покупать, все будут качать на github
Этого не произойдёт по ряду причин: 1. Многим удобнее пользоваться Steam, даже если это дороже (удобства стоят денег); 2. Про GitHub знают лишь те, кто хоть как-то связан с IT и хоть как-то шарит в ПО; 3. Не всякий даже продвинутый пользователь осилит сборку игры из исходников; 4. Для сборки потребуется установка компилятора, фреймворков и прочей чепухи; 5. Кроме того, если игра хорошая, всегда найдутся те, кто захочет отблагодарить тебя.
Да и вообще, если ты выкладываешь код в публичном месте – это не означает, что ты разрешаешь что-то с этим кодом делать. Ты можешь написать лицензию, которая разрешает "читать и изучать" этот код, но не разрешает его компилировать и напрямую использовать в других продуктах. Разумеется, это будет уже не "open source", но в образовательных целях кому-то да пригодится...
Или, как вариант, может быть лицензия, которая разрешает компилировать и использовать код только в случае покупки приложения, т.е. игроку по закону всё равно нужно сначала купить, прежде чем "качать на github" (ну это для тех, кто любит всё собирать из исходников, даже если есть готовые бинарики).
Цитатаafq ()
но я всё равно не хочу, чтобы кто нибудь его читал и играл бесплатно, кроме меня
ИМХО, если ты выкладываешь код под свободной лицензией, то больше будет проблема от форков, т.е., по сути, клонов игры, которые могут распространяться как и твоя игра (и могут стать лучше и успешнее твоей). Но, опять же, тебя никто не заставляет выкладывать код под свободной лицензией... хотя могу ошибаться (надо почитать правила гитхаба).
Вообще, вся концепция open source, насколько я понимаю, предназначена для того, чтобы люди могли коллективно разрабатывать сложные проекты, использовать чужие наработки для ускорения собственных, поддерживать то, что уже не поддерживается оригинальным автором и т.д. Если переносить на игры, то игра с открытым исходным кодом позволяет любому желающему: – исправить ошибки, которые не исправил автор; – добавить любые возможности и контент, которые не хотел/не смог добавить автор; – убрать или изменить любые имеющиеся возможности и контент; – взять на себя ответственность дальнейшего развития продукта (например, если автор умер); – перенести проект на другую платформу (Windows -> Linux, Linux -> Windows и т.д.); – забрать из игры полезный код, чтобы на его основе сделать совсем другую игру; – и прочее, и прочее. Здесь преимущества в том, что твоя игра не остаётся лежать мёртвым грузом после того, как ты бросил/завершил работу над ней, она будет жить и развиваться до тех пор, пока к ней есть интерес хотя бы одного разбирающегося в разработке ПО человека (или хотя бы одного человека с лишними деньгами). С одной стороны ты теряешь контроль над последующими изменениями игры (не можешь наложить вето на какие-либо изменения), с другой стороны разделяешь контроль над игрой на всё человечество, таким образом увеличивая шансы на её благополучное развитие (если она хоть кому-то кроме тебя интересна). Вопрос в том, чего тебе хочется больше – иметь полный контроль или повысить шансы на выживание?..
Т.е. по сути: Если приоритет на "заработать денег, много денег, а дальше хоть трава не расти" – лучше не выкладывай код. Если приоритет на "подарить человечеству что-то разумное, доброе, вечное" – разумеется, выкладывай код.
Лично я так и не определил свою сторону в этом вопросе. Правда, меня удерживает от окончательного выбора в пользу open source то, что созданное мной может быть извращено, искалечено и использовано с каким-либо злым умыслом... Всё-таки как-то спокойнее, когда никто чисто физически не может внести изменения в то, что ты ценишь (ну в идеале вообще не публиковать, даже бинарики и скриншоты, ага). Но это уже маразм и я пытаюсь с этим как-то бороться)))
ИМХО, если ты выкладываешь код под свободной лицензией, то больше будет проблема от форков, т.е., по сути, клонов игры, которые могут распространяться как и твоя игра (и могут стать лучше и успешнее твоей). Но, опять же, тебя никто не заставляет выкладывать код под свободной лицензией... хотя могу ошибаться (надо почитать правила гитхаба)
Но это насколько простой должен быть проект и насколько упорным должен быть тот, кто над этим кодом строит свой проект
Добавлено (12 Мая 2019, 13:55) --------------------------------------------- Я, например, выкладываю код в надежде на то, что кто-нибудь однажды сделает код ревью и укажет на проблемные места. Для обучения опенсурс отлично подходит.
мой стрим, который я редко включаю, но зато на нём я делаю игры
Но это насколько простой должен быть проект и насколько упорным должен быть тот, кто над этим кодом строит свой проект
Посмотри на: – десятки китайских донатных мобильных ММО, отличающиеся только набором спрайтов и парой фич; – десятки браузерок, построенных на исходниках однажды выстрелившей древней (00-е) браузерки; – десятки "глобальных" модов на игры типа GTA, которые прикидываются самостоятельными играми; – сотни модов на большие и старые игры, которые могут менять оригинальную игру очень сильно; – кучи геймплейно одинаковых мини-игр, созданных для фарма денег с рекламных баннеров. Очевидно, что будет значительно проще делать некоторые проекты на базе готовой игры, чем разрабатывать с нуля или на каком-то универсальном движке. Разумеется, в итоге получится в той или иной степени клон, и чем меньше будет приложено сил и ресурсов, тем более похожим на оригинал будет этот клон, но в определённых условиях это выгодно. Тем более когда автор оригинала сам предоставил права на модификацию и распространение/продажу производных продуктов.
Ну и потом, если у тебя есть идея игры, и два пути её реализации – целиком с нуля (на универсальном движке) или на базе очень похожей готовой игры – естественно будет выбрать второй путь, если тебе разрешает это делать её автор (или тебе пофиг на копирайт и всё такое, как это было принято раньше). Потому что тогда, возможно, достаточно будет заменить контент и написать свои сценарии, вместо того, чтобы самостоятельно прорабатывать рутину вроде загрузки карты, контроля персонажа, ИИ и т.д.
Так что, возможно, брать за основу сложные проекты даже проще, чем какие-то простые, потому что в них всё за тебя уже сделали)
...Окей, это в случае сферического в вакууме проекта, в котором нет лапши вроде "если поменять эту модель, то код сломается в 20 местах, а если перекрасить второй слева пиксель в этой текстуре, то код сломается в 42 местах". Ну и если тебе для твоего проекта не нужно каких-то супер-пупер фич, а только модельки/картинки свои воткнуть и сюжет запилить...
Для меня мой код это что то интимное) У каждого свои тараканы в голове и всё это отражается в коде, большинство кода что я видел или правил вызывало у меня отвращение потому, что не соответствует моим кодовым фетишам и образу мышления) Цитата недели: Из-за леса, из-за гор, кишки, месиво, хардкор. (Берсерк ТВ-2)
Ordan, Обычно это проблемы тех, кто никогда не работал в команде. Я в последнее время пытаюсь идти в сторону шаблонного проектирования, ведь сейчас уже выдумали множество удобнейших архитектур, не говоря уже о различных стандартах оформления кода. Тогда уже и читать чужой код будет удобно, и показывать свой без стыда.
Для меня мой код это что то интимное) У каждого свои тараканы в голове и всё это отражается в коде, большинство кода что я видел или правил вызывало у меня отвращение потому, что не соответствует моим кодовым фетишам и образу мышления)
Люто плюсую. Обычно стараюсь писать код "красиво", вне зависимости от языка, чтоб читать было приятно и понятно. Соответственно видя то, что накодили другие люди – порой хочется просто бросить всё, ибо человечество обречено(
Цитатаmartuk ()
Обычно это проблемы тех, кто никогда не работал в команде
Типа, поработав в команде, становишься таким как все?
Есть пример программы aseprite, которая есть на github, но также продаётся и в steam. Готовы ли вы выложить код на github, чтобы любой желающий мог понять как ваша игра работает? В таком случае возможно что её никто не будет покупать, все будут качать на github. Я бы например не хотел бы выкладывать код. Пусть мне и нравиться как код написан, но я всё равно не хочу, чтобы кто нибудь его читал и играл бесплатно, кроме меня.
Кому надо найдут и прочтут ; ) Например на юнити сейчас каждая третья игра) ну в любом случае оч распространненый движок. Если собран под моно то открыть код игры не сложно.
Скажу больше - еще заинджектить можно разного чтобы интереснее игралось XDD Вопрос твой не имеет смысла ибо выложив проект в доступ ты уже поделился своим кодом.
Цитата
Так что, возможно, брать за основу сложные проекты даже проще, чем какие-то простые, потому что в них всё за тебя уже сделали)
Не проще. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Вторник, 14 Мая 2019, 07:52
Там не очень обдуманно я сделал. Но если подправить, то можно и свои задания сделать. Это я писал когда не мог создать свою файловую систему программно. Выложил код, чтобы любой желающий смог создать уровни.
Щас например у меня ежу есть продуманней игра и с программной файловой системой. Всё никак не придумаю взаимодействие с сетью. В той, которую я выложил сеть была статическая. То есть был адрес в файле и он пинговался. А я хочу сделать чтобы добавил компьютер, подсоединил к узлу, дал ip, и можно пинговать. Чтобы была маршрутизация. Чтобы я мог одним компьютером найти другой за другим роутером. Если у меня это получиться, то создавать новые уровни будет проще простого, а если рассматривать ту игру, которую я выложил, то в ней сложно добавлять новые уровни, да к тому же чтобы создать новый компьютер, надо создать новый файл, потом в этом файле сделать файловую систему. Это всё проблемы, потому что сделать сохранение для такой игры будет накладно. Если не продумать всю архитектуру приложения, то можно накосячить. Да и как ты без общения с автором разберёшься где что добавлять? Как создать новые уровни.
Добавлено (14 Мая 2019, 00:32) --------------------------------------------- Попробуй разберись что я там в terminal.cpp написал.
Типа, поработав в команде, становишься таким как все?
Поработав в команде, ты осознаешь важность стандартов. С точки зрения бизнеса, очень важно когда разработчики на одной волне. Но можешь говнокодить и в соло, никто не запрещает. Вот только код сможешь потом прочесть только ты, и только какой то начальный период. Для этого и придуманы код-ревью внутри компании, где тебе пояснят кто ты и что ты со своим "собственным" подходом.
Если собираешься писать какую нибудь программу/игру один, то можно позволить себе некоторые вольности, я и сам так поступаю. Но крупные проекты пишутся зачастую группой людей, где действительно нужно быть "как все", иначе скорость разработки упадет, а сложность возрастет в разы.
Сообщение отредактировал martuk - Вторник, 14 Мая 2019, 10:19
Раз уж пошёл разговор о стандартах, то непременно советую: 1) "Совершенный код" Макконнелл С. 2) "Building Maintainable Software" (C# Edition/Java Edition), publisher: O'Reilly Media мой стрим, который я редко включаю, но зато на нём я делаю игры
тебя никто не заставляет выкладывать код под свободной лицензией... хотя могу ошибаться (надо почитать правила гитхаба).
На Гитхабе уже даже приватные репозитории можно бесплатно создавать, лицензия уж тем более любая.
ЦитатаTimKruz ()
– взять на себя ответственность дальнейшего развития продукта (например, если автор умер);
Это уже делается форк. Но да, в этом тоже идея опенсорса.
ЦитатаOrdan ()
Для меня мой код это что то интимное) У каждого свои тараканы в голове и всё это отражается в коде, большинство кода что я видел или правил вызывало у меня отвращение потому, что не соответствует моим кодовым фетишам и образу мышления)
Пока это просто хобби, вы фрилансер или предприниматель - оно и нормально. Но в корпоративной среде приходиться адаптироваться. И кстати, умение адаптироваться собственно очень важно для подобной карьеры. Как выше верно сказали - мы работаем на бизнес, а ему нужен хороший пульс команды.
ЦитатаTimKruz ()
Типа, поработав в команде, становишься таким как все?
Если стандарты стоят на каждый оператор и каждый чих - действительно уже армия клонов. Но с точки зрения бизнеса это хорошо.
Так что, возможно, брать за основу сложные проекты даже проще, чем какие-то простые, потому что в них всё за тебя уже сделали)
Не проще.
Ну окей, что проще: 1. Написать 10000 строк кода, предварительно разработав общую архитектуру. Добавить картинки. 2. Выдернуть старые картинки и воткнуть новые картинки. Код никак не изменять. В обоих случаях тебе нужны новые картинки, но во втором случае ты экономишь кучу времени, взяв готовый проект. И чем сложнее этот проект (чем больше возможностей игры реализовано), тем больше времени ты экономишь, не написав ни одной строчки кода. А если этот код написан хорошо – то и времени на добавление нового будет меньше.
Разумеется, я сейчас говорю о тех самых бизнес-проектах, где всё делается ради выкачивания денег. Здесь, как говорится, "все средства хороши", и использовать свободную опенсурсную игру – только снизить риски, которые возникают при обычном воровстве кода.
А если бы речь шла о расширении кода игры, то тут та же ситуация, что и с готовыми игровыми движками. Можно писать целиком с нуля, а можно взять чужие наработки. И тут уж либо изобретать свой велосипед, либо перебирать детали чужого велосипеда. Вопрос только в том, сколько придётся изобретать и сколько перебирать...
Цитатаafq ()
Ну вот мой проект ты мог бы осилить? https://github.com/xverizex/hacker_version
Речь шла про абстрактный, хорошо выполненный проект, а не наброски новичка) Хотя, мне кажется, такой стиль кода характерен для C/C++ (за это я и не люблю вот это всё си-подобное)...
Цитатаafq ()
Попробуй разберись что я там в terminal.cpp написал.
Ну дык, писать разборчиво всегда сложнее, чем абы как. Вспомнилось вот чьё-то высказывание (нагуглить не получилось), что-то типа: «Писать код легко. Сложно писать поддерживаемый код.» Или, как вариант: «Легко написать программу, которую поймёт компьютер. Сложно написать программу, которую поймёт другой человек.»
Конечно, я сам тот ещё "программист", но могу посоветовать следующее: 1. Нужно обязательно разбивать любые большие подпрограммы на маленькие, иначе пока дочитаешь до середины, забываешь, с чего всё началось, где ты и кто ты. В идеале тело подпрограммы не должно содержать больше 6-8 отдельных сущностей, поскольку большее число сущностей мозг удержать во внимании одновременно не может (читая следующую строку, одна из предыдущих "вылетит из головы").
2. Обязательно давать читаемые имена. Даже классический счётчик "i" лучше назвать читаемо, чтобы было понятно, что конкретно он будет считать (например, Row и Column вместо i и j для счётчиков строк и столбцов таблицы). Даже если из самого кода понятно, что может обозначать имя из одной-двух букв, всё равно на мысленный разбор кода будут потрачены время и силы, тогда как читабельные имена распознаются мозгом практически мгновенно. Да, печатать дольше, но лучше потратить больше времени на печать, чтобы сэкономить время на чтении в будущем.
3. Извлекать все константы, не связанные с логикой кода, куда-нибудь в другое место. Лучше в отдельный файл. И обращаться к ним по читабельным именам, а не по индексам. В случае числовых констант гораздо проще понять имя FirstElement, чем разбираться, "почему здесь не ноль?" (не важно, почему так; важно, что это "первый элемент"). В случае текстовых констант (строк) нам требуется знать только то, что "здесь вывод строки GreetingMessage", и не цепляться взглядом за лишнюю информацию, которая содержится в строке (мало ли какое там "приветствие", оно в будущем может на три экрана раздуться, а логика останется прежней).
В идеале в коде вообще не должно быть безымянных констант. Разумеется, если где-то нужен "просто ноль" – называть его "Zero" не нужно, но если этот ноль имеет какое-то важное значение, которое с чем-то связано (мы не зануляем переменную, а присваиваем ей конкретное значение), то нужно показать, с чем это значение связано. Можно, конечно, писать комментарии, но всегда лучше выглядит обращение по имени, чем лишняя строчка комментария.
4. Не делать далеко идущих связей. В идеале, если из твоего кода выдернули одну подпрограмму, то она должна продолжать работать, как будто ничего не изменилось (разумеется, пока известны все вложенные в неё подпрограммы). И самое главное, эта выдернутая из кода подпрограмма должна быть понятна без ознакомления с остальным кодом. Заголовок говорит, что эта подпрограмма делает, тело говорит, как она это делает, и не должно быть необходимости "сбегать в другой файл, чтобы понять, что здесь вообще происходит". Потому что если подпрограмма ничего не говорит о себе без ознакомления с её соседями, можно попасть в ловушку, когда ты уже три часа исследуешь код, пытаясь понять, чем занята первая попавшаяся функция.
Короче, хороший код – это когда ты ткнул пальцем в любую строчку, и уже знаешь, кому она принадлежит, чем занимается и зачем здесь нужна. Но для этого код нужно писать человеческим языком, а не кучей закорючек и спецсимволов. И любой ЯП это позволяет сделать (даже Ассемблер с макросами-вставками).
Да, кстати, есть такая холиварная тема, как "читабельность языков", и многие языки стремятся её повысить (Ada - за счёт многословия, Python - за счёт строгого требования отступов, и т.д.). Вот только на самом деле читабельность кода зависит от того, кто его пишет, а не от того, на каком языке он написан. Невозможно правилами языка заставить программиста давать корректные имена переменным, например. Так что возможные оправдания "я пишу на C++, он по определению сложный" сразу не катят, C++ не запрещает писать код понятно.
А так и я могу скинуть исходники тетриса, который я написал в 2012, и, попытавшись через несколько лет добавить новый пункт в главное меню, сломал вообще всё. При том код компилировался нормально, но в его поведении я так и не разобрался, потому что приходилось бегать глазами по более чем двум тысячам строк))) С тех пор стараюсь такой запутанный код не делать.
Вообще, идеальный ЯП – Forth. В нём нет ничего лишнего, только объявление новых "слов" (команд) из набора имеющихся. Это просто гениальный язык, который может быть таким, каким хочешь. А форт-машина настолько проста, что любой может написать свою с нуля, и начать на ней работать... Плюс, принципы Форта можно использовать на любом другом ЯП (так-то сам по себе Форт не очень применим на практике, несмотря на все преимущества).
Цитатаmartuk ()
Поработав в команде, ты осознаешь важность стандартов.
Их много. У Васи один стандарт, у Пети другой. Как им без начальника сработаться? Мы же тут обсуждаем опенсурс, в котором каждый может притащить кусок своего кода в общий проект, и никто никому не обязан. Кроме того, команда команде рознь, команда школьников без опыта работы – тоже "команда".
Цитатаmartuk ()
Но можешь говнокодить и в соло, никто не запрещает. Вот только код сможешь потом прочесть только ты, и только какой то начальный период.
То есть, по-твоему, если я не могу прочитать чужой код, написанный по стандартам военной секретности*, то я обязательно пишу абы как, без какого-то своего собственного стандарта?
*Имена из одной-двух букв, магических чисел больше чем операций над ними, дёргать глобальные переменные в рандомных местах, подпрограммы на пять экранов, вложенность циклов на три экрана, прыжки по коду через goto (чтобы выбраться из тех самых циклов), использование недочётов языка/компилятора в качестве "оптимизации", принципиальное отсутствие комментариев кроме предсмертных записок и криков о помощи – лишь бы враг не узнал, чем реально занимается эта программа, и всё это выглядит как какой-то негласный стандарт...
Хорошо, хоть автоформатирование придумали. Плохо, что у каждого оно настроено на какую-то свою систему правил.
Цитатаmartuk ()
пишутся зачастую группой людей, где действительно нужно быть "как все", иначе скорость разработки упадет, а сложность возрастет в разы.
А что, если я не хочу быдлокодить как все? Я хочу писать красивый, понятный код. Чтобы его читать было приятно, не спотыкаясь взглядом о всякую фигню. Я бы мог писать частоколом непонятных символов, как это делают все, но зачем мне делать себе же хуже?
Мне кажется, нечитабельный код пишут хейтеры begin..end из алгол-подобных языков. Ведь это они жалуются, что вынуждены писать 8 символов вместо двух. Конечно, быстрее набрать цепочку из спецсимволов, чем текст, но о том, как люди будут это читать (машине-то всё равно), никто почему-то не задумывается...
И я совершенно не понимаю, почему половина человечества мечтает "общаться с компьютером на человеческом языке", а другая общается с этими компьютерами на максимально нечеловеческих языках, несмотря на возможность так не делать... Можно было бы понять, если эти специальные коды было бы легче воспринимать, чем простой текст, но разве это так? Программирование ни разу не математика, мы оперируем реальными вещами (кроме случаев, когда вычисляется математическая формула, но это всегда делается для чего-то, а не просто так), так не надо втягивать сюда огромные формулы из отдельных символов.
Да, у меня бомбит. Да, раньше я допускал те же самые ошибки. Но почему-то я догадался, в чём суть процедурного подхода (назвать кусок кода именем, чтобы он был понятен), а большинство считает это чепухой и продолжает нагромождать безымянные горы команд, говоря "так быстрее".
А ещё кто-то говорит, что, мол, слепой ввод программисту не нужен, скорость печати значения не имеет и т.д. Конечно, когда каждую клавишу ищешь глазами – ни о каких длинных именах и дополнительных конструкциях (объявления подпрограмм) даже думать не хочется, ведь их все печатать нужно.
И не надо про оптимизации, что лишний вызов подпрограммы замедляет программу, что длинные имена занимают больше места на диске и т.д. Мы не в 90-х, а если хотите что-то оптимизировать – скажите это тем, кто берёт огромный фреймворк ради одной примитивной функции, и весь этот фреймворк загружается из интернета в память браузера при каждом посещении сайта. От читабельного кода никто не помрёт, а сведение высокоуровневого кода к набору спецсимволов убивает весь смысл в высокоуровневых языках (хотите непонятности – пишите сразу в машинных кодах, заодно и наоптимизируетесь).
Сорри за многабукв и если вдруг я снова в чём-то заблуждаюсь)
А что, если я не хочу быдлокодить как все? Я хочу писать красивый, понятный код.
Для этого есть корпоративная вики, где описаны правила и приложены ссылки на официальные доки. Если не соблюдать тот или иной стиль кода, то его просто не пропустит git с правильно настроенным валидатором (CI / CD). Каждый грамотный проект, даже если он опен-сорсный и его разработкой занимаются много людей с разных уголков света, должен иметь CI и группу людей, которые модерируют любой ваш коммит.
Добавлено (15 Мая 2019, 10:08) ---------------------------------------------
ЦитатаTimKruz ()
Сорри за многабукв и если вдруг я снова в чём-то заблуждаюсь)
Может быть и заблуждаешься, но я вижу огонь в твоих глазах - и это хорошо!)
Сообщение отредактировал martuk - Среда, 15 Мая 2019, 10:21
1. Каким бы понятным код не казался автору - другие не всегда будут его таким находить, ты то его видишь каждый день и очень долго. В слепую можешь сказать примерно что где. Более того скорее всего уже давно в голове визуализировал ( мнемотехника ). Абсолютно не имеет значения для посторонних как ты пишешь. Ваша группа должна быть на одной волне и писать единообразно. Тем кто работает над конкретным кодом он должен быть "понятен" и не более. Если все адекватно и структуризировано можно разобраться при необходимости в чужом коде даже если ты находишь его "некрасивым". ( Тому кто тебе платит глубоко ***** красивый код или нет )
ЦитатаTimKruz ()
И не надо про оптимизации, что лишний вызов подпрограммы замедляет программу, что длинные имена занимают больше места на диске и т.д. Мы не в 90-х,
Ты очень, очень сильно сейчас заблуждаешься : ) Нормальные люди ( я даже сейчас не применяю это к сфере программирования ) стараются не усложнять себе жизнь. Программиисты тут ничем не отличаются. Но если бы было все так просто все бы писали игры на lua. Ну ты ж не думаешь что одной половине открыто сакральное знание простоты, а эти казалось бы умные программисты зачем-то пишут непонятную простым смертным херь. Просто чтобы позлить другую половину.
Фантазии, амбиции и масштабы игр растут быстрее чем обновляется железо которое на тех же консолях оставляет желать лучшего ( ровно столько сколько надо ).
Оптимизировать все подряд - глупо, но точно не надо принижать труд людей которые делая низкоуровневые вещи позволяют тебе писать так высокоуровнево как ты хочешь : ) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Среда, 15 Мая 2019, 10:22
И не надо про оптимизации, что лишний вызов подпрограммы замедляет программу, что длинные имена занимают больше места на диске и т.д. Мы не в 90-х
Вот поэтому в Стиме так много лоуполи игр и прочие kinda meh graphics, которые грузят мой средний пк (1050, i5-7th) на 90% "Мы ж не в прошлом" не совсем правильный подход.
Делать упор на прошлое тоже не стоит. Конкретный пример в моём первом предложении.
мой стрим, который я редко включаю, но зато на нём я делаю игры
Речь шла про абстрактный, хорошо выполненный проект, а не наброски новичка)
С чего ты взял, что сможешь разобраться в сложном проекте, если даже в моём не можешь? Зайди в main.cpp и посмотри что получилось в итоге, как создаётся всё. И пофиг что не по 18 строк кода функция. Она требует больше строк кода. Лишние вызовы других функций ни к чему. Если для тебя это наброски, то ты просто должен был узнать что как там работает. А я тебе напишу. Потому что ты не поймёшь. Все действия происходят в файлах. Если ты хочешь перейти в другой каталог, то ты переходишь в файле на нужный inode. Как в файловой системе. Чтобы посмотреть файл. Нужно прочитать блок память с размером в 512 байт, если файл занимает больше места, то после это блока памяти будет указатель на следующий блок памяти, который надо прочитать. Я тебе описал часть работы. В коде это можно сделать в единственное варианте, который приходит на ум. Ты бы не понел как что делать. Но зато можно потом легко создать компьютер и добавитть каталоги и файлы.
Добавлено (15 Мая 2019, 14:09) --------------------------------------------- TimKruz, я вот читал исходный код nginx. И что ты думаешь, код хорошего программиста легко читается? Это не совсем так. Там записано его мышление. И зачастую его мысли сложнее понять. Я что-то понимал, но долго читал. Каждую функцию. Вроде бы потом становилось легко понять где и что. Но вот если бы я захотел бы модуль написать к nginx, я до сих пор незнаю как модуль написать.
Добавлено (15 Мая 2019, 14:11) --------------------------------------------- В своей игре я уже сделал мультиязычность, и теперь все тексты беруться из файлов. И данные задаються вот так
Для этого есть корпоративная вики, где описаны правила и приложены ссылки на официальные доки. Если не соблюдать тот или иной стиль кода, то его просто не пропустит git с правильно настроенным валидатором (CI / CD). Каждый грамотный проект, даже если он опен-сорсный и его разработкой занимаются много людей с разных уголков света, должен иметь CI и группу людей, которые модерируют любой ваш коммит.
С этим согласен... Похоже, я пока просто не встречал грамотных проектов) ...ну, или я просто на самом деле немогутор в серьёзное программирование(
Цитатаmartuk ()
Может быть и заблуждаешься, но я вижу огонь в твоих глазах - и это хорошо!)
Хорошо, если это тот огонь, о котором ты думаешь, а не пожар моей депрессии)))) *ещё много якобы весёлых скобочек*
Цитатаpixeye ()
Тем кто работает над конкретным кодом он должен быть "понятен" и не более
Эм, где-то вычитал, что по отношению к коду "красиво" = "понятно".
Думаю, это как-то связано с психологией, ведь нет никаких биологически обусловленных признаков "красивого кода". Вот если ты легко понимаешь конкретный код, то его чтение доставляет тебе удовольствие (в противовес страданию от состояния ЯНИЧЕГОНЕПОНЯЛ при чтении непонятного кода), а то, что доставляет тебе удовольствие — очевидно, должно быть чем-то "красивым", ибо нечто "уродливое" удовольствия как правило не доставляет.
Кстати, если проводить параллель с текстами на естественных языках — всегда приятнее тот текст, что легче читать. Об этом не говорят как о какой-то "красоте", но ведь именно из-за этого в Интернете не принято писать зАбОрЧиКоМ, писать всё сообщение капсом и т.д., потому что читать становится сложнее и неприятнее. В общем, думаю, "красота" и "понятность" тут связаны.
Совсем другое дело, что понятность субъективна, это да)
Цитатаpixeye ()
Тому кто тебе платит глубоко ***** красивый код или нет
Им потом этот код в будущем поддерживать придётся (не лично, а организации, если речь об этом). Что, совсем плевать, какой код поддерживать?
Цитатаpixeye ()
ЦитатаTimKruz ()
И не надо про оптимизации, что лишний вызов подпрограммы замедляет программу, что длинные имена занимают больше места на диске и т.д. Мы не в 90-х,
Ты очень, очень сильно сейчас заблуждаешься : )
Цитатаk0fe ()
Вот поэтому в Стиме так много лоуполи игр и прочие kinda meh graphics, которые грузят мой средний пк (1050, i5-7th) на 90% "Мы ж не в прошлом" не совсем правильный подход.
pixeye, k0fe, я тут опять простыню накатал, но потом одумался. Если кратко: оптимизации кода не должны быть во вред читаемости кода. Какой толк от того, что ты выигрываешь 5 микросекунд на исполнении кода, который не можешь расширить, дополнить, и т.д.? Давайте все просто машинные коды набирать, нам же не нужно потом в этих кодах разбираться... Есть масса способов писать и понятно, и оптимально. Но почему-то люди предпочитают оправдывать свой грязный код мистическими "оптимизациями", в которых они потом сами разобраться не могут...
А игры в стиме такие тормозные, потому что простые движки/конструкторы доступны всем, а технический склад ума и необходимые знания доступны не всем. Сегодня у людей понимание того, чем они занимаются, возникает позже, чем они получают возможность создать новый игровой суперхит и срубить кучу бабла. Потом они понимают, что было бы неплохо улучшить своё творение, но, оглядываясь по сторонам, видят сотни таких же глючных и тормозных проектов, и справедливо решают "ну, раз тут так принято, то зачем мне напрягаться?"... Так что, возможно, во всём этом бардаке виноваты как раз те люди,
Цитатаpixeye ()
которые делая низкоуровневые вещи позволяют тебе писать так высокоуровнево как ты хочешь
Цитатаafq ()
С чего ты взял, что сможешь разобраться в сложном проекте, если даже в моём не можешь?
В твоём я даже суть не понимаю. Ты создаёшь как бы эмулятор ПК, но при этом у тебя в основном работа с файлами выдуманной файловой системы... Ты же на C++ пишешь? Где ООП? Где Computer.Create("zex")?
Цитатаafq ()
Зайди в main.cpp и посмотри что получилось в итоге, как создаётся всё. И пофиг что не по 18 строк кода функция. Она требует больше строк кода. Лишние вызовы других функций ни к чему.
Ты прав. Лишние вызовы ни к чему. Поэтому мой игровой движок максимально прост:
Код
begin GameEngine := TGenGECore.Create(Configuration); GameEngine.Run; end.
Дальше он делает всё сам. Магия? Не думаю)
...сначала транслируется код генерирующего скрипта, затем скрипт генерирует исполнимый код игры, и код передаётся виртуальной машине, которая максимально тупа, но очень послушна. В теории это позволило бы очень легко и быстро моделировать поведение игры и её ресурсы, в то время как компилируемая часть движка оставалась бы без изменений, маленькой и простой. Как-то так работают Форт-машины, но здесь хотелось большей приближенности к играм...
Правда, я это дело забросил на начальной стадии. Транслятор-то у меня есть, и простую машину написать я могу, но у меня не клеится общая концепция движка. Не получается придумать набор инструкций и связи между отдельными машинами (их, по идее, должно быть несколько), а без этого всё становится бессмысленным. К тому же язык генератора, который я придумал, оказался не таким уж универсальным, и без его расширения особо интересного не нагенерируешь (хотя позабавился знатно)... Так что дальше генерации забавных картинок дело с движком не ушло, а тексты генерировать как-то совсем грустно((
Нет, я понимаю, что всё это можно придумать по ходу дела, это ведь не ИИ какой-то, чтобы заранее придумывать от А до Я. Но мотивация никакая. Да и нужен ли мне собственный игровой движок, если я не стремлюсь делать игры?..
afq, а что должно симулироваться на этих твоих виртуальных ПК, у тебя ведь там не настоящие операционки и программы... Неужели целиком весь терминал эмулируешь, со всеми этими dd, man, sudo?.. Мне просто интересно, насколько быстро я мог бы сделать сравнимый аналог на Pascal (со стороны игрока), но разбираться в чужом коде ради этого совсем не хочется)
afq, а что должно симулироваться на этих твоих виртуальных ПК, у тебя ведь там не настоящие операционки и программы... Неужели целиком весь терминал эмулируешь, со всеми этими dd, man, sudo?.. Мне просто интересно, насколько быстро я мог бы сделать сравнимый аналог на Pascal (со стороны игрока), но разбираться в чужом коде ради этого совсем не хочется)
TimKruz, нет, весь терминал не эмулирую. Например, которую щас игру делаю, там есть всего несколько функций. Пока что команда запускается если она присутствует в каталоге /bin. Парсер опеределяет какую команду запустить и запускает с аргументом. У меня реализовано всего несколько простых команд, это переход по каталогам, просмотр файлов, просмотр каталогов. Далее будут ещё реализованы другие команды, в основном для сетевой деятельности. Также реализованые команды ping и трассировки маршрута. В игре будет несколько провайдеров интернета, клиент может быть от другого провайдера. Если я нахожусь у одного провайдера, я не могу пропинговать или отследить маршрут до внутренних серверов другой компании. Но если я взломаю хотябы шлюз или клиента компании, то смогу получить доступ к связи к внутренним серверам. Утилиту ping и traceroute делал несколько дней, около двух. Уделяя почти час на это или больше. То есть я сначала сделал, где-то за день за час или более, но потом через несколько дней обнаружил что не совсем логично сделал, и вот тут то я заморочился. Было сложно врубиться в работе рекурсивной функции, но я всё таки справился. Вот например немного с ошибками, но уже что-то есть из создании интернета. Пока это только тестируется, потом когда доработаю функционал, может быть создание соединений будет ещё упрощено. Пока что у меня надо соединять указывая какой порт подключить к какому. Я сначала делал сеть отдельным проектом, потом просто наследовался от класса, благо в c++ можно множественное наследование использовать.
