Плохо! Плохо!:  0
Страница 1 из 6 123 ... ПоследняяПоследняя
Показано с 1 по 10 из 54

Тема: Open RGSS3: Обсуждение

  1. #1

    По умолчанию Open RGSS3: Обсуждение

    Итак, раздел открыт и нужно приступать к его наполнению.
    Очень важно при этом сохранять порядок и не допустить хаоса.

    Прежде всего, не стоит забывать, что содержимое этого раздела, равно, как и данная тема - коллективное творчество. Все обсуждаемо, и если вы с чем-то не согласны, если у вас есть предложения - не молчите, высказывайте их.

    Open RGSS3
    Обсуждение

    —————————————

    В этой теме только обсуждение Open RGSS3:
    вопросы использования в своём проекте, отчёты по багам, пожелания, критика, советы.

    Рабочие вопросы по разработке в другой теме.


    Скачать
    -- пока недоступно --


    Краткий FAQ

    Q: Что такое RGSS3?

    A: Его суть проще всего выразить формулой: RGSS1 + RGSS2. Это переписанная система классов RPG Maker XP и VX, совместимая с обеими программами.


    Q: Чем мне, как обычному пользователю, будет полезен RGSS3?

    A: Если вы работаете в XP, то сможете воспользоваться новыми возможностями RGSS2 в старой программе (60 FPS motherfucker!). Если вы пользователь VX, то и вам будет полезна оптимизированная версия RGSS3, в которой будут исправлены баги RGSS2 и улучшены некоторые методы и классы.


    Q: Чем мне, как скриптеру, будет полезен RGSS3?

    A: Кроме того, что эта система полностью совместима с обоими мэйкерами, в ней также будут сильно расширены возможности стандартных классов. Целые ангары велосипедов, собранных начинающими скриптерами отправятся на свалку. Всё уже придумано до вас, берите и пользуйтесь.

    Но самое интересное будет вас ждать в экспериментальной части скрипта.


    Q: Как определить на какой стадии проект?

    A: По версии. Будет использоваться следующая нумерация:

    0.0 - 0.4.х: Начальные работы. Приоритет — написание сверхклассов RPG.
    0.5: Готова система сверхклассов RPG.
    0.5.x - 0.9.x: Приоритет — написание базовой части RGSS3.
    1.0: Готова базовая часть RGSS3. На этом этапе библиотекой уже можно пользоваться в проектах.
    1.х: Расширение стандартных классов и работа над экспериментальной частью. С каждой новой версией этой ветки библиотека будет становиться всё полезнее.


    Q: Где сделать предзаказ / купить коллекционное издание / DVD-версию?

    A: Нигде. Всё делается своими руками и выкладывается в этой теме. Если хотите поучаствовать как разработчик, см. план работ в теме разработки. Там всё подробно расписано. Никаких сверхспособностей от вас не требуется. Берёте задачу по силам, решаете, выкладываете на форум. Если что не так, товарищи по команде помогут.

    Пожелания, советы, критику можно оставлять в этой теме.
    Последний раз редактировалось Bullet S.D.; 25.07.2011 в 14:14.

  2. #2

    По умолчанию

    Итак, начнем. Предлагаю следующие правила:
    - Все скрипты должны быть совместимы, как с VX, так и с XP. В обоих случаях, они ориентируются на последние версии патчей.
    - Один класс\модуль - одна тема. Запрещается разбивать классы\модули на части, объявляя по кускам то в одном, то в другом месте. (Ведь мы пишем единую систему скриптов, а не свалку непонятно чего).
    - Все представленные сцены и окна должны быть связаны друг с другом. (Если есть сцена "Бестиарий", то она должна откуда-то вызываться - если уж рисуются сцены, то они должны вписываться в цельную систему).

    - Комментарии к скриптам - на русском языке (не вижу смысла в обратном)
    - Любой метод или свойство должен сопровождаться комментарием
    - Проный отказ от использования венгерской нотации.
    - Полный отказ от использования нижнего подчеркивания "_" в именах чего-бы то ни было (спорный вопрос, оно с первых дней жизни RPG Maker XP вошло в RGSS и без него он кажется странным и непривычным. Тем не менее оно снижает читабельность кода, особенно когда таких подчеркиваний большего одного и снижает скорость написания кода. Практической пользы от него нет. Тем не менее, не настаиваю, но выношу на обсуждение).

  3. #3
    Создатель Аватар для Рольф
    Информация о пользователе
    Регистрация
    14.04.2008
    Адрес
    Южно- Сахалинск/Пенза
    Сообщений
    10,283
    Записей в дневнике
    2
    Репутация: 108 Добавить или отнять репутацию

    По умолчанию

    - Все скрипты должны быть совместимы, как с VX, так и с XP. В обоих случаях, они ориентируются на последние версии патчей.
    У меня с vx бывают затруднения, но я постараюсь по больше разобраться.
    - Любой метод или свойство должен сопровождаться комментарием
    Не люблю ставить комментарии, постараюсь привыкнуть.
    - Полный отказ от использования нижнего подчеркивания "_" в именах
    чего-бы то ни было (спорный вопрос, оно с первых дней жизни RPG Maker XP
    вошло в RGSS и без него он кажется странным и непривычным. Тем не менее
    оно снижает читабельность кода, особенно когда таких подчеркиваний
    большего одного и снижает скорость написания кода. Практической пользы
    от него нет. Тем не менее, не настаиваю, но выношу на обсуждение).
    Согласен, надоедает.
    @command_window = Window_ShopCommand.new
    Слева вообще думаю не нужна эта фигня, справа хоть напоминает, что это окно.
    Последний раз редактировалось Рольф; 16.07.2011 в 04:06.

  4. #4
    Познающий Аватар для mephis
    Информация о пользователе
    Регистрация
    27.01.2011
    Адрес
    Новосибирск
    Сообщений
    330
    Записей в дневнике
    8
    Репутация: 34 Добавить или отнять репутацию

    По умолчанию

    Вопросы.

    1. Нет чёткого и ясного объяснения зачем это всё нужно. Я так понимаю, должно получиться что-то похожее на ХР-шные SDK и MACL. Это мягко говоря огромная работа и без понятной сути, ясных целей и чётко поставленных задач — идея заглонет 100%. Потому что не будет понятно куда идти, как именно идти и как понять, что куда-то пришёл.

    2.
    Все скрипты должны быть совместимы, как с VX, так и с XP.
    Зачем? Не лучше ли выбрать только VX? На XP уже переписывали классы, см. выше.

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

    ...а не просто

    а) решил что надо, написал, а дальше сами пихайте
    ?

    4.
    Любой метод или свойство должен сопровождаться комментарием
    Было бы неплохо комментировать логические куски кода, чтобы была понятна суть алгоритма, а не доводить до двух идиотских крайностей:
    а) вообще нет комментариев. Типа, хрен знает как но работает, поэтому не лезьте внутрь.
    б) комментится каждая строчка. Ещё больший идиотизм. В таком вот стиле:
    Код:
    // Создаём переменную
    int a = 4;
    // Складываем
    c = a + b;
    // Выводим
    print(c);
    5.
    Проный отказ от использования венгерской нотации
    Где она в RGSS, чтобы от неё отказываться?

    6.
    Полный отказ от использования нижнего подчеркивания "_" в именах чего-бы то ни было
    Действительно очень и очень спорный пункт.
    Доводы против:
    а) Какие имена должны быть у констант из нескольких слов? "COUNTOFTILESINTILESET"?
    б) Скачущий стиль будет гораздо хуже. Потому что все, или почти все, сторонние скрипты написаны с оглядкой на стандартные и в его стиле. Не нужно плодить сущности без острой на то необходимости.

    Вообще, предлагаю не трогать стиль оформления кода RGSS. Самому-то приятно будет читать код, где в одном месте ($gameTemp.shopGoods и LETTERTABLE), а в другом ($game_temp.shop_goods и LETTER_TABLE)? Зачем путать людей? К чему эти эстетские замашки? Как будет осуществляться совместимость с другими скриптами?

    upd:
    снижает скорость написания кода
    Вот это позабавило ))) Предлагаю пойти дальше и для ускорения написания кода отказаться от комментариев вовсе. Избавиться от длинных имён (вместо $game_temp.shop_goods — $gt.sg). Или вообще ничего не писать. Тогда экономия времени будет просто огромна!!!

    Такое ощущение, что вы там код пишете по тыще строк в час.
    Последний раз редактировалось mephis; 16.07.2011 в 04:56.

  5. #5
    Создатель Аватар для Рольф
    Информация о пользователе
    Регистрация
    14.04.2008
    Адрес
    Южно- Сахалинск/Пенза
    Сообщений
    10,283
    Записей в дневнике
    2
    Репутация: 108 Добавить или отнять репутацию

    По умолчанию

    1. Нет чёткого и ясного объяснения зачем это всё нужно.
    http://rpgmaker.su/showthread.php/11...B0%D1%82%D1%8C

  6. #6

    По умолчанию

    Эх!!! Тут столько умного, а понять всё равно не можем!!! Мы поняли, что когда мы изучаем их мы сильно тормозим и много не можем переварить!!

  7. #7
    Познающий Аватар для mephis
    Информация о пользователе
    Регистрация
    27.01.2011
    Адрес
    Новосибирск
    Сообщений
    330
    Записей в дневнике
    8
    Репутация: 34 Добавить или отнять репутацию

    По умолчанию

    * картинно всплеснув руками *
    Быть не может!

    Рольф, ну за дурака-то зачем меня принимаешь? Я читал уже ту тему.

    Наверное, распишу по-подробнее этот вопрос.

    К абстрактной цели придти невозможно в принципе. А той теме она именно абстрактно сформулирована: "Давайте перепишем и оптимизируем стандартный RGSS". В стиле — давайте замутим мега-мэйкерский-проект. Вроде же где-то была эта тема на форуме. Ну и что, далеко ушли? Неужели непонятно в чём облом был?

    На истину в последней инстанции не претендую, но рекомендую выстроить чёткую для понимания структуру, в которой есть ответы на вопросы:

    1) Почему такой-то класс или метод неэффективен. Аргументы.
    2) Почему и можно ли его переписать. Может овчинка и не стоит выделки.
    3) Какие классы и методы нуждаются в переписывании. Почему.
    4) Какие классы нуждаются в расширении. Почему.
    5) И все остальные вопросы, которые я написал в прошлом посте.

  8. #8

    По умолчанию

    2. Это элементарно: многие продолжают сидеть на XP. И на то есть масса причин, хотя бы банальное удобство в отношении тайлсетов! А если ты переопределяешь методы Graphics, то сложности с исполнением явно не возникнет. Если же какой-то метод будет очень плотно завязан на использование библиотеки конкретного мукера и ее использование в другом будет невозможно - что ж, этот сопрный момент мы решим.
    3. Совершенно верно
    4. Согласен, как с рекомендацией - по желанию авторов. Желающие также смогут дописывать эти комменты сами.
    5. В RGSS ее нет - прекрасно. В пользовательских скриптах она порой встречается, притом в особо извращенной форме, вроде: m_name, m_year, помимо обычных iIndex
    6.
    а) Какие имена должны быть у констант из нескольких слов? "COUNTOFTILESINTILESET"?
    CountOfTilesInTileSet, например?
    б) Скачущий стиль будет гораздо хуже. Потому что все, или почти все, сторонние скрипты написаны с оглядкой на стандартные и в его стиле. Не нужно плодить сущности без острой на то необходимости.

    Вообще, предлагаю не трогать стиль оформления кода RGSS. Самому-то приятно будет читать код, где в одном месте ($gameTemp.shopGoods и LETTERTABLE), а в другом ($game_temp.shop_goods и LETTER_TABLE)? Зачем путать людей? К чему эти эстетские замашки? Как будет осуществляться совместимость с другими скриптами?
    А кто-то говорил про совместимость? Мое мнение - если уж займемся плагиатом (а мы им займемся), то чужие творения также придется переписывать, подгоняя под наши реалии.
    Но насчет сущностей, пожалуй, соглашусь. Действительно определенный стиль уже укоренился, что не может не огорчать... (кстати, ты не привел в пример attr_* )

    Наконец 1:
    Откуда такие пораженческие настрои? Сейчас повыложим сверхклассы, поправим то, да сё, потом кто-нибудь захочет переделать Scene_Title и понеслась...
    Загнуться может проект, идущий к невыполнимой / неподъемной цели. Абстрактная же ни к чему не обязывает, и не заставляет торопиться с ее выполнением. Получится в итоге новая система скриптов, которую можно вставить хоть в XP, хоть в VX? Прекрасно! Нет - будет набор методов для определенных классов, которые кому-нибудь пригодятся в проектах. Только и всего.

    Касательно второй части - замечательная структура для подачи заявок на изменение тех или иных методов/классов. Согласен, надо бы под это дело завести отдельную темку (займешься? ). Но только не как обязательное требование перед выполнением чего-либо. Будет очень много полемики и очень мало действий. Если человек что-то пишет без согласования с другими. он должен понимать, что с этим могут не согласиться и его усилия пропадут в Туне. Если он пишет несмотря на это - его право.

    Поднял замечательные вопросы. Давай дальше в том же духе.

  9. #9
    Создатель Аватар для Рольф
    Информация о пользователе
    Регистрация
    14.04.2008
    Адрес
    Южно- Сахалинск/Пенза
    Сообщений
    10,283
    Записей в дневнике
    2
    Репутация: 108 Добавить или отнять репутацию

    По умолчанию

    Тему надо создать, где будет основное обсуждение или можно перенести ту тему где ты просил раздел.

  10. #10

    По умолчанию

    Нужно вообще определиться с тем - какие темы, помимо собственно скриптов, нам нужны. Пока есть: правила, обсуждение, заявки, что еще?

Страница 1 из 6 123 ... ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 2 (пользователей: 0 , гостей: 2)

Социальные закладки

Социальные закладки

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •  
Open RGSS3: Обсуждение