EmissionRP - уникальный (?) мод с нуля

[Black Fox]

EmissionRP // dev_log


// Live commits log: http://emission-samp.ru/ (не допилен)


// INTRO

Приветствую игроков данного форума!
Данной темой я бы хотел анонсировать разработку уникального (?) игрового РП режима написанного с нуля - EmissionRP.

Я программист, который еще совсем недавно был достаточно далеким от мира SAMP'a. Я играл, но абсолютно ничего не знал о том как устроены сервера внутри, на чем они пишутся. Не знал pawno, не знаю паттернов и подходов к разработке...
И вот в один момент я понял, что мне стало абсолютно невыносимо от качества и однообразности большинства модов. Разработчики нагло врут игрокам о том, что тратят неимоверные время и усилия, но при этом выпуская раз в месяц сомнительные обновления, реализующие пару фич, разработка которых в действительности займет не больше дня.

Я захотел сделать свой мод, с блекджеком и... ну вы поняли. Я захотел доказать себе, что все эти люди ленятся и не хотят делать нормально, доказать, что делать нормально возможно!
Я уверен, что даже без знания pawno и без опыта разработки под SAMP у меня получится хороший проект. Я осознанно ни разу не смотрел исходные коды каких либо проектов, чтобы не засорять себе мозг и быть более независимым в вопросах проектирования архитектуры.

Что, опять?... Резонно! Но нет
Это не очередной мод, который будет заброшен через пять минут.
Это не очередной мод от человека, который не знает как программировать.
Это не очередной мод, который планирует быть безыдейный копиркой.
Это не очередной мод, основанный на копипастах других - я не видел код других модов.

Я уверен что мне хватит мотивации и сил, чтобы доделать этот мод. Надеюсь их хватит и моему напарнику, и мы пройдем этот пусть вместе!

Дальнейшая судьба мода неизвестна. Может быть он останется нашим личным детищем, может быть мы выложим его в паблик, может быть мы переедем в "проекты" и откроем собственный сервер. Для меня сейчас это загадка.

Мы делаем мод с желанием создавать собственные механики, но посчитали что будет слишком фатально трогать важные и привычные всем вещи. Все основные механики из других модов ИЗНАЧАЛЬНО будут присутствовать в нашем. Далее, если мы все же решим поднять проект и получим аудиторию, то мы продолжим гнуть свою "линию", и постепенно заменять привычный всем, но кривой функционал на более продуманный и соответствующий миру РП.

Еще один важный принцип нашей разработки заключается в том, что мы хотим по максимуму учесть все нюансы возможных абузов и нарушений, чтобы сделать мод максимально комфортным. Наша задача дать игрокам как можно меньше шансов что-либо нарушить, и предоставить автоматические РП наказания в случаях нарушений.


// TEAM

В настоящий момент я уже нашел себе единомышленника, который так же только встает на путь изучения pawno. Разработку всего мы ведем вдвоем. Если он захочет, то назовет себя в этой теме, или попросит меня.
Андрей, напиши мне, или сам в эту тему



// TECH

Технический мод реализуется не так, как большинство существующих модов. Вместо использования mysql, файлов и прочего мною было решено использовать отдельный сервер для работы с данными, так называемый бэкэнд.
Все операции по сохранению, обработке, просчитыванию и прочему выполняются им (бэкэндом), тем самым экономя ресурсы игрового сервера.
Второй очевидный плюс - все данные вынесены за пределы сервера, что позволяет легко использовать их где угодно еще. Например - панель администрирования, из которой можно делать практически все действия, которые можно делать с сервера.
Третий плюсом является более удобный язык (C#), позволяющий разрабатывать проще, быстрее и приятнее, чем это происходит с устаревшим pawno. Это особенно актуально при работе с данными, ведь в C# мы имеет великолепные EntityFramework и LINQ.

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

Панель администрирования будет так же реализована после завершения некоторой основной части функционала мода. Она будет как для игроков, так и для админов. Хочу открыть все данные, все логи: сделать все доступным. Сделать карту с проверкой домов, машин - идей на тему админки очень много, но я пока не занимался их систематизацией и не записывал их, поэтому в данный момент не способен выдать что-то более конкретизированное.

Мод разбит на файлы. Я тут читал, что многие так не делают... Я в шоке=)))
Мод разбит на модули, которые могут быть включены или выключены.
Мод старается следовать правилам наименования и единой архитектуре модулей. Пока написано достаточно мало код, то сложно однозначно трактовать удобность архитектуры, это будет понятно только с увеличением сложности мода и количеством кода. Думаю, что архитектура со временем будет сильно меняться, и придет к чему-то совершенному.
Мод будет использовать переводы и настройки, подцеляемые из веб панели. Разумеется, они будут применяться без перезагрузки. Если не делать так - лучше не делать вообще. Единственная сложность это непрогнозируемый размер строк (решения пока нет).
Мод будет активно использовать продвинутые инклюды от Y_Less'a (YSI), тем самым еще больше улучшая свою архитектуру и функциональность, благодаря возможностям динамический хукать функции и т.д..
Мод написан с осознанием того, что делается. Например, каждая функция не является public или stock, как в 50% туториалов, разбросанных по русскому сегменту.


// Summary

Зачем эта тема? Мы видим в ней несколько причин:
1) Мы хотим делится проделанной работой, чтобы повышать мотивацию и получать отклик (советы) от других людей.
2) Мы хотим проводить опросы, иметь некую аудиторию, с которой можем советоваться.
3) Мы хотим приносить вдохновение другим разработчикам, показывать что можно делать нормально и круто, и вовсе не обязательно следовать шаблонным гайдам (помним: я не видел ни одного исходного кода существующих модов)
4) Мы хотим общаться и обсуждать идеи, проблемы и решения с другими разработчиками. Наш опыт павна - одна неделя. Да, зная другие языки этого хватило чтобы начать уверенно писать на нем, но всегда могут возникать спорные вопросы или ситуация, в которых требуется знание "внутренностей" языка.

Старт разработки - 13.07.2017
Мы следуем системе еженедельных спринтов, поэтому крупные посты об обновлениях будем стараться писать раз в неделю.
Так же мы подняли простой сайт, который агрегирует коммит-логи с наших репозиториев. Там вы можете следить за работой в лайв-режиме - http://emission-samp.ru/ (не допилен)

[DeimoS]

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

Так а MySQL не является отдельным сервером? Даже если и игровой сервер, и MySQL сервер стоят на одной машине, они всё равно никак не влияют на работу друг друга (если, конечно, всё настроено правильно и никто никого не уронит, в итоге, из-за какой-нибудь ошибки благодаря криворукости настройщика). Хотя если брать более-менее адекватные хостинги (да и самому никто не запрещает такое реализовать на VDS), можно поместить MySQL сервер на отдельную машину и даже, при желании, пробросить ей свой интернет-канал, дабы нельзя было положить один сервер за счёт ддоса другого. Только стоит учитывать, что появится дополнительный пинг из-за обмена информацией между двумя машинами.


Все операции по сохранению, обработке, просчитыванию и прочему выполняются им (бэкэндом), тем самым экономя ресурсы игрового сервера.

А как же формируются данные для отправки на твой второй сервер? Не при помощи ли средств сервера? Точно так же, как и формируются запросы к MySQL: сервер лишь формирует запрос из тех данных, что ты собрал ранее (которые не только для синхронизации данных с MySQL/бэкендом или чем-либо ещё нужны, но и просто для адекватной работы с информацией игрока во время игры) и больше он никак свои ресурсы не тратит.


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

Так, собственно, а MySQL что позволяет делать, лол? Не то же ли самое? Только с учётом того, что MySQL как раз и создан был для того, чтоб работать с большими объёмами информации, и в нём всё сделано так, чтоб эта работа происходила максимально быстро (как думаешь, за 22 года разработки люди смогли бы оптимизировать своё детище так, чтоб оно работало достаточно быстро?).

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


Может я, конечно, что-то недопонимаю, но пока всё очень похоже на то, что ты не особо давался в теорию перед тем, как делать тот или иной выбор. У тебя просто есть какое-то своё представление того, как, по твоему мнению, можно сделать лучше, а проверять это самое мнение ты решил сразу на практике, а не при помощи теории.
Например, что ты хотел сказать вот этим?

Например, каждая функция не является public или stock, как в 50% туториалов, разбросанных по русскому сегменту.
Судя по всему, ты просто не знаешь предназначения как маркера public, так и маркера stock, но решил, что использовать их повсеместно - говнокод...

Советую изучить элементарные основы языка (ссылки на официальную документацию можно найти в этой теме (http://pro-pawn.ru/showthread.php?12772-%D0%9E%D0%B3%D0%BB%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5)) и почитать о разных способах хранения данных (о том, почему большинство людей сейчас использует MySQL, как минимум)

[Seregamil]

Третий плюсом является более удобный язык (C#), позволяющий разрабатывать проще, быстрее и приятнее, чем это происходит с устаревшим pawno.


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

Вы юзаете дотнет, и при этом собираетесь делать плагин на крестах. Чем не угодили сокеты дотнета?

Например, каждая функция не является public или stock
Дайте угадаю. Если вы заюзали для мода дотнет, то все функции выглядят в виде "private static void function()"?

В настоящий момент я уже нашел себе единомышленника, который так же только встает на путь изучения pawno.
Сначало разберитесь с названием ЯП, а потом вставайте на путь изучения -_-

Чет бред какой-то в тексте

[ziggi]

То есть, вместо MySQL используется LINQ через HTTP? Это ТАК странно. И если просадок по скорости ты сейчас не видишь, то при нескольких игроках они уже будут ощутимы, лучше отступиться от этого, пока не поздно. А если у тебя аллергия на MySQL, то можешь использовать Redis, благо, нужный плагин уже доступен.

P.S. socket плагин уже давно написали, нужно лишь немного полистать раздел с плагинами на официальном форуме.

[Black Fox]

@DeimoS


Так а MySQL не является отдельным сервером? Даже если и игровой сервер, и MySQL сервер стоят на одной машине, они всё равно никак не влияют на работу друг друга (если, конечно, всё настроено правильно и никто никого не уронит, в итоге, из-за какой-нибудь ошибки благодаря криворукости настройщика). Хотя если брать более-менее адекватные хостинги (да и самому никто не запрещает такое реализовать на VDS), можно поместить MySQL сервер на отдельную машину и даже, при желании, пробросить ей свой интернет-канал, дабы нельзя было положить один сервер за счёт ддоса другого. Только стоит учитывать, что появится дополнительный пинг из-за обмена информацией между двумя машинами.

А как же формируются данные для отправки на твой второй сервер? Не при помощи ли средств сервера? Точно так же, как и формируются запросы к MySQL: сервер лишь формирует запрос из тех данных, что ты собрал ранее (которые не только для синхронизации данных с MySQL/бэкендом или чем-либо ещё нужны, но и просто для адекватной работы с информацией игрока во время игры) и больше он никак свои ресурсы не тратит.

MySQL несомненно является отдельным сервером, с этим я не спорил. Разница в том, что MySQL не может сам производить расчеты (есть хранимки, но это дургое).
Бэкэнд сервер в свою очередь может брать львиную часть работы на себя, тем самым снимая нагрузку с игрового сервера. Списать деньги со счетов всех домов (онлайн/оффлайн) игроков, например. Таких примеров может быть очень много. Да и вообще, для работы с данными намного приятнее и круче использовать то, что сделано для работы с ними (Entity Framework, LINQ).


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



Так, собственно, а MySQL что позволяет делать, лол? Не то же ли самое? Только с учётом того, что MySQL как раз и создан был для того, чтоб работать с большими объёмами информации, и в нём всё сделано так, чтоб эта работа происходила максимально быстро (как думаешь, за 22 года разработки люди смогли бы оптимизировать своё детище так, чтоб оно работало достаточно быстро?).
Здесь не спорю - MySQL может делать тоже самое, и разумеется мой бэкэнд сервер так же использует БД для хранения данных.
Привел этот пунк, потому что видел что на многих проектах панели обновляются после рестарта, или типа того. По-сути- да, данный пунк можно удалять из плюсов :)



Судя по всему, ты просто не знаешь предназначения как маркера public, так и маркера stock, но решил, что использовать их повсеместно - говнокод...
Допускаю, тогда проясни пожалуйста, в чем причина? (это не сарказм)
Единственная причина которую я вижу - люди хотят потом отлаживать скрипты более комфортно (профайлером или чем-то еще). Т.е. они пишут public чтобы пробросить имя функции в amx. Но тогда у меня другой вопрос - почему авторы туториалов молчат об этом, о причинах использования пабликов? Это, разумеется, вопрос риторический - они меня не слышат.

По поводу stock - мод не библиотека. Ему не нужен stock. Возможно за исключением редких архитектурных решений, но уверяю - их нету у людей, ищущих код в 1 файл.

@Seregamil


Сначало разберитесь с названием ЯП, а потом вставайте на путь изучения -_-
Pawn* - моя вина, повелся на всеобщее заблуждение :)


Вы юзаете дотнет, и при этом собираетесь делать плагин на крестах. Чем не угодили сокеты дотнета?
Мы о разном, я не буду отвечать. Ты (вы?) не понял архитектуру, разговор не имеет смысла.

@ziggi


То есть, вместо MySQL используется LINQ через HTTP? Это ТАК странно. И если просадок по скорости ты сейчас не видишь, то при нескольких игроках они уже будут ощутимы, лучше отступиться от этого, пока не поздно. А если у тебя аллергия на MySQL, то можешь использовать Redis, благо, нужный плагин уже доступен.
Да, я ОЧЕНЬ ДАЖЕ допускаю, что начнутся серьезные просадки. У меня нету аллергии на MySQL, просто я хочу разделить игровую часть, и часть работы с данными, об этом писал выше. В случае просадок я просто заменю протокол HTTP на что-то более быстрое, это сильно не повлияет на саму идею.

[DeimoS]

MySQL несомненно является отдельным сервером, с этим я не спорил. Разница в том, что MySQL не может сам производить расчеты (есть хранимки, но это дургое).
Бэкэнд сервер в свою очередь может брать львиную часть работы на себя, тем самым снимая нагрузку с игрового сервера. Списать деньги со счетов всех домов (онлайн/оффлайн) игроков, например. Таких примеров может быть очень много. Да и вообще, для работы с данными намного приятнее и круче использовать то, что сделано для работы с ними (Entity Framework, LINQ).

Списать деньги со счетов всех домов? Легко.
Например, 1000 долларов (или в чём там исчисляются финансы):

UPDATE house SET balance = balance-1000
Всё. Сервер лишь отправит этот запрос в базу и она всё сама обработает.
А если ты подразумеваешь то, что результат вычислений должен прийти обратно на сервер, то что тебе мешает сразу запустить цикл и провести эти вычисления? Отнять от текущего баланса тысячу будет так же быстро, как и обработка результата работы твоего бэкэнд сервера (или ты придумал как передавать данные через ноосферу сразу в переменные?). А более сложные расчёты обычно требуются незамедлительно (обычно нечто подобное бывает в античитах. Например, расчёт положение стреляющего игрока относительно других с учётом того, куда попадает этот самый игрок. Если ты переложишь расчёты на бэкэнд, у тебя мало того, что из-за пинга игрока будут погрешности, так ещё и пинг бэкэнд сервера прибавится).


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

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

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


Допускаю, тогда проясни пожалуйста, в чем причина? (это не сарказм)
Единственная причина которую я вижу - люди хотят потом отлаживать скрипты более комфортно (профайлером или чем-то еще). Т.е. они пишут public чтобы пробросить имя функции в amx. Но тогда у меня другой вопрос - почему авторы туториалов молчат об этом, о причинах использования пабликов? Это, разумеется, вопрос риторический - они меня не слышат.

По поводу stock - мод не библиотека. Ему не нужен stock. Возможно за исключением редких архитектурных решений, но уверяю - их нету у людей, ищущих код в 1 файл.

Потому что это крайне несущественная информация, которая никак особо не влияет на работу мода в целом. Ты хоть все функции определяй через атрибут public - принципов обработки кода это не изменит и сервер не сломает. А stock в SA-MP используют чаще всего лишь из синтаксических соображений (дабы визуально отделить функции, что вызываются сервером/таймером/CallLocalFunction и т.п., от тех, что просто вызываются в коде). И от того, что ты начнёшь использовать public/stock/static и т.п. только по их предназначению, ты не сделаешь ровным счётом ничего, что могли бы ощутить твои игроки. Это больше на понтокод походит, хоть отчасти это и правильно.


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

И да, ты писал, мол использование бэкэнд серверов - нормальная практика во многих приложениях. Так может она потому в них и нормальная, что и архитектура проекта позволяет, и действительно есть проблемы, которые иначе не решить? Машина вон тоже без колёс ездить не может. Но это ведь не значит, что колёса нужно к табурету приделывать из-за этого.

[Black Fox]

@DeimoS,
Во-первых: спасибо за развернутый комментарий.

Изначально я подумал, что ты невнятный комментатор уровня @Seregamil, но сейчас я вижу что ты объективен и конструктивен, за это уже спасибо :)

Давай проясним немного суть нашей дискуссии...

1) Я знаю, что MySQL это хорошо, и что все получится.
2) Я не пытаюсь доказать что MySQL это плохо, а мой способ лучше. Мой способ - это просто способ. Мне кажется, что он лучше для меня. Не больше.
3) Я знаю, что мой способ несет много проблем, и что в определенный момент они могут стать неразрешимыми.
4) Я не видел и не слышал ни об одной реализации с использованием такой архитектуры как у меня, что делает задачу интереснее.
5) Ничего страшного не случится, если я в определенный момент пойму что уперся в тупик, и заменю серверный код на MySQL - это не займет много времени.
6) Я не пытаюсь ничего УСКОРИТЬ, я пытаюсь сделать так, как мне интересно и хочется, но при этом чтобы работало хорошо, а не было костылями и быдлокодом.
7) Тот факт что я использую другие технологии не делает решение костыльным.
8) Ты говорил о трате времени, но ведь разработка под самп изначально является тратой времени. Все затраченные почти любым самп-кодером человекочасы могли бы принести ему намного больше денег и пользы, примени он их на более важные и полезные задачи.
Что касается меня - у меня есть хорошая работа, на которой я пишу хороший и полезный код, поэтому проблем с самореализацией и проф. реализацией у меня нету, я могу позволить себе "понаркоманить", и попробовать сделать что-то необычное для развлечения и нового опыта.

Теперь немного ближе к твоему сообщению...
Да, MySQL может вычесть сумму аренды, ок, мой пример был не совсем корректен. Давай усложним его немного... Я хочу:

1) Вычесть сумму аренды с дома, учитывая класс дома, подключенные модули (интернет, домашний телефон, телевидение, гаражи - подставь нужно), учесть процентную ставку, заданную мэром.
2) Записать эти изменения в лог средств пользователя.
3) Сформировать квитанцию для пользователя, отправив ему ее на email.
4) Сформировать и отправить уведомление о критический малом кол-ве средств ему на email/моб. телефон (это я не про игру)
5) Рассчитать старение дома, уменьшить состояние

Список становится уже не таким простым. Да, все это может сделать MySQL, но частичные расчеты уже перейдут на сторону сервера. Более того, эти данные не нужны мне мгновенно, поэтому никаких проблем с асинхронностью я не вижу.

И в завершение: Да, ты прав. Как и все другие, кто будут говорить что нужно делать на MySQL. И я с радостью повторю это еще раз, если (когда?) упрусь в непреодолимые проблемы с моим способом. Но это не мешает мне попробовать, не мешает разработке мода (максимум добавит лишнюю неделю для перевода мода на MySQL). Поэтому давай на данном остановимся, и перестанем обсуждать мой бэкэнд? :)

Тем не менее, я с радостью готов выслушать другие вещи, советы.

[Fallen A.]

Из самого простого, для выполнения всех операций, могу подсказать cron-задачи. Не катит?

[Black Fox]

Из самого простого, для выполнения всех операций, могу подсказать cron-задачи. Не катит?

Искренний надеюсь, что я не так тебя понял, и этот комментарий не про задачи с домом...

[Fallen A.]

Искренний надеюсь, что я не так тебя понял, и этот комментарий не про задачи с домом...

Если ты выполняешь списание средств со счета игрока, к примеру, раз в день/каждый час/6 часов, то можно использовать крон задачи.
При этом можно применять фильтры относительно установленных в БД значение и высылать email на почту. С этим отлично справится как php, так и c#. Про остальные языки не знаю.

[Black Fox]

Если ты выполняешь списание средств со счета игрока, к примеру, раз в день/каждый час/6 часов, то можно использовать крон задачи.
При этом можно применять фильтры относительно установленных в БД значение и высылать email на почту. С этим отлично справится как php, так и c#. Про остальные языки не знаю.

Я не улавливаю сути :)

Сделать можно все, и очень многими способами, не понимаю к чему это.
Я же не писал, что задача с домом разрешима только моими средствам. Так или иначе - да, крон тоже подойдет.

#Change Log (от 21.07.2017)
Вот и прошла первая неделя разработки (на деле чуть больше).

Основные задачи заложенные на этот недельный спринт:
1) Создать сайт для отображения коммитов, поднять хост, купить домен
2) Разобраться с павном, базово прикинуть архитектуру
3) Сделать связь сервера с бэкэндом
4) Сделать регистрацию и авторизацию

План работ был выполнен, даже перевыполнен, и это не может не радовать:

На этой неделе мы провели много работы над сайтом, и продолжаем по-немного допиливать его и дальше.

Каких-то выдающихся результатов в разработке мода за эту неделю сделано не было, но из незапланированных фич была реализована базовая логика пэйдея, удобная обертка для сохранения пользовательских данных, и примерно набросана архитектура проекта.
Из-за довольно маленького опыта разработки в павне (1 неделя :)) прогресс пока движется медленнее чем хотелось, ведь много времени уходит на понимание вещей, на выработку оптимальных решений, на эксперименты с разной архитектурой и стилем написания кода.

Не вижу смысла публиковать скриншоты диалогов авторизации/регистрации: все видели подобные диалоги уже тысячу раз, это никому не интересно. Более того, до тех пор пока у нас не закрыта задача с подгрузкой строк (переводов) из БД мы не финалим тексты/формулировки, потому что не видим в этом смысла.

Так же было написано достаточно много внутренней документации и справочных текстов, в которых мы постарались расписать некоторые из систем, планируемых в будущем.

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

PS: не упоминал, но я и мой напарник работаем фуллтайм программистами, поэтому у нас не так много времени, как хотелось бы. Не нужно думать, что мы занимаемся модом целый день :)
PSS: текст вышел довольно сумбурным, наверно стоило отправиться спать, и написать его завтра. Но раз написал - публикую.

[DeimoS]

Я не улавливаю сути :)

Сделать можно все, и очень многими способами, не понимаю к чему это.
Я же не писал, что задача с домом разрешима только моими средствам. Так или иначе - да, крон тоже подойдет.

Просто обычно люди приходят на форум с Наполеоновскими планами и, при этом, не понимают сути своей идеи. Поэтому иногда приходится этим людям объяснять их идеи, дабы они более сознательно к своему выбору подошли. Так же и с тобой: никто не знал, что ты понимаешь о чём говоришь и представляешь все последствия, которые сопутствуют твоему выбору, потому и пытались тебе разъяснить всё. Но раз ты осознанно идёшь на сей эксперимент, то и, как говорится, флаг тебе в руки.

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

[Black Fox]

Кстати, для простоты возможного перехода на MySQL набросал некую обертку для формирования строки запроса.
Это конечно лишний синтаксический сахар, что тоже не ок... Но все равно это упросит переход.

Более того, я бы в любом случае писал что-то подобное, потому что захотел бы изолировать MySQL запросы (или хотя бы их большинство) в отдельном модуле.

Выглядит примерно так:
http://storage2.static.itmages.com/i/17/0722/h_1500731566_4414889_033c193ad1.png

Хотелось бы задать вопрос всем просматривающим, кто имел опыт с MySQL: а как вы оборачиваете запросы? В отдельные функции, сахар, или просто пишите там, где он понадобился? (по возможности с примерами)

[DeimoS]

Хотелось бы задать вопрос всем просматривающим, кто имел опыт с MySQL: а как вы оборачиваете запросы? В отдельные функции, сахар, или просто пишите там, где он понадобился? (по возможности с примерами)

Собственно, всё так же, как и с обычным кодом: все запросы, что вызываются более чем в одном блоке кода (изменение значения столбца в таблице с аккаунтами, например) обёртываются в отдельную функцию (некоторые даже делают нечто подобное (http://pro-pawn.ru/showthread.php?10548-%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B-%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%86%D0%B8%D0%B8-%D0%BD%D0%B0-%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B5-%D0%BF%D0%BB%D0%B0%D0%B3%D0%B8%D0%BD%D0%B0-MySQL-R39-R40&p=85035&viewfull=1#post85035), объединяя все запросы обновления значения столбца в одну функцию, где нужно указать название столбца и, собственно, значение), а одиночные запросы можно и напрямую прописать

[Black Fox]

Собственно, всё так же, как и с обычным кодом: все запросы, что вызываются более чем в одном блоке кода (изменение значения столбца в таблице с аккаунтами, например) обёртываются в отдельную функцию (некоторые даже делают нечто подобное (http://pro-pawn.ru/showthread.php?10548-%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B-%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%86%D0%B8%D0%B8-%D0%BD%D0%B0-%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B5-%D0%BF%D0%BB%D0%B0%D0%B3%D0%B8%D0%BD%D0%B0-MySQL-R39-R40&p=85035&viewfull=1#post85035), объединяя все запросы обновления значения столбца в одну функцию, где нужно указать название столбца и, собственно, значение), а одиночные запросы можно и напрямую прописать

Вариант по ссылке это по сути как раз то, что сделал я.

Только у меня столбцы задаются не строкой, а енамом, и их может быть неограниченной количество в 1 запросе. Но и из минусов, так это то, что у меня это 4 функции, а не одна :)

[Black Fox]

*Change Log #2 (от 31.07.2017)
Привет. Это западавший чейжлог №2.
Пока достаточно сложно держаться графика, и выпускать недельные чейнжлоги вовремя, но я буду стараться как можно меньше отклоняться недельного графика.

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

*WEB
На этой неделе мы начали работу над редактором сокращений, и планирование блога.

Редактор сокращений это достаточно бесполезная штука, которая просто пришла к нам в голову. Мы стараемся не ограничивать себя рамками, и позволять некий фан и творчество в разработке. Если нам хочется потратить время на разработку какой-то не сильно нужной системы, которая кажется нам интересной, то мы делаем это. Просто потому, что нам это нравится.
Суть идеи проста: мы заметили, что сокращенные имена некоторых наших разработок достаточно плохо читаются, и теоретическим читателям нашего блога (ниже об этом) или чейнжлога может быть сложно понять о чем идет речь. Редактор сокращений призван решить данную проблему, позволив нам добавлять в БД сокращения и их расшифровки, выводя их потом в виде поп-апов.

Блог. Мы просто поняли, что нам нужно иметь какое-то место, где мы можем писать наши чейжлоги, чтобы в перспективе размещать их на разных источниках. Намного удобнее выносить обсуждения на источники, а исходный текст держать в одном месте, ведь так проще править и следить за ним. Да, это могла бы быть группа ВК, или мы могли бы использовать существующий блоговый движок.. Но я, например, ни разу не писал своего блога. Пора исправлять :)


*SAMP
На этой неделе я занялся созданием экрана создания персонажа.
Там у нас предполагается распределение статов, как это например сделано в небезызвестном фоллауте. Но не успев дойти до момента создания TextDraw'a для распределения скиллов я наткнулся на проблему с анимацией камеры. По плану у нас на экране выбора скинов камера движется по разным районам, показывая Actor's в разных скинах. Я сделал это через функции интерполяции камеры, но сразу понял, что это совершенно неудобно для меня, и хранить позиции камеры, настройки и скорости переходов и прочее в исходном коде... ну совсем не хочется.

В результате я решил создать редактор для создания кинематографических (cinematic) камер, которые могут переключаться друг на друга динамический, в зависимости от значения флагов, переменных (внутренних, тех которые созданы для этих камер).
Достаточно сложно описать свою идею детально, в ближайшие дни завершу и предоставляю видео-демку, так будет проще и понятнее.

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

[Fallen A.]

Мне кажется, что все, чем вы, по большей части, занимаетесь, так это то, что пишете никому не нужный текст.

[Black Fox]

Если ты о чейнжлогах, то:

1) Это занимает 10 минут времени, просто не всегда удается выделить это время именно в тот момент, когда есть настроение и ментальное состояние подходящее для написания подобного рода сообщений.
2) Это мотивация и структурирование работы/информации. Даже если это только для нас. Вещи становятся намного более явными, когда ты оформляешь их в виде документов или текста. Не пробовал вести дневники, списки задач, планы? Интересная практика. Написание идей позволяет осознавать их четче, продумывать и видеть больше деталей и ньюансов.

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

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

----
PS: И как альтернативный ответ, более простой:
Мы делаем то, что хотим делать :)
Хотим пишем, хотим не пишем. Правила мы не нарушаем, пишем в своей теме, какие к нам вопросы?

[Black Fox]

*Change Log #3 (от 9.08.2017)
Да-да, это в очередной раз запоздавший чейджлог №3.
Когда-нибудь я смогу следовать недельному графику.

*Mental
Решил добавить новую "рубрику", в которой можно писать о моральном состоянии, о трудностях мотивации, о тайм-менеджменте. Опять же повторюсь: если это никому не интересно это совершенно не беда. Эти заметки дублируются ко мне в Evernote, и писать их имеет смысл как минимум для личного контроля и мониторинга себя, своей производительности, своего настроя и т.д..

В настоящее время из-за большой занятости сложно выделять достаточно времени на разработку.
Код в последнее время пишется без тестирования в игре. Максимум - через консоль сервера. Сейчас имеется уже около 1.5-2 тыс. строк кода, которые я не смотрел в игре вообще.
С одной стороны это интересный и полезный для любого программиста опыт, ведь очень сильно развивает и задействует абстракцию. Но с другой... велик шанс, что при тестировании в игре функции начнут выдавать непредсказуемый результат которого я не ожидал, и в лучшем случае это приведет к правкам кода.

В выходные в последнее время не занимаюсь проектом вообще: стараюсь выделять их под отдых, чтобы не перегорать от большого кол-ва работы.

Из другого интересного опыта: заметил что обещания (даже если в пустоту) довольно сильно мотивируют. Когда вспоминаешь о них, то ощущаешь внутренний пинок, мотивирующий работать усерднее чтобы успеть в срок. Смею заметить, что скорее всего это актуально далеко не для всех. Есть люди которые без зазрения совести могут нарушать сроки и обещания, поэтому данный опыт скорее всего субъективен.

*SAMP

В ходе разработки нашей системы "умных" камер CMT я понял, что нужен какой-то инструмент для админов, который может выделять объекты, двигать их, задавать позиции, вращения...

Так родилась идея админ-тула, или админ-палочки. Это специальный инструмент, который поддерживает различные режимы (неограниченное число, он имеет удобное API чтобы расширяться без изменения собственного кода). Каждый режим позволяет выделять и манипулировать различными объекта (здесь под понятием объект не 3д модель, а сущность: пикап, дома из системы домов, редактирование ЗЗ, создание рекламных щитов и т.д.).

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

Все наши системы будут использовать данный инструмент (если он им нужен, разумеется).

===========================================================================

На данную неделю все. К сожалению пока мало визуала который можно показать, но надеемся через месяц (а может и меньше) мы уже начнем демонстрировать скриншоты и гифки систем.

Здесь, как и в разработке любого другого ПО справедлив закон Парето. Сейчас у нас те самые сложные 20% результата и 80% работы, которые отвечают за основную программную базу сервера :)