Урок %count% причин не писати скрипти в SA MP Архів - Pro Pawn - Портал про PAWN-скриптинг
Передмова: На одному відомому, шкільному форумі у модератора дуже згоріло з цієї теми і він її видалив. Сподіваюся тут народ буде адекватнішим.
Назва %count% вказує на безліч, яка може бути змінена залежно від випущених багів фіксів у клієнті SA-MP.
Фактично, у цій темі ми порівнюватимемо кілька мультиплеєрів:
San Andreas Multi Player: http://sa-mp.com/ Multi Theft Auto: http://mtasa.com/ Just Cause 2 Multi Player: http://jc-mp.com/ Mafia 2 Multi Player: http://m2-multiplayer.com/ IV-Network: https://github.com/IV-Network/IV-Network
Кожен із вищеперелічених мультиплеєрів має свої унікальні фітчі, але ми займемося мультиплеєром SA-MP.
Як відомо у SA-MP багато проблем як на рівні самого клієнта, так і на рівні скриптингу.
Проблема №1: Як на мене, головною проблемою є наявність Античита. У SA-MP античит на рівні мультиплеєра відсутня наглухо. Коли Mult Theft Auto свій самописний античит, а JC2MP використовується VAC. Ця проблема є і в інших мультиплеєрів з нашого списку.
Проблема №2: Повна відсутність клієнтської частини SA-MP. Клієнтська частина SA-MP відсутня, тому всі графічні роботи йдуть через сервер, а не завантажується на клієнт. У решті мультиплеєрів клієнтська частина присутня. Тому SAMP підвантажити картинку клієнту чи полегшити роботу серверу практично неможливо.
Проблема №3: Проблема доступу до коду. Можливо, у SA-MP було б менше проблем, якби SAMP Team відкрили деякі модулі вихідного коду, щоб спільнота допомагала у виправленні помилок. Але відкритий код є тільки у двох мультиплеєрів MTA SA (крім net-модуля) і IV-Network (повністю).
Проблема №4:Front-end. У SAMP на весь дизайн, який буде видно гравцеві, відведено лише пару діалогових вікон та функції для малювання TextDraw. У всіх інших мультиплеєрах для діалогових вікон є бібліотека CEGUI. Та й ще підтримка деяких графічних функцій dx (У МТА, наприклад, є підтримка шейдерів).
Проблеми написання скриптів
Проблема №1: Скриптингова мова програмування. У SAMP використовується підозріла мова pawn (В Source/Gold Source використовується SourcePawn, який трохи відрізняється). Ця мова є затиснутою і гнучкою плюс до всього в ній відсутня підтримка класів і структур. Та й мета мови Pawn була зовсім іншою. Інші мультиплеєри використовують більш спеціалізовані ЯП. Такі як Lua або Squirrel.
Проблема №2: Модульність. Сервер SAMP має погану модульність. Не можна розбити 1 гейммод на кілька ресурсів, щоб було зручніше працювати у великій команді. Та й видимість змінних у фільтр-скриптах кульгає.
Проблема №3: Невелика кількість бібліотек. Наприклад, було б зручніше в координатах, rgba кольорах, позиціях камер використовувати вектора, а не окремі числа, підхід до векторів використовується в JC2MP.
Проблема №4: Як я повторювався вище, відсутність класів та структур. Процедурне програмування не завжди призводить до чогось корисного, тут я скористаюся цитатою відомого програміста: «Якщо не виходити за кордон «об'єктно-орієнтованих» методів, щоб залишитися в рамках «доброго програмування та проектування», то в результаті обов'язково виходить щось , здебільшого не має сенсу. ООП використовується в MTA, JC2MP, IV-Network.
Наприкінці хочу сказати, що я перерахував лише найглобальніші проблеми, дрібні витоки пам'яті, дивно-консервативну спільноту таінше я не брав до цього списку.