Monthly news

>Walking forward<

Hello, after almost six months of silence HoneyBadger again out on bond. I don't really like to write texts, because what I'm doing is not fully clear to the average user. The common goals that I pursue as a programmer in this project are to make our game running quickly and conveniently available on any device and to prepare a platform for easy implementation of all our crazy ideas. Below is a boring description of all the things I do.

Current task:

Create a proper online application.

Completely get rid of outdated and unnecessary code.

Optimization game events for easy future development.

Refactoring:

We are at the stage when the graphical interface of the "designer", which we chose at the beginning of our way turns from a good assistant to a novice game developer, into a limitation. "Underside" - the framework can be arbitrarily long to change to suit your needs, but the graphical interface through which files are created game maps and events can not be changed. And the methods of creating game logic that he offers are no longer suitable for us. After a year and a half of development, the game was filled with a huge number of duplicate code, excessive complexity and high connectivity of fragments. I tried a lot of methods of code structuring, but in the end I came to something similar to "normal" programming. From the basic system remains one "skeleton". Event lists have been turned into independent "functions" that support the transmission of arguments, the built-in system of variables has faded into the background and is replaced by a new one that supports multiple scopes, event lists are cleared of unnecessary data, become well readable, there is a certain "standard" of development. According to my estimates, after the final refactoring of all game events, the number of game script code will decrease by 30-40%. All this is necessary for quick changes in the future and easy debugging. At the same time, it became possible to design "memories" taking into account arbitrary branches of history.

Naturally, in the process of changing game events, the code of the framework is also constantly modified. Every day the missing functionality is created and the code of old solutions is reprocessed.

Debugging:

In parallel, we are working with the extension of the logging system, each action will generate a record in the log with all the necessary data. Users will be able to back up their problem descriptions with a detailed log file. In the end, all bug reports will be sent to a centralized server and we will know where, when and under what conditions the error occurred. All this reduces the time for troubleshooting several times.

Resource optimization:

Imagine a server where hundreds or even thousands of people receive files every day during their own gameplay. The size and number of these files directly affects the loading of channel and server resources, and hence the smoothness of the gameplay of each player. The first priority is to reduce the size of the game assets as much as possible. This will help us such things:

Already announced system of "collages".

Localized delivery of resources within a single loader. The ability to intelligently start downloading the necessary resources before they need the user to wait for the download in key places, and so on.

A new sound system that allows you to pack sounds in "sprites", that is, having a dozen short sounds, we can easily add up to one file and the number of requests to the server will drop sharply.

Something about the sound:

The new system has in its core pixi-sound library, with a rather complex wrapper. I think I added so much possibilities that all of them have no place to use at the moment. Each sound has tags that can be used to manipulate arbitrary groups of active sounds. It is possible to save and restore the current map of sounds with all related parameters. There is a system of additional modifiers, for example, you can "mute" any group of sounds for any time. There is a system of sound range, which is widely used now, no sound porridge on the cards will no longer be, the sound volume gradually increases with the approach of the player to the source. The sounds will be divided into several main groups: "background", "music", "voices", "current event", "steps". The users will be able to adjust their volume at their discretion.

>Demonstration<

The system of "memories":

In fact, "memory" is no different from an ordinary map with standard game events, the problem is that the early approach to their creation was catastrophically excessive. Each branch of the development of the plot had to be created from the original by collecting commands from the main script and creating a separate list manually. What if there are three or six branches? A huge number of duplicate and sometimes even not the same code, many copies of the original maps. This approach is simply unacceptable. Fortunately, the current development model allows with just a few commands to reproduce any past event with all the variations. If we have to correct the original - then all of its variations in the memories will also change. So all the necessary game challenges are isolated in the memory scenes and do not affect the main gameplay. Now make a replay was a matter of thirty minutes.

As you know what the user sees in the course of the game depends on his actions and talent class. If the player wants to get all the erotic content in the game he will have to go through the game several times. The progress indicator will cover the current player's experience and all the past saved games, it will be possible to easily "playback" all the variations of events, regardless of where the player is at the moment.

Conclusion:

Experience appears in the process and many solutions created earlier do not stand the test of time. But without mistakes unfortunately no development is possible and I am very grateful to you for the opportunity to move forward. All the best to you.

And a few words from HandlessGhoul.

Being distracted from the main events development, thoughts about different things come to mind. One of these ideas is personal transport. In the F2 was a Highwayman, so adding a car would be unoriginal. Our choice was stopped on a sidecar motorcycle. This is quite unusual and suitable for our restriction of the group to two companions. For a basis we took the motorcycle "Ural", below you can see an example of appearance, with tuning and without.

We also add more interactivity to the game. Now most of the consumable items can finally be used, and each of them will have its own unique picture, in addition to the inventory icons. Similar to the use of a stimpak.

Continuing the theme of thoughts about the future. Working on the sprites for Dogmeat, initially there was a mistake in size, because of what he turned out just huge. But since we do not throw anything away, the idea arose that at some point, having high enough...ahem, relationship with the Dogmeat, it will be possible to change him, with the magic of friendship and a pinch of FEV. This "super" Dogmeat will be much stronger, as well as it will be possible to ride, moving rapidly on the global map, if the group you do not have other companions. These are ideas.

One last, I would like to show you something very old. When the game was just beginning to be developed, for it was supposed to have a completely different visual style. Initially, it was assumed that all objects and characters will occupy only one cell, similar to the default RPGM style.

Yep, it is perceived completely different. But who knows, maybe we can use this somewhere too. Hehe~.

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

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

Текущие задачи:

Создать полноценное онлайн-приложение.

Полностью избавится от устаревшего и лишнего кода.

Оптимизировать игровые события для лёгкого развития в будущем.

Рефакторинг:

Мы находимся на стадии когда графический интерфейс "конструктора", который мы выбрали в начале нашего пути превращается из хорошего помощника начинающему гейм-разработчику, в ограничение. "Изнанку" - фреймворк можно сколь угодно долго менять под свои нужды, но графический интерфейс, посредством которого и создаются файлы карт и игровых событий изменению не поддаётся. И методики создания игровой логики которые он предлагает больше нам не подходят. Спустя полтора года разработки игра стала наполнена огромным кол-во дублирующего кода, избыточной сложностью и высокой связанностью фрагментов. Была перепробавана уйма методик структурирования кода, но в итоге я пришёл к чему-то похожему на "нормальное" программирование. От базовой системы остаётся один "скелет". Списки событий были перевращены в самостоятельные "функции", поддерживающие передачу аргументов, встроенная система переменных отошла на второй план и заменяется новой, поддерживающей несколько областей видимости, списки событий очищаются от лишних данных, становятся хорошо читабельными, появляется определённый "стандарт" разработки. По моим прикидкам после окончательного рефакторинга всех игровых событий кол-во кода игровых сценариев снизится на 30-40%. Всё это необходимо для быстрого внесения изменений в будущем и лёгкой отладки. Вместе с этим появилась возможность конструировать "воспоминания" с учётом произвольных веток развития истории.

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

Дебаггинг:

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

Оптимизация ресурсов:

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

Уже анонсированная система "коллажей".

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

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

Кое-что о звуке:

Новая система имеет в своём ядре библиотеку pixi-sound, с довольно сложной обёрткой. Кажется, я добавил туда столько возможностей, что все их пока даже некуда применить. У каждого звука есть теги при помощи которых можно манипулировать произвольными группами активных звуков. Есть возможность сохранять и восстанавливать текущую карту звуков со всеми сопутствующими параметрами. Есть система дополнительных модификаторов, например можно на произвольное время "приглушить" какую-либо группу звуков. Есть система дальности звука, которая повсеместно применяется уже сейчас, никакой звуковой каши на картах больше не будет, громкость звука плавно нарастает при подходе игрока к источнику. Звуки будут разделены на несколько основных групп: "фоновые", "музыка", "голоса", "текущее событие", "шаги", пользователь сможет регулировать их громкость по своему усмотрению.

Система "воспоминаний":

Фактически "память" ничем не отличаются от обычной карты со стандартными игровыми событиями, проблема в том что ранний подход к их созданию был катастрофически избыточным. Каждую ветку развития сюжетного момента приходилось создавать из оригинального посредством сбора команд из основного сценария и создания отдельного списка вручную. А если веток три, а если шесть? Огромное кол-во дублирующего и местами не одинакового кода, множество копий оригинальных карт. Такой подход просто неприемлим. К счастью, нынешняя модель разработки позволяет буквально несколькими командами воспроизвести любое прошлое событие со всеми вариациями. Если нам придётся поправить оригинал - то все его вариации в воспоминаниях тоже изменятся. Так же все необходимые игровые вызовы изолированы в сцене воспоминания и никак не влияют на основной игровой процесс. Сделать реплей стало делом тридцати минут.

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

Заключение:

Опыт появляется в процессе работы и многие решения созданные ранее не выдерживают проверку временем. Но без ошибок к сожалению никакое развитие невозможно и я очень благодарен вам за возможность движения вперёд. Всего вам доброго.

И несколько слов от HandlessGhoul'а.

Отвлекаясь от работы над основными эвентами, в голову приходят разные мысли. Одна из таких идей - личный транспорт. В F2 был Хайвеймен, поэтому добавление автомобиля было бы неоригинальным. Наш выбор остановился на мотоцикле с коляской. Это довольно необычно и неплохо подходит для нашего ограничения группы двумя компаньонами. За основу мы взяли мотоцикл "Урал", ниже вы можете увидеть пример внешнего вида, с тюнингом и без. 

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

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

Напоследок, я хотел бы показать вам кое-что очень старое. Когда игра только начинала разрабатываться, для нее предполагался совершенно другой визуальный стиль. Изначально планировалось, что все объекты и символы будут занимать только одну ячейку, аналогично стилю RPGM по умолчанию.

Да, это воспринимается совершенно по-другому. Но кто знает, может мы и это тоже сможем где-то использовать. Хехе~.