Конструктор модов SA-MP, CR-MP

[KillStreak]

Привет, хочу услышать мнение людей насчёт необходимости в реализации конструктора модов SA-MP, CR-MP. Представим на минутку, допустим уже есть что-то подобное, как вы считаете каким образом это повлияет на общее положение дел в SA-MP, CR-MP. Будет лучше или большинство отреагируют скорей в негативном свете. Я говорю о конструкторе который способен создать не только лишь определенные вещи а в целом всё то что могут позволить возможности SA-MP, CR-MP. Откроет ли данная разработка куда больший потенциал большинства людей не знающих Pawn но стремящихся в создании своего проекта. Готов выслушать любую критику и любые предложения на этот счёт.

[ziggi]

Такое уже есть (или было) и это никак не повлияло. Забей, ничего гибкого всё-равно не получится (или на это уйдёт уйма времени).

[Web]

Не нужно.

[vovandolg]

По моему тут даже сверх раку было бы понятно что легче будет всё изнутри изучать и писать на свой лад, чем плясать под какую то прогу которая не вышла ещё даже, а если и выйдет то будет жутко сырая:drinks:
Иди огород лучше копай и не занимайся бесполезным делом:rofl:

[Web]

И так нехватка уникальных игровых режимов.

[KillStreak]

Такое уже есть (или было) и это никак не повлияло. Забей, ничего гибкого всё-равно не получится (или на это уйдёт уйма времени).

Было и на сколько я сейчас знаю, даже не открылось. Исходя из той информации что была предоставлена, это даже и не конструктор был.



Иди огород лучше копай и не занимайся бесполезным делом:rofl:

Я этим не занимаюсь, просто спросил.


И так нехватка уникальных игровых режимов.

Их и не было или ты имеешь ввиду режимы по типу RP, RPG, DM, Stunt, Race, Freeoram, Cops And Robbers, GangWar, Zombie, Survival. Если да то твоё утверждение поставлено не верно.


Не нужно.

Аргументировать свой ответ можешь?

[Daniel_Cortez]

Не стоит, причём сразу по нескольким причинам.

Во-первых... Pawn сам по себе рассчитан на нубов -_-

Если же копнуть глубже, то, во-вторых, раньше уже были попытки сделать генераторы кода под отдельные задачи (например, создание рекламы в чате по таймеру (http://pro-pawn.ru/showthread.php?3391) или телепортов по пикапам/командам (http://pro-pawn.ru/showthread.php?3644) - и это лишь одни из многих примеров). Ничего грандиозного из этого не вышло.

В третьих, можно сделать что-то наподобие редактора PawnBlocks (https://www.compuphase.com/images/scriptcreator.png) - я так понимаю, именно это вы имели в виду под фразой "всё то что могут позволить возможности SA-MP, CR-MP". Но это будет уже не совсем конструктор - скорее, визуальный редактор кода.
Помню, подобный редактор уже был в редакторе карт к игре Warcraft III, но в нём не реализовывалась и половина возможностей языка JASS (именно этот ЯП применялся в игре): не было локальных переменных - вернее, в самом языке они были, но в редакторе не поддерживались - ,циклы были сделаны через N-ное место, причём только арифметические (без do/while) и счётчиками были тоже глобальные переменные, утечки памяти в библиотеке вспомогательных функций (эта библиотека была создана специально под нужды редактора, в оригинальных функциях JASS упомянутых утечек не было), и ещё куча недостатков, из-за которых на выходе получался глючный быдлокод.
Суть в том, что подобные редакторы всегда или почти всегда предоставляют куда более скудный функционал, чем тот, который можно получить, программируя "голыми руками". И это не говоря об эргономике, которая у визуального редактора куда меньше, чем у текстового (особенно, если в последнем есть подсветка синтаксиса и автодополнение).
Кроме того, пригодится такой редактор только тем, кто впервые имеет дело с кодом или хронически не умеет печатать. И если вместо программирования мышкой потратить хотя бы неделю на изучение основ самого ЯП и кодинга в целом, то необходимость в визуальном редакторе с большой вероятностью отпадёт.

В общем, можете попробовать реализовать свой редактор, если уж очень хочется, но, ИМХО, вряд ли результат будет стоить потраченного вами времени.

[KillStreak]

Ответ очень развёрнутый и мне он нравится, я хотел услышать мнение немного в другом стиле. Я имею ввиду как бы на это отреагировала общественность на конструктор модов SA-MP/CR-MP если предположить что он уже есть и соответствует заявленному (делать всё что можно). Это пользовалось бы спросом для людей не имеющих желания разбираться в коде самим?

[DeimoS]

Ответ очень развёрнутый и мне он нравится, я хотел услышать мнение немного в другом стиле. Я имею ввиду как бы на это отреагировала общественность на конструктор модов SA-MP/CR-MP если бы он был. Это пользовалось бы спросом для людей не имеющих желания разбираться в коде самим?

Вообще, всё зависит от реализации конструктора. В идеале, если конструктор будет иметь огромную гибкость и функционал, при этом останется простым в использовании - да, он бы пользовался спросом. Но это в идеале.

На деле же встанет вопрос о том, как реализовать функциональный и гибкий, но простой в освоении редактор. Ведь чем больше возможностей в нём будет, тем больше ошибок можно будет допустить и тем сложнее будет во всём разобраться. Функциональность взаимоисключает простоту.
И логический исход всего этого - появление людей, которые будут так же, как и с обычном ЯП, пытаться лезть в написание скриптов без подготовки и, в итоге, мир получит очередную кучу кривых скриптов, только уже сделанных в конструкторе.

В общем, всё, опять же, упирается в реализацию самого конструктора. Если реализовать всё так, что в нём будет удобно составлять любые по сложности скрипты (опять же, речь о идеальном стечении обстоятельств), то он отобьёт нужду и в написании скриптов руками. Но чтоб такого добиться, нужно либо обладать нереальной удачей, либо иметь хороший опыт написания таких конструкторов и знать как всё лучше реализовать. Ну и время, конечно. Ибо на такой конструктор его явно много уйдёт.

[Daniel_Cortez]

Это пользовалось бы спросом для людей не имеющих желания разбираться в коде самим?
ИМХО, настоящий вопрос здесь - "стоит ли подпускать таких людей к коду?" Программирования без программирования не бывает.

В плане эргономики тоже всё отнюдь не радужно.
Приведу пример. Представим такую ситуацию: нам нужно вызвать функцию SendClientMessage. Сравним подходы с применением текстового и визуального редактора.
В текстовом редакторе для этого нужно:
Написать название функции SendClientMessage.
Добавить скобки для параметров.
Прописать сами параметры: ID игрока, цветовую константу и текст.
Не забыть добавить ";" после скобок.

Вроде бы всё просто. Теперь что нужно сделать в визуальном редакторе:
Найти SendClientMessage в списке из 526 функций (да, именно столько их в SA-MP, не считая скрытых). Пока вы это сделаете, можно успеть несколько раз просто напечатать её название.
Проблему может смягчить наличие категорий, но окончательно это ситуацию не исправит. Также можно добавить возможность ввести название функции вручную - но тогда чем это будет лучше текстового редактора? Опять же, просто лишние клики мышкой и поиск в списке.
Выбрать из ещё одного списка тип параметра (локальная/глобальная переменная или непосредственно числовое значение) и выбрать переменную или ввести число.
Выбрать тип цвета: заранее определённая цветовая константа, глобальная/локальная переменная (вы же не собираетесь ограничивать пользователей и запретить им хранить цвет сообщений в переменных?), выбор цвета их палитры (наподобие того, что в MS Paint) или ввод числа, которым кодируется цвет.
Ввести сообщение. Опять выбор и опять по тому же принципу: переменная или текстовое значение.

Основной недостаток визуальных редакторов связан с тем, что много времени уходит на поиск нужного варианта из списков и постоянные "переключения" горе-кодера с мыши на клавиатуру и обратно.
Основываюсь на своём печальном опыте с похожим редактором кода в Warcraft III World Editor - благо, вовремя слез с него, пока совсем не потерял интерес к кодингу.

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

[$continue$]

В наших реалиях ты вряд ли заметишь лаги, если я буду использовать std::unordered_map

Найти SendClientMessage в списке из 526 функций (да, именно столько их в SA-MP, не считая скрытых). Пока вы это сделаете, можно успеть несколько раз просто напечатать её название.

[Daniel_Cortez]

В наших реалиях ты вряд ли заметишь лаги, если я буду использовать std::unordered_map
На списке функций, для которого логично было бы использовать контейнер list или простой массив? -_-

И да, перечитай пост внимательно. Специально процитирую основную мысль:

Основной недостаток визуальных редакторов связан с тем, что много времени уходит на поиск нужного варианта из списков и постоянные "переключения" горе-кодера с мыши на клавиатуру и обратно.
Где ты здесь увидел хоть слово о производительности программы?