Многие заметили, что некоторые вещи работают медленно, некоторые работают неудобно, иногда просто тупит.
Я провёл расследование и нашёл двух виноватых:
1. Тяжёлые сетевые зависимости в коде.
2. Недостаточные ресурсы сервера
С первой частью я уже решил проблему в выборе тэгов (это можно видеть уже тут) и также изменил логику работы веток комментариев, и переписал логику проставки оценок.
Сейчас на тестовом сервере мы с командой гоняем большое обновление с некоторыми нюансами, которые помогут упростить несколько моментов по работе. Это частично устранит первую причину.
А для устранения второй причины мы пришли к выводу, что будем переезжать на более мощный сервер. Настройка нового сервера займёт несколько дней, а начну я его настраивать уже завтра. Надеюсь уложиться в неделю максимум. После этого произведём переезд. О нём, конечно же, оповестим всех через официальные каналы связи. После чего, я полагаю, пользоваться ресурсом станет значительно приятнее.
Посему прошу у всех ещё чуть-чуть терпения. Я делаю так, чтоб всё становилось лучше и не планирую останавливаться, пока не отполирую наш с вами сайт до блеска.
Приступаем к вопросу создания игровых уровней. Для того, что бы натворить нашу первую игровую локацию, нам необходимо подготовиться: выспаться, умыться, привести мысли в порядок.
Самая фиговая идея садиться делать уровень просто открыв редактор и начиная что-то накидывать на сцену. Этот метод, конечно же, тоже допустим, но он в той же мере непрактичен, в какой и хаотичен. А я напомню, что слово дизайн с английского переводится не как «Сделать красиво», а как «проектировать».
Поэтому, прежде чем начать нам нужны пара тройка вещей.
1. Идея
Идея – это вообще очень всеобъемлющая концепция, но тем не менее, если вдруг вы ехали в автобусе, и у вас в голове родилась какая-то крутая механика, или офигенный визуальный приём, или концепция локации или даже целого сюжета, сразу же запишите себе это куда-то. Нет никакого смысла сделать локацию без привязки к идее. Если нет какой-то особой идеи именного для игрового уровня, то должна бы идея для всей игры, и локация должна на эту идею работать.
2. Синопсис
Прям как в книжечках. Иными словами, вам нужен текст, который в пару тройку предложений или абзацев, без подробностей опишет вам, что же за уровень вы сейчас будете делать. и самое главное зачем этот уровень вообще существует. Какую цель он преследует (обучение, боевой сегмент, головоломка, место, чтобы дать передышку и т.д.).
Даже если ваша игра в большой открытом мире, создавать и наполнять вы его будете по частям, так что не надо делать весь мир сразу. Вы делаете стартовую деревню/комнату/пещеру и потом перемещаетесь к следующим этапам игры, каждый прорабатывая отдельно.
3. Схема/План
Это не должен быть точный инженерный план здания, со всеми помещениями и проложенными коммуникациями. Это должно быть схематическое изображение примерного расположения элементов и помещений. Препятствий и возможностей.
Как проектировщики уровней, вы должны продумать хотя бы минимально на начальном этапе, что игрок сможет увидеть, а что нет, а как он сможет воспользоваться той или иной областью на карте.
Трюм корабля из Divinity Original sin 2
План должен ответить ещё на один вопрос: маршрут передвижения. Чем открытие мир/локация, тем сложнее продумать этот элемент, но хотя бы один, основной надо предусмотреть.
Приведённая мной в пример локация является обучающей, поэтому маршрут в ней строго определён. И, хотя игрок, конечно же, может пойти иначе, механики игры ему подсказывают более лёгкий путь.
Управлять вниманием игрока и направлять его в нужном вам направлении можно с помощью точек интереса, которые можно продумать сразу, а можно внедрить после плейтестов или уже на этапе детализации, если возникнет подозрение, что игрок тут заблудится.
4. Контроллер персонажа.
Если вы собираете уровень. По нему нужно уметь побегать. А значит вам нужен какой-то человечек. Это может быть стандартный капсуль или кубик, но важно помнить, что масштабирование объектов на сцене должно отталкиваться от масштаба контроллера персонажа. Если сделать капсулу, запишите себе, что она росном метр восемьдесят. И когда будете строить сцену, необходимо будет подстраиваться под этот размер, чтоб не быть великаном или лепреконом в неизвестно для кого построенном мире.
Чем линейнее ваша игра, тем вам будет проще проектировать свои уровни. Но это не повод намеренно превращать движение персонажа в рельсы. Игроки любят свободу. И даже в линейных играх им необходимо дать иллюзию этой самой свободы. Более того, нужно ещё и поощрять исследование.
Переулок, через который нельзя пройти? Пусть там будет не просто тупик, а иллюзорно открытый проход, но неиллюзорно смертельная опасность или препятствие.
Закуточки с секретками или пасхалками. Все эти элементы всегда можно внедрить на любом из этапов разработки. Но если есть хорошие мысли до того, как вы начали, почему бы их не зафиксировать на плане?
Есть метод для планирования романов (ну и вообще любых историй), называемый методом снежинки (придумал дядя по имени Рэнди Ингермансон). Если по простому, то это одна из версий «От общего к частному».
Метод очень удобный и мне лично помогает не запутаться в сложных сюжетах, но нормального ПО для него практически нет (ну или я не находил).
Для андроидов есть Фабула. А для ПК (винда) я решил таки написать сам с небольшими вольностями.
Был у меня раньше курс видео по этой теме. В целом оно всё ещё актуально, но я решил чуть обновить некоторые моменты и скомпоновать в виде текста, так как не у всех есть возможность смотреть видео.
План будет следующим:
Препродакш
Прототипирование
Детализация
Оптимизация
Ландшафт
Точки интереса
Свет и цвет
Звук
Всё постараюсь сделать с актуальными на сегодняшних день скринами.
Если есть вопросы, предложения, пожелания, пишите. Если чувствуете, что в моём списке не хватает каких-то важных тем, тоже не забудьте мне об этом сказать.
Раз уж я тут книжками занимаюсь, логично было, что мне надо как-то эти самые книжки верстать делать спуск полос.
Я знаю, что есть программы для этого, но ни одна из них мне не показалось достаточно простой и понятной. Не исключаю, что я криворучка и не разобрался, но я решил пойти по пути простоты: написать такую программу самому.
Второй причиной для такого решения было то, что я немного погуглил, нашёл несколько решений. Первые ссылки в гугле - платные приложения. Это мне не подходит.
Что ж, как и любой бесплатный аналог платного ПО, моя программа просто обязана была иметь убогий интерфейс. Я пошёл дальше, и решил, что не буду делать его вовсе. Это консольное приложение. Но мне искренне было впадлу рисовать кнопочки и поля, а потом писать под них обработчики, когда нам надо знать всего три параметра для работы.
1 параметр обязательный, второй и третий можно опустить, тогда начинать программа будет с первой страницы и верстать по 4 листа (16 страниц) в одной тетради.
А для первого параметра в винде есть "киллер фича": клацаем правой кнопкой мыши по файлу с зажатым при этом шифтом и там вот такая вот строчка будет
Пара скриншотов из цикла было-стало
С итоговым файлом нужно поступить следующим образом: просто отправить его на печать, поставив галочку двусторонней печати. Можно хоть на обычном принтере домашнем, хоть пойти в ближайшую типографию. Двусторонняя печать и вы получаете набор готовых к сшиванию тетрадей.
Сделал программку только для ПДФок, так как это универсальный формат для печати. В Ворде уже есть удобный встроенный инструмент брошюрования, а любой другой формат можно быстро перегнать в тот же ПДФ при желании.
Как вы могли заметить, а если нет, то я вам рассказываю, вкладка Лучшее у нас показывает что-то не совсем поддающееся логике.
А всё по тому, что никакого Лучшего у нас ещё нет, мы ещё думаем над алгоритмом, и параллельно ведём споры о том, как должно работать горячее
Статистика
Из чего некоторые из членов команды решили, что сейчас порог слишком высокий, поэтому я изменил формулу рассчёта и 18, которые стояли сегодня утром, превратились в 16.
Будем ещё наблюдать, возможно, математика ещё изменится.
Я хочу чтобы вы знали: порог горячего напрямую зависит от вашей активности. Не забывайте ставить оценки всему, что вам нравится и не нравится.
Этим постом я начинаю серию публикаций о том, как я разрабатываю систему для ведения интерактивный НРИ. В тегах указана пятая редакция Подземелий, но на самом деле речь о любой НРИ. Привязки к конкретным правилам нет, подразумевается, что все необходимые действия (типа бросков кубиков) игроки будут совершать ручками за столом. А программа нужна только для визуализации перемещений, отображения карт и создания показательных боевых ситуаций. Ну и автоматическая выдача опыта, но это опционально и об этом потом.
И так, начнём с самых азов. На чём всё это безобразие будет работать? На Unity. Почему? Да потому что на ней достаточно дёшево реализуется общение с ГПУ, а оно нам тут понадобится.
Полностью рассказывать о том, как и что я сделал смысла не вижу, но буду делиться какими интересными выкладками и, возможно, кусками кода, если они кому-то нужны.
Что мы сейчас имеем: 1. Система приключений 2. Внутри каждого приключения есть система игровых сессий 3. Внутри сессий и приключений есть возможность редактирования базы НИП, заданий, предметов и локаций
Кстати, UI в окне приключения реализован, как мне кажется, достаточно элегантно: он строится динамически, и в него легко буквально одной строчкой можно добавить новые разделы, которые сразу же отрисуются и кнопочкой и панелькой.
Для этого у меня создан класс SectionsManager, который висит в памяти приложения как Singleton. Он хранит в себе информацию о том, какие разделы мы будем использовать. Добавлять их туда можно через конфиги или через код, это уже вопрос того, кому как удобно. А потом есть код, отвечающий чисто за UI и он ждёт от этого менеджера команду, когда тот всю необходимую информацию соберёт и скажет, что вот сейчас уже можно рисовать
Конечно, каждую секцию нужно предварительно настроить и сохранить как префаб, совсем магии тут нет, но зато управление такими секциями становится максимально простым. Не захочет мастер пользоваться функционалом заданий, зачем ему занимать память приложения и заграмождать интерфейс ненужным функционалом. Он его отключит, приложение его выгрузит и забудет до тех пор, пока Мастер снова не захочет им воспользоваться.
Понятия не имею, интересно ли это вообще хоть кому-то, но я искренне надеюсь, что среди пользователей сайта есть люди неравнодушные к программированию, геймдеву и НРИ.
Посему жду комментариев, вопросов, критики, чего угодно.
Если кто-то не знает, кто такое VariusSoft, то посмотрите пожалуйста справа под рандомными комментами в подвальчик)
Что это значит? Ну всё очень просто, есть я такой дофига Напалм, который тут картиночки с рассказиками постит. А есть команда разработки, которая занимается серьёзными программерскими штуками и я хочу делиться ими именно от имени команды.
1. Кто-то скажет: «мультиакк детектед»! Я отвечу: да, но! Это такой способ «узаконить» мультиакк, наложив на него ряд ограничений. Самая главная проблема мультиакка в том, что наделав себе аккаунтов можно натыкать кучу плюсов и минусов, серьёзно обесценив рейтинговую систему. Ну так вот, такой аккаунт не может ставить оценки:
Второй нюанс в том, что на странице профиля такого акка будет прямым текстом написано, кто за него отвечает.
2. Кто-то скажет: «Корпоративный аккаунт детектед». И тут ответ иной: нет, это не корпоративный аккаунт. И если вдруг к нам придёт какая-то мегакорпорация, которая захочет делиться тут своими новостями официально, тогда мы ей скажем: «Пожалуйста, регистрируйтесь на общих правилах и постите на здоровье».
Такой функционал дочерних аккаунтов нужен лишь чтобы разделить ленту по смыслу и по темам.
3. Дочерний аккаунт может быть только один и сам он поддаётся рейтинговым правилам. Если человек будет постить с него дичь и люди доведут такой акк до бана. Ну, значит доведут. Тут и сказочке конец.
Такие акки будут создаваться через админку ручками и по запросу. Первый тематический журнал уже продуман и на подходе. Если ничего не изменится, то вы его скоро увидите.