Pull to refresh
6
0
Денис Ефимов @SpiderMan

Пользователь

Send message
Классический алгоритм никто не сможет написать, он не сможет предусмотреть миллиарды ситуаций. А обучить сеть до достаточно высокого показателя надежности — можно. Вдобавок, перечитайте еще раз слова Маска по поводу лидара — это тупиковое решение
Когда автопилот будет готов с надежностью 99.9999% никто о таком даже думать не будет
Глухонемые ездят не полагаясь на слух и автопилот сможет. В хорошей машине такая звукоизоляция, что шум колес все равно не услышишь.
Ну я сам предпочитаю работать с одним моником — дело привычки и специфики работы. Как по мне, геймдеву в первую очередь нужно пространство — чистый широкий рабочий стол: разместить планшеты, мышку, клаву, бумагу зарисовки/заметки делать, наушники/колонки. Не помешают перегородки вокруг (изолироваться от окружающих отвлекающих движений, на перегордки можно цеплять разные рисунки, заметки). Во вторую очередь меня беспокоит хорошее кресло.
Посмотрел на эти рабочие места — стал ценить свое место, оно лучшее в мире, по сравнениею со всем этим ) А вообще, ожидал увидеть что-то, чтобы перенять идею, а у них все скучно и бардак на столах. Автору спасибо за перевод, в любом случае
А вот мне, наоборот, стало понятнее )
А что если это будут не пули, а тяжеловесные объекты? Предположим, у нас генерится случайный мир и вероятность такая, что обычно каждый вид объекта попадает на сцену в количестве 10 штук. Но иногда случайно все же может быть сгенерировано 20 одинаковых штук. В этом случае пул досоздаст 10 объектов. Если их не уничтожить, то так и будем их таскать всю игру, даже если больше никогда не сгенерится 20 штук. Опять же, такая ситуация может случится и с другими видами объектов. В итоге получим, что вместо 10 штук на каждый вид, будет храниться 20 — т.е. памяти потребуется вдвое больше. А еще один плохой момент, это что вначале игры памяти будет хватать, а в процессе она будет захватываться. Поэтому я бы может быть даже ввел счетчик и подстраивал размер пула под текущие нужды
1. Как на счет того, чтобы сделать размер пула? В большинстве случаев объектов внутри этого размера должно хватать для сцены. Если иногда возникает ситуация, что нужно создать чуть больше объектов, то пул создает их и уничтожает при последующем освобождении, вновь оставляя в пуле только обычное количество объектов.
2. Может быть имеет смысл инициализировать все пулы с заданным количеством объектов перед загрузкой уровня, чтобы не возникало скачков FPS при создании объектов во время игрового цикла? Т.е. пул не досоздает объекты по мере необходимости, а перед стартом уровня создает их с запасом и потом выдает только готовые.
Там разница между некоторыми играми в 1 год. Да и все равно все гуглят и находят эти даты, так что сомнительный вопрос на выявление увлеченности этими играми. Я таким вообще не увлекаюсь, но ответил на эти вопросы
1. Не, стрелки не заменят страшных шевелящихся тварей
2. Дерево одно, и если его сожрут, то оно упадет. К тому же это будут уже не пауки, а бобры )

Вот скрины, чтобы было понятно как выглядит игра: ludumdare.com/compo/ludum-dare-34/?action=preview&uid=66055
Ваши статьи можно заносить в учебник по гейм-дизайну. Спасибо

А теперь можно посоветуюсь с вами? У меня мобильная 2D игра, совсем не похожа на Crossy Road, но игровая физика в общем-то как брат или сестра этой игры. Игра вертикальная, белки убегают по дереву вверх. Задача: заставить игрока бежать вверх не останавливаясь. Был вариант догоняющего огня, но теперь за белками гонятся пауки. Текущая реализация такая, что камера сопровождает белок, а пауки движутся снизу с одинаковой скоростью. Когда они догоняют белок, то их становится видно. И тут я вижу два серьезных недостатка:
1) Игрок не видит пауков постоянно, а значит расслабляется когда их нет. А когда пауки появляются в кадре, то они уже слишком близко (опасно) и их все равно плохо видно (пальцы игрока перекрывают частично пауков).
2) Игрок может оторваться от пауков очень сильно и потом расслабиться. Или не расслабляться, но всегда идти впереди, не чувствуя дыхания пауков в затылок. Еще плохо и то, что не видна как близко пауки (вводить еще один индиктор — не вариант, уже есть scores и кнопочка выхода в меню.

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

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

Может подскажете что-то? Спасибо
В Battlefield тоже так было: вы покидаете зону ведения боевых действий и отсчет. А ведь можно было обыграть, например, залпами ПВО по летающим объектам, они бы длились те же 10 секунд, отнимая чуть-чуть hp каждый раз. Наземную технику приследовали бы ракеты или минометный огонь, опять же, невидимого противника. Но игрок бы понимал опасность выхода из зоны и не погибал бы сразу, очутившись там по ошибке
Я думаю главная ваша ошибка была в том, что вы не начали с малого и что у вас не было, как вы говорите, стратегии. Но материал все равно полезный, спасибо
Участвовал в Ludumе, делал Vaviorki про двух белочек. В твою игру тоже играл. Игра действительно сложная для реализации в 2 дня
Спасибо за перевод, обязательно переводи вторую часть, очень полезный материал
Скачайте книгу автора, она всего 8 страниц, но там все самодостаточно изложено. Книга бесплатная, нужно лишь зарегаться на сайте
Мне кажется json читается человеком легче, чем XML. Системой он читается (обрабатывается) также быстрее.
Спасибо за перевод, статья офигенна!
Из комментариев выше, автора не смущает вообще ничего )

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity