- foxes
- Постоялец
Stain
> Не просто по техническим причинам, а в первую очередь чтоб ни у кого из команды
> (особенно новичков, джуниоров и *дизов) соблазна не возникло использовать этот
> код "в бою".
а вот это и есть то что я называю "мировозрением", то есть никаких технических проблем нет - просто партия запрещает!
Stain
> Боевое двигло, как продакшен код, должно быть однозначно избавлено от подобных
> вещей.
А я такое представление завернул в отдельную группу/инструмент процедурно-функциональный синтез пытаюсь эту тему структурировать, чтобы это не выглядело фиалкой на полированной поверхности. То есть это уже выдавливается из непосредственного присутствия оригинальных решений в движке, по средством отдельного варианта программного интерфейса. Все это взгляд с боку на организацию движка - охват и вариативность функционала инструментов.
Stain
> Их не две всего, есть и пайпы/файберы, и микроядро, метаслои... куча их.
Ну с этой частью я уже определился и сделал некоего рода вывернутую абстракцию частично реализованную для первого знакомства с движком, и дальнейшим разносторонним конфигурированием, при помощи параметров или замен ключевых точек определяющих последовательность пайпов.
Это уже взгляд с верху на логику модели движка - архитектура.
https://github.com/thesiv/freeengine
обращаю ваше внимание, что лицензия не определена.
the_siv
Кстати. Можешь для всех, чтоб разночтений небыло, дать полновесное описание на лицензии?
Я прекрасно понимаю что это громадная писанина, ссылками отделываться неохота. Мне важно видеть именно понимание лицензий (скажем: GPL, MIT, Apache, BSD), а для этого нужна детализация лично переработанной информации.
Stain
Так в том-то и дело, что я не шарю в open-source лицензиях, как-то не было надобности во всём этом разбираться. Потому и не определена лицензия. Но не только по этому.
Вот есть сам движок, есть его модификации, есть проекты с использованием движка или модификаций. Надо решить:
- можно ли продавать движок/модификации/проекты;
- необходимо ли открывать исходники модификаций/проектов (у движка изначально исходники открыты, но тут тоже могут быть варианты);
На мой взгляд это основные моменты, которые должна обозначать лицензия. Хотя может что-то забыл.
Я считаю, что если нельзя продавать проекты, сделанные на движке, то движок сразу мёртв не родившись, а остальное под вопросом.
the_siv
Продавать надо позволить. Поэтому я и выдвинул примером эти четыре лицензии. Они допускают распространение кода в платных проектах при соблюдении некоторых условий.
Я тоже не эксперт в лицензиях, но кой-чего кое-где черпнуть успел... Чего черпнул, тем и делюсь. :)
MIT :
https://ru.wikipedia.org/wiki/Лицензия_MIT
Лицензия допускает любое распространение и модификацию исходного кода (включая и платные приложения на основе исходного кода) при указании копирайта и пометки об использовании исходного кода.
Лицензия никак не оговаривает методы использования третьими лицами имен разработчиков и/или копирайта в целях рекламы/саморекламы.
MIT совместима с GPLи BSD.
GPL:
https://ru.wikipedia.org/wiki/GNU_General_Public_License
Эта еденица уже интереснее. Фактически, по этой лицензии проект передается в общественное достояние (общественную собственность). Однако, авторство все равно остается за фактическими авторами.
GNU не допускает прямое использование кода в проприетаных проектах. Иными словами, проект, собранный с использованием GPL кода должен быть опубликован под той же GPL лицензией. GPL - штука заразная. :)
Имеется и модификация GPL лицензии - LGPL, в рамках которой допускается использование GPL кода в проприетарном проекте, в качестве "объекта динамического связывания" (или проще - динамической библиотеки).
При соблюдении условия открытости исходного кода, GPL будет совместима с BSD и MIT.
BSD:
https://ru.wikipedia.org/wiki/Лицензия_BSD
По своей сути, BSD - это надстройка на MIT, включающая в себя пункт об ограничении использования доброго имени создателей кода в рекламных или иных целях извлечения прибыли.
Полностью совместима с GPL и MIT.
Apache:
https://ru.wikipedia.org/wiki/Лицензия_Apache
Данная лицензия не ставит условием неизменность лицензии распространения программного обеспечения, и не настаивает даже на сохранении его бесплатного и открытого статуса. Единственным условием, накладываемым лицензией Apache, является информирование получателя о факте использования исходного кода. Таким образом, в противоположность copyleft-лицензиям, получатель модифицированной версии не обязательно получает все права, изначально предоставляемые лицензией Apache. (прям с вики скопировал, лучше и не придумаю)
Это крайне либеральная лицензия, накладываемая исключительно и только на покрываемый ей исходный код и снимающая практически все обязательства с третьих разработчиков.
Эта лицензия полностью несовместима с MIT, BSD и GPL.
Еще есть интересная статья с интересными вопросами по поводу открытых лицензий.
http://geektimes.ru/post/45878/
Я думаю, для движка лучше всего подойдет BSD или MIT. Выбор тут, по факту, стоит между использованием и неиспользованием всего одного пункта (об ограничениях использования имен в рекламных целях).
the_siv
> расскажи общее устройство движка как ты его видишь.
Был ли ты на Девпоинте в 2011 году? Меня туда нелегкая занесла. Там было много всякой фигни про веб-индустрию, сервера и браузеры, про яваскрипт и про пЕхЕпЕ... А еще там Был Андрей Аксенов. Да, этот человек нам более интересен. :)
У Андрея достаточно богатый опыт разработки игр, но, после неминуемой гибели Титаника российского геймдева, он ушел заниматься системой Sphinx - поисковым движком.
У него на девпоинте было два доклада, первый меня не интересовал. Второй же назывался "Прекращаем писать код". И вот к чему я вспомнил это все (Я вообще стал часто ссылаться на Андрея, т.к. этот его доклад хорош сам по себе).
http://youtu.be/LodXWv234Kg?t=3m42s
Вот также и я. Я не знаю как должен выглядеть движок, я знаю как он выглядеть не должен. В смысле, как вдигло выглядеть не должно если двиглом хочется хоть в малой степени гордиться.
Архитектура ни в коем случае не должна быть похожа на cocos2d и прочие похожие. Мешать все на свете в одну кучу ни в коем случае нельзя.
Код не должен быть функционально-ориентированным более чем на 20%, меньше можно (как говаривала госпожа Беладонна), больше - ни-ни.
Архитектура ни в коем случае не должна быть похожа на MOAI (хоть я и уважаю это двигло, но также прекрасно вижу всю его неповоротливость).
Ни в коем случае не стоит увлекаться "шаблонами". Многие это делают, почти всегда это приводит к ужасам. ("шаблон" - это потому что многие люди шаблоном считают постулат или идиому. Различия между ними всеми шириной с Гудзон.)
Все, что могу сказать прямо по существу: так это что движок должен представлять из себя статическую библиотеку (или комплекс из них). Статика должна линковаться в активный модуль, в котором не должно быть ни одной строчки платформозависимого кода. При сборке активного модуля пользователь должен получить исполняемый файл требуемого класса (приложение, динамическая библиотека).
Доклад хороший очень "по мне костюмчик сшит". Но с остальным могу поспорить вплоть до занимания противоположной точки зрения. Но не хочу, в лом надоел весь этот срачь во имя луны. Собственно моя точка зрения исходит из посыла той же лекции. В основном это зависит от конкретики и на конкретном примере ты вполне можешь со мной согласится. Потому что любое утверждение можно разглядеть более глубоко и понять что оно верно только на 50 процентов для половины случаев. Поэтому я бы не стал что то утверждать из за того что можно по разному организовать и саму разработку движка и его внутреннюю организацию и она вполне может быть адекватной удобной и применимой но в корне отличатся от любого утверждения.
Главное с чем бы я согласился это то что для задачи нужно что то утвердительное и в рамках ее проблем можно сказать что нужно, а что нет.
У меня вот код к примеру на 80% платформо зависим, как от ОС так и от железа, при том что 20% это его платформо не зависимая копия. И из всех 100% кода работает только 20%, но не те 20% которые платформо не зависимы, а микс из всего кода и возможно что для некоторых платформ его составляет код из области 80%. Но это только алгоритмическое ядро всего движка, то есть все 100% функционально-ориентированный код. И если развивать мысль как и мой движек, то в полном составе, благодаря внесению дополнительного/основного высокоуровневого функционала, эти 100% превратится в 20% и получится как ты и говорил.
Я делал некоторые тесты, что то на подобии исследования, и для себя пришел к выводу что в принципе весь код может быть процедурным, а непосредственное использование функций может быть обернуто через классы, при этом весь код конечного проекта/приложения написанный с использованием этого движка будет объектно-ориентированным. Возможно это не удобно для написания самого движка, но очень влияет на производительность и объем кода в лучшую сторону. При том что программист видя такой код, долго будет плеваться, быстренько все приведет к надлежащему приемлемому виду, потеряв в 2-10 раз от производительности и увеличив в 3 раза код (и в 10 раз бинарники), экспортировав из основной библиотеки вместо "C" функций классы "C++" или скомпилировав все обертки в отдельную библиотеку. Потом перепишет реализацию на полностью объектно-ориентированную реализацию где код будет плодится практически из ничего. И потом придет к тому что вспомнит лекцию о том как лучше не писать (Прекращаем писать код) и возможно забьет.
Да я не любитель велосипедов, но теперь по крайней мере по примеру Андрея Аксенова уверен что занимаюсь нужным делом, периодически переписывая одни и те же исходники с целью сравнения производительности. Я думаю если этого не делать, то в конечном итоге улетишь в абсолютно не адекватную теоретическую абстракцию, оперируя какими то домыслами.
Ооооочень не хотел это все писать... но не удержался... Заранее согласен со всеми возражениями, но моя жопа видит все в таком ракурсе!
foxes
С твоего поста мне стало казаться что у тебя слабый/неудачный/плохой/отсутствует опыт мета-программирования и статического связывания. :)
Многие люди плюются на плюсы в угоду pure C, пеняя на то, что "никогда Вы не узнаете", что из честного ооп кода "нагенерили и как соптимизили".
Брехня. ООП код легко, при должной красивой организации, ложится в короткие и быстрые инструкции. И только неумелое использование инструментов может привести к описанным тобой результатам.
Поголовное использование функционального подхода, как правило, приводит к "типа-ооп" с функциями, обрабатывающими структуры, и со структурами, в которых лежат указатели на функции.
Это еще один признак, который я не переношу...
Ну все таки статическое связывание тут не причем, а вот громоздить все на сплошном OOП это не есть полный охват всех задач и уровней проектирования.
Да всякое бывало. Есть пример когда нужно отвязаться вообще от языка С при этом либка пишется на ООП C++, а используется где нибудь в С# ява или LUA. Переходы для разных подходов делать не гуд.
Stain
> приводит к "типа-ооп" с функциями
Ну нет ни к чему такому это не приводит, при правильной организации. Это собственно из класса "а да вы не знаете и не умеете". Как минимум это все оборачивается инлайнами. А вот возможность отрабатывать различные элементы обработки объекта с минимальным антуражем вокруг класса, это позволяет, для базовых элементов. В общем это надо видеть.
foxes
Вот скажи что ты тут делаешь, зачем тебе движок? ты же классический адепт вермишельного кода
Stain
Доклад хороший но это на уровне комеди-клаба, если ты вышел за рамки "кто-здесь?" и уже сдал пару проектов коммерческих.
Разработку движка нужно начинать с интерфейсов систем которые мы хотим имплементировать. Это позволит и параллелить работу, и делать позднею оптимизацию, и портирование, это очень и очень удобно.
так вот как определить какие системы и сервисы нужны? для этого нужно поставить цель, минспек - какую игру мы хотим на нем сделать?
давайте сделаем КрестикиНолики, цель ясна.
какие нужны для этого системы и сервисы? кто первый получит приз!)
foxes
> а используется где нибудь в С# ява или LUA.
А можно поподробнее про использование ООП C++ либок в LUA? :)
Stain
> А можно поподробнее про использование ООП C++ либок в LUA? :)
я думаю речь идет о luabind
Stain
> А можно поподробнее про использование ООП C++ либок в LUA? :)
А то типо документации ни где нету?
IROV..
> Вот скажи что ты тут делаешь, зачем тебе движок? ты же классический адепт
> вермишельного кода
Судя по всему теперь уже просто по ржать над людьми которые пишут только на OOП, или только на процедурном языке, или только на скрипте и на друг друга смотрят как на аборигенов из параллельной реальности, с полной уверенностью что только такая реализация является центром вселенной. (Вот такая я забавная бяка)
IROV..
> я думаю речь идет о luabind
гы - вот собственно я и об этом, вам гораздо проще взять клон копию или другую известную/неведанную технологию обвить ее сверх высокими моральными качествами, вместо того чтобы реализовать или использовать простое решение. Поскольку использование этого простого решения в корне противоречит вашим постулатам.
Кроме того сам движек ориентируете как корневой элемент диктаторского влияния на прицип разработки программы, а это инструмент. И если мне как художнику кисточка будет рассказывать как лучше делать штрихи мазки и обводки, а в противном случае вообще перестанет рисовать, то наверно мало кто такой кисточкой что то сможет нарисовать. ( АААА говорящая кисточка - глюки :) )
Неужели не интересе движек позволяющий реализовать качественное программное обеспечение с учетом всех своих единоличных "фи"?
Тема в архиве.