REDIRECT I SAID

Hey! This blog is out-of-date! If you read this actually, you can add&subscribe me:

1. Follow me on twitter @eliaskuvoice (i follow back)
2. Read my new microblog (RSS)
3. I have ru-lang group in VK, join us!

Cheers!

Срочные выпуск новостей для ребят и котят!

В этом блоге давно перестали появляться новые публикации! И их здесь больше не будет! Однако заявляю, что события всё-таки будут: например, сейчас идёт разработка супер-римейка оригинальной игры DUCKSTAZY! Да и вообще, о моих новых играх теперь можно будет узнать только из представленных ниже источников!

Подписывайтесь на мой новый микроблог или на мой twitter @eliaskuvoice! Вконтакте есть добрая группа digiduck games вступайте в неё, если еще нет!

Итак, еще раз:

1. Подписаться на мой Новый блог (если угодно RSS)2. Следовать за мной в твиттере @eliaskuvoice (фолловлю в ответку)3. Вступить в группу digiduck games вконтакте

Погнали!

Redirect

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

GraviLens Rebuilding News.

(кликабельно)

Луч. Сегодня сделан первый шаг к порталам. Наконец-то дошли руки написать перенос луча. Потом для теста заюзана правая стена, которая телепортирует луч к левой стене. На скриншоте всё вроде понятно. Теперь можно приступать к грави-порталам. Заодно, наверное, напишу направляющие и линкеры.

(кликабельно)

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

***

Ну вот на след. неделе времени совсем не будет, но я постараюсь написать новую puzzle-систему и проверить её. Ну и рисовать придёться много-много...

А вот ещё на своей диарее написал про мое негативное отношение к UML. Это касается только независимой разработки одним человеком конечно.. xD

GraviLens. Items? Slots! #2

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

Гипотетические изменения #1. Предметы остаются такими же, вводим слоты. Слоты, их вид и количество на каждый объект задаются в xml карты, тем самым убираем злую свободу действий и упрощаем дизайн уровней. Устранили 1, 2, 3 минусы и убили тем самым все особенности первой теории, чёрт с ними.

Изменения в графическом контенте:

1. Каждый предмет требует под себя картинку со слотом.
   
2. Желательно сделать подсветку вставленного предмета.
   

Чтобы легче представить изменения, приведём несколько примеров:

1. 3 ключа (2 звезды и 1 серп). При полном заполнении слотов объект отключается.
   
2. 2 фильтра и 2 зеркала. При постепенном заполнении изменяются свойства объекта: каждый фильтр убирает часть дисперсии, а каждое зеркало вычитает часть поглощения.
   

Использование предметов не изменилось: сбиваем и используем. Можно вытащить используемый предмет из слота и вставить его в слот другого объекта, совсем другая свобода действий. 4-ый минус первоначальной теории усиливается. Теперь это очень длинный минус: вставленные в слоты предметы двигаются по орбите вокруг объекта и занимают дополнительное пространство, которое может использоваться игроком для прицеливания. Когда игрок прицелиться, курсор нечаянно наедет на предмет, и при нажатии кнопки «огонь» – выстрела не будет, он всего лишь захватит предмет.

Работа над последним минусом. Какие вообще идеи появляются, когда вопрос касается 4-ого минуса.

1. Предметы нельзя доставать из слотов. Всё очень просто, упор сделан на дизайн уровней. Хороший вариант.
   
2. Предметы нужно повторно сбивать. Вообще бессмысленно.
   
3. Добавить дополнительную механику для выковыривания предметов. Плохо.
   

Гипотетические изменения #2. Из предметов, которые можно вставлять в слоты, оставить только ключи. Ключи нельзя доставать из слотов. При заполнении слотов объекта, выполняются заскриптованные действия. Например, если слотов пять, то всего доступно будет описать 5 скриптов. Если мы хотим повесить скрипт на полное заполнение – вставляем только скрипт с кол-вом ключей =5. Скрывать после этого вставленные объекты, думаю, не нужно. Просто поставить полупрозрачность, т.к. они всё ещё будут заполнять пустоту игрового поля. Графическое наполнение уменьшается за счёт отмены фильтров, зеркал и антигравитации. Так мы вроде разобрались со всеми минусами первоначальной теории.

GraviLens. Items? Slots!

Я начал гипотетическое выстраивание новой концепции.. Проблема в том что игроку непонятно куда засовывать ключи. Для этого вводим слоты. Слоты расположены возле гравилинзы и медленно летают по орбите. Слоты бывают разной формы. Если все слоты гравилинзы заполнены, то выполняется действие, описанное в xml уровня. Форм ключей и слотов должно быть минимум три. Пока есть две: звезда и лунный серп.

Пока под вопросом следующие моменты, касающиеся только механики работы с ключами:

1. При сборке группы слотов и выполнения некоторого действия, слоты исчезают или остаются?
   
2. Если слоты остаются, то можно ли обратно достать ключ, и если можно, то какой эффект это произведёт?
   
3. Можно ли вообще доставать ключи из слотов? Если можно, то не будет ли рука (курсор при наведении на вставленный ключ в слот) мешать прицеливанию?
   

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

Эмпирическая теория (см. конкурсную версию).

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

Взаимодействия:

Ключ – выключает гравилинзу. В гравилинзах можно прописывать кол-во ключей для выключения, если в параметре указан ноль – выключить нельзя и ключи не лепятся к гравилинзам.
Зеркало – уменьшает параметр поглощения, что заставляет гравилинзу или поверхность отражать. Лепится, если поглощение >0.
Антигравитация – уменьшает массу. Можно прилепить, если масса != 0.
Фильтр – уменьшает дисперсию поля. Лепится, если дисперсия !=0.

Особенности:

1. Универсальность.
   
2. Эксперимент. Игрок должен найти гравилинзу, свойства которой можно изменить.
   
3. Минимум графики.
   

Плюсы подхода не очевидны, но явно видим минусы:

1. Игрок не знает, чего мы хотим от него. Мы хотим чтобы он выключил гравилинзу тремя ключами или вставил зеркало в поверхность, но это никак не отображается визуально и игрок просто в замешательстве: что ему делать с этими предметами...
   
2. Графика становится непонятной. Мы выключаем гравилинзу, а предмет висит в воздухе. И что мне его опять можно сбить, ведь он такой и висел в начале до того как я его сбил, правда в другом месте...
   
3. Универсальность плохо. Ну, у гравилинзы все параметры, есть много предметов, ну и мы начинаем лепить на неё всё что можно. Предметы накладываются друг на друга, превращаясь в большую некрасивую кучу. А может вообще не нужно ничего делать с этой гравилинзой?
   

Продолжение следует...

Singularity.

Началось всё с локализации. Задумался о том как это делается в моём фреймворке. Допустим звуки переводить не нужно. Переводим текстовку и меню. Есть какой-нибудь strings_en.xml с таблицей идентификаторов и строк. Переводим всю эту бадягу. Всё отлично. Запускаем и видим что перекосячило некоторые элементы GUI. Ну я компилирую просто вариант игры с тем же меню но с флагом GUI_EDITOR, подгоняю позиции/размеры и радуюсь.

Но теперь к чему я это всё написал. Редактор, как и все тулзы, не должен быть in-game. Не так давно прочитал на gamedeff про кубики и монолиты. Очевидно что редактор гуи должен работать только с лайерами гуи и не обязан отображать все переходы, эффекты и in-game подстановки. В итоге мы имеем: сингулярный тулз к любым гуи лаерам, упрощённый код гуи в фреймворке, и геморой с игровыми custom контролами. Как просто и элегантно решить последнее до сих пор думаю...

GraviLens KV.

Хе, в минских Компьютерных Вестях написали про конкурс и GraviLens. Очень забавно читать как случайные люди рецензируют продукт твоего воображения, правда. Всё одно, какой-то фокус-тест. Чего я там не нашёл, так это бэклинка на блог.. Газета минская.. Я тоже из Минска, об этом тоже не написали :( Буду плакать. Наверное автору лень было капать что-либо о разработчиках. Вот почему я так неравнодушен к блогам инди-игр. Там не только о больных играх, но и о таких же разработчиках.

Music Adventures.

К музыке часто делают видеоряд, клипы. На концертах делают performance. Но видео игры пока остались не затронутыми. Пока только делали музыку для игр. Я вот думаю каким успехом будет пользоваться музыка к которой написана rhytm-based игра. Причём игра жёстко по сеттингу привязана к теме песни, а ещё круче к теме всего альбома. Мне сразу представился атмосферный хардкорный rhythm based платформер написаный под акценты The Dillinger Escape Plan - Ire Works

Hunt For Hunters.

Появилась идея перевернуть игру про охоту на уток. Управлять пришлось бы стайкой уток, уворачиваясь от огня с земли и воздуха. От стрел, пулемётов, ракет и т.д. Если добавить возможность рвать охотников на мясо - получается action swarm. Всё по закону жанра.

GraviLens Dwarfs.

Я сегодня опять экспериментировал. В этот раз на карликах. Закончил и испытал оргазм.

На картинке изображены карлики. Первые два ряда демонстрируют фазы кручения карлика со скоростями(игровыми) от 1 до 5 рад/сек. На статичной картинке движения нет, но мне нравится как оно смотрится в игре. Снизу зелёный карлик, просто для него я на тот момент не прописал в GraviLib(см. в конце) параметры для вихря. А чёрный карлик - это нейтронная типо звезда. Когда видешь вращение - реально завораживает. Даже ничего размывать не нужно. Ах, и ещё крона звёзд медленно светиться: масштабируется.
Резюмирую: это мой первый успешный эксперимент за всё последнее время.

Рисуем в три шага:
1. Крону с добавочным смешиванием. (никогда не вращается)
2. Сама гравилинза. (никогда не вращается)
3. Вихрь, прозрачность которого зависит от его скорости вращения.

Вся графика для карликов заняла 5кб. Одна белая крона, ставим нужный цвет умножением. Три гравилинзы, нейтронную рисуем умножая на 0xff000000. Жёлто-красный вихрь. Зелёным вихрь делаем обрезая красный умножением.

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

Дальше надеюсь поэкспериментировать с небом, опять же когда будет свободное время.