- aml
- Постоялец
crazy_miner
> outcast
> Не назовете проекты разработанные вами в которых,
Если бы я хотел их назвать в заголовке была бы ссылка.
> все было "статистически точно проверено" и смоделировано?
Статистически и точно не бывает. "Статистически" можно гарантировать, например, что в 80 случаях из 100 ИИ сработает удовлетворительно, а в 20 оставшихся нет. Очевидно что кручение коэффициента в скрипте такой гарантии не дает.
> > вас тестеры сами правят баги?
> Баги очевидно правит, тот кто их сделал.
"А махать лопатой это у Q&A задача такая, им за это деньги платят." - это о чем было, просто поддержать разговор? :)
outcast
> > outcast
> > Не назовете проекты разработанные вами в которых,
> Если бы я хотел их назвать в заголовке была бы ссылка.
>
> > все было "статистически точно проверено" и смоделировано?
>
> Статистически и точно не бывает. "Статистически" можно гарантировать, например,
> что в 80 случаях из 100 ИИ сработает удовлетворительно, а в 20 оставшихся нет.
> Очевидно что кручение коэффициента в скрипте такой гарантии не дает.
Тоесть как я и говорил ранее, это была очередная "торетика кайфа в стране фиолетовых эльфов", тогда к чему это все было, просто поддержать разговор?
outcast
> > > вас тестеры сами правят баги?
> > Баги очевидно правит, тот кто их сделал.
> "А махать лопатой это у Q&A задача такая, им за это деньги платят." - это о чем
> было, просто поддержать разговор? :)
Это было о разделении труда - одни лопатой машут, другие снег вывозят.
Z
> Тоесть, появилась необходимость сделать что-то на VB и програмист по
> идеологическим причинам отказъвается?
> Ну, я надеюсь с такими програмистами не повстречатся в професиональном плане,
> ето ахтунг.
Не, не нужно подменять одно на другое :) А то так мы договоримся что наняли как программиста, а заставляют моделить и текстурить, а он отказывается - значит не профессионал, лол.
Если программиста наяли на вакансию "программист С++ /C#", а в итоге он занимается скриптописанием на Lua как _основной работой_ - я об этом говорю. А не о том что иногда нужно что-то поправить в скрипте или там при сдаче этапа поправить баги/сделать нормально какие-то части скрипта.
>
> > Непонятно какой смысл более-менее нормальному программисту,
> > переквалифицироваться в скриптовика.
> Никто не заставляет переквалифицироватся, но если надо сделать работу, то
> хорошо ето делать в самой удобной для етого среде. Если ето не родной C++,
> тогда что - отказъватся работать?!
Обычно круг работ оговаривается при найме или там при старте нового проекта.
> Решения с чем работать, они кстати не индивидуальнъе. Т.е. не индивидуальнъе,
> если охота остатся в рамках канторъ конечно...
Понятное дело что такие вопросы решает не сам работник. Но согласись, что нанять человека со знанием одного языка программирования, а заставлять его писать на другом, ну как минимум странно ;)
crazy_miner
> Тоесть как я и говорил ранее, это была очередная "торетика кайфа в стране
> фиолетовых эльфов", тогда к чему это все было, просто поддержать разговор?
Да всем пофиг на твои фантазии, расслабься :)
crazy_miner
> > "А махать лопатой это у Q&A задача такая, им за это деньги платят." - это о
> > чем
> > было, просто поддержать разговор? :)
> Это было о разделении труда - одни лопатой машут, другие снег вывозят.
Сморозил хрень неподумав, бывает. Зачем вилять теперь?
outcast
Очередное, тупое хамло? Откуда же вас столько на ресурсе-то развелось....
crazy_miner
> Очередное, тупое хамло? Откуда же вас столько на ресурсе-то развелось....
Угомонись уже и не засоряй пожалуйста тему всекой хренью.
> Еще раз повторю: скрипты могут быть заменой редактору (или части редактора). Но _при наличии нормального редактора_, их ценность сомнительна. Так понятнее?
Не понятнее. Каким образом скрипты могут заменять редактор? Главное зачем их противопоставлять? Вы вообще о каких редакторах говорите?
> Напомню, изначальное ваше утверждение было - что скрипты нужны _в редакторе_. Хотелось бы узнать зачем?
Нет, я такого не утверждал. Мы, видимо, не поняли друг друга.
Я пишу только про скрипты в игре. Для того, чтобы они работали, они должны как-то попасть в движок. Будет это через редактор или нет - разницы никакой.
> Это как минимум спорное утверждение - и про ошибки и про размер кода.
> Размер кода на универсальном скрипт языке (Lua, Python и т.д.) не сильно меньше чем на С++, C#. А если учесть поддержку и то что большая часть функционала сосредоточена в функциях на "низкоуровневом языке", то разница не существенная.
1. Высокоуровневый код на скриптах будет раз на порядки компактнее, чем на C++. Экспериментальный факт. Просто пример приведу на скрипте: if gui.confirm("Вы уверены, что хотите купить этот товар"?)): if member.money_debit(price, currency): item.transfer(member, "buy") else: gui.alert("Недостаточно средств в данной валюте") . Как будет выглядеть аналогичный код на C++, вы и сами можете представить. Не нужно представлять скрипты как говнокод, который пишет говнопрограммист. Ровно тот же самый программист движка может писать и скрипты - нет ничего зазорного, чтобы в уместной ситуации использовать уместный инструмент.
2. большая часть функционала сосредоточена в функциях на "низкоуровневом языке" - это, как минимум, спорно. После реализации основного игрового движка (визуализация, сеть, взаимодействие объектов и прочая инфраструктура) начинается собственно программирование игры. И там таких мелких задач типа "купить в магазине" уйма. Если весь этот функционал реализовать на C++, его объём будет, как минимум, сравним с движком, а скорее всего на какой-нибудь RPG будет в разы превышать.
> Может это конечно мне не везло, но я ниразу не встречал чтобы изначально скрипты писал более-менее толковый программист, или вообще программист :)
Это вам точно не повезло :) Скрипты - супер-мощный инструмент. Пренебрежение им выглядит очень странно.
aml
> Нет, я такого не утверждал. Мы, видимо, не поняли друг друга.
Я понял вашу фразу как "редактор лучше написать на скриптовом языке". Если это не так, ну тогда и вопроса нет :)
> Я пишу только про скрипты в игре. Для того, чтобы они работали, они должны
> как-то попасть в движок. Будет это через редактор или нет - разницы никакой.
По этому вопросу естественно возражений нет.
aml>
> 1. Высокоуровневый код на скриптах будет раз на порядки компактнее, чем на C++.
> Экспериментальный факт. Просто пример приведу на скрипте: if gui.confirm("Вы
> уверены, что хотите купить этот товар"?)): if member.money_debit(price,
> currency): item.transfer(member, "buy") else: gui.alert("Недостаточно средств в
> данной валюте") . Как будет выглядеть аналогичный код на C++, вы и сами можете
> представить.
Выглядеть он будет (может) в точности так же, с поправкой на наличие скобок и другие особенности синтаксиса С++.
Или вы думаете что функции transfer(), money_debit(), confirm() каким-то чудесным образом в скрипте сами по себе реализуются? :)
aml
> Не нужно представлять скрипты как говнокод, который пишет
> говнопрограммист. Ровно тот же самый программист движка может писать и скрипты
Я не утверждаю что "программист движка" не может писать скрипты, вполне может и даже наверное их писал когда был юниором :)
> - нет ничего зазорного, чтобы в уместной ситуации использовать уместный
> инструмент.
Самая уместная ситуация для этого инструмента - можно нанять работника с меньшей зарплатой и он сделает ту же работу что и работник с большей зарплатой на нативном языке.
Нанять работника с большей зарплатой чтобы он делал работу которую может сделать работник с меньшей зарплатой - это благотворительность или отсутсвие здравого смысла с точки зрения бизнеса :). Ну никто же не нанимает докторов наук чтобы они подметали улицы, хотя теоретически это возможно, но крайне неэффективно.
> 2. большая часть функционала сосредоточена в функциях на "низкоуровневом языке"
> - это, как минимум, спорно. После реализации основного игрового движка
> (визуализация, сеть, взаимодействие объектов и прочая инфраструктура)
> начинается собственно программирование игры. И там таких мелких задач типа
> "купить в магазине" уйма. Если весь этот функционал реализовать на C++, его
> объём будет, как минимум, сравним с движком, а скорее всего на какой-нибудь RPG
> будет в разы превышать.
Это беспредметный разговор, т.к. реализовать можно по разному: можно чтобы на С++ было больше, можно чтобы на скриптовом языке было больше кода (это гораздо более вероятно), это зависит от массы разных обстоятельств.
Преимущества скриптового языка находятся не в области меньшего объема кода, выше по треду Z написал где :)
> > Может это конечно мне не везло, но я ниразу не встречал чтобы изначально
> > скрипты писал более-менее толковый программист, или вообще программист :)
>
> Это вам точно не повезло :) Скрипты - супер-мощный инструмент. Пренебрежение им
> выглядит очень странно.
Не вижу связи моего высказывания с вашим, или вы считаете что в руках дизайнеров этот мощный инструмет теряет свою мощность, хреновый тогда инструмент наверное? ;)
outcast
>Это беспредметный разговор, т.к. реализовать можно по разному: можно чтобы на С++ было больше, можно чтобы на скриптовом языке было больше кода (это >гораздо более вероятно), это зависит от массы разных обстоятельств.
Если в скрипте неявная работа с памятью и динамическая типизация, то там кода будет меньше, чем в аналогичном по функциональности C++.
В Lua есть еще инструментъ, которъе делают код короче - локальнъе функции, возможность создать где угодно таблички и наполнить их чем угодно.
В C++ писать код так влобно и локально не получается.
Z
> Если в скрипте неявная работа с памятью и динамическая типизация, то там кода
> будет меньше, чем в аналогичном по функциональности C++.
В целом согласен, но "в умелых" руках получается больше чем на С++.
> В Lua есть еще инструментъ, которъе делают код короче - локальнъе функции,
> возможность создать где угодно таблички и наполнить их чем угодно.
Насчет таблиц согласен, хотя мы последнее время юзаем для таблиц эксель + экспортер в свой формат, который юзается из С++. Это получается гораздо более наглядно и редактируемо чем скриптом/конфигом, особенно для больших таблиц.
Насчет локальных функций не совсем понял в чем смысл?
> В C++ писать код так влобно и локально не получается.
Это имхо от архитектуры зависит сильно и от тех кто пишет, если я правильно понял что такое "влобно и локально".
outcast
> Насчет локальных функций не совсем понял в чем смысл?
x = function() .... end
Метод имеет аргумент функцию - берем и создаем прямо на възове метода, если надо.
> Это имхо от архитектуры зависит сильно и от тех кто пишет, если я правильно
> понял что такое "влобно и локально".
Как ни крути, так влобно и локально как в скрипте не получится на C++ - надо типъ декларировать явно и все кода, надо функции въносить из других функций, таблички не насоздаеш как угодно, ибо не core фича язъка (только для POD типов).
Z
> x = function() .... end
> Метод имеет аргумент функцию - берем и создаем прямо на възове метода, если
> надо.
>
Ок, понял. Хотя пока не сообразил для чего такое нужно и чем оно лучше
declare x;
{
x = ... здесь ведем расчет;
}
:)
Или эту функцию потом еще звать откуда-то можно?
> > Это имхо от архитектуры зависит сильно и от тех кто пишет, если я правильно
> > понял что такое "влобно и локально".
> Как ни крути, так влобно и локально как в скрипте не получится на C++ - надо
> типъ декларировать явно и все кода,
> надо функции въносить из других функций,
Ну это двоякое дело, с одной стороны неудобства создает, с другой способствует качеству кода, т.е. пока выносишь функцию - подумаешь зачем она нужна и что делает.
С типами тоже, я бы в минуса типизацию не записывал. Хотя для дизайнеров пишущих скрипт это конечно плюс :)
> таблички не насоздаеш как угодно, ибо не core фича язъка (только для POD
> типов).
Таблички в коде/скрипте это имхо зло всетаки, т.к. их потом искать нужно если что подправить, да и график там построить по ним или перевычислить коэффициенты - неудобно. А не дай бог еще там какие данные от локализации зависимые. Эксель в этом смысле дает фору и скрипту и нативу.
outcast
> Или эту функцию потом еще звать откуда-то можно?
А как угодно. Ето может бъть callback, функция-мембер и прочее.
> Ну это двоякое дело, с одной стороны неудобства создает, с другой способствует
> качеству кода
Ну, назъвать отсуствие фич - каким то плюсом язъка я бъ не стал. Его нет - точка. Делать локальнъе функции нельзя и все тут. А они удобнъе, код нагляднее (сразу видно scope) и т.д.
> С типами тоже, я бы в минуса типизацию не записывал. Хотя для дизайнеров
> пишущих скрипт это конечно плюс :)
Да какие блин дизайнеръ, не видел в жизни дизайнеров, которъе бъ писали на скрипте... У нас один из лидов пересел на скрипт уже как год - просто бъстрее игровой код там писать, логику всякую и прочее.
> Таблички в коде/скрипте это имхо зло всетаки,
Я не про таблички с какими то игровъми даннъми. Разумеется их руками писать никто не захочет.
Табличками примерно можно хоть параметръ функции подавать - в раз удобней, чем их явно расписъвать, примерно когда куча default параметров.
> Выглядеть он будет (может) в точности так же, с поправкой на наличие скобок и другие особенности синтаксиса С++.
> Или вы думаете что функции transfer(), money_debit(), confirm() каким-то чудесным образом в скрипте сами по себе реализуются? :)
Вот тут как раз синтаксисом разница не обойдётся. Если мы хотим, чтобы на C++ у нас такой же код работал, надо его запускать в отдельном потоке операционной системы. Пока поток один, два или даже 10 - проблем нет. Если же вы захотите описать логику каждого бота таким простеньким скриптом, у вас будет на каждого бота по потоку. 100 ботов - и система будет захлёбываться. Вам придётся отказаться от такой простой записи поведения и перейти к явному заданию конечного автомата - к какому-нибудь событийному механизму. Код будет расти и усложняться.
На остальные реплики не отвечаю, т.к они уже граничат с грубостью.
aml
> Если мы хотим, чтобы на C++ у нас такой же код работал, надо его запускать в
> отдельном потоке операционной системы
Именно так на С++ не сделать, но есть масса других вариантов. А здесь преимущество только при ожидании асинхронных операций.
aml
> Вам придётся отказаться от такой простой записи поведения
Проблема в том, что не во всех проектах логика поведения такая простая. И стейты или события все-равно будут. А грамотно написанный С++ код более скалируемый, чем скрипт.
Тема в архиве.