Войти
ПроектыФорумСобираю команду

roguelike — требуется 2D pixelart художник, желательно js программист (2 стр)

Страницы: 1 2 3 Следующая »
#15
10:24, 17 янв. 2011

Траф, слушай, а как ты круг определяешь? Ну, в смысле до каких точек ты ведешь свои линии?

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


#16
15:47, 17 янв. 2011

Rulexec
У меня не круг(ромб), как у тебя, а квадрат(скрин 1). Это, на самом деле, логично. Ведь если персонаж может ходить по диагонали, то, фактически, расстояние по диагонали на одну клетку должно быть равным расстоянию по вертикали или горизонтали, а значит и видеть он должен во все стороны на опр.кол-во клеток.
Линии веду до клеток, которые образуют периметр квадрата, составляющего весь обзор персонажа (при обзоре 1 клеток 8, при обзоре 2 клеток 16, 3 - 24 и т.д., т.е. 8*обзор). Веду их по алгоритму Брезенхэма, при натыкании на стену - break (если кстати дальше не брейкать, а проверять на наличие СТЕНЫ в следующем квадрате по алгоритму, то, я думаю, можно избежать глюка, как на скрине номер 3. Бывают еще такие глюки, как на втором скрине. Возможно обусловлены несовершенством алгоритма, возможно кривизной моих рук. В целом я результатом доволен (скрин 4), учитывая то, что я совсем не программист, и поделка сделана на гейм мейкере - я с этим мучился два дня, с чужой помощью таки вымучил и потом еще два дня гордый ходил :]
Изображение удалено
Кстати удивлен быстротой работы алгоритма, да еще на гейм мейкере, да на моем доисторическом железе. Летает даже при дальности обзора в 50 клеток.

#17
16:36, 17 янв. 2011

1. Надо не алгоритмы искать (с вашим-то опытом), а самому думать (тот самый опыть повышать) - благо, думать тут особо нечего.
2. Может стоит сначала генерацию уровней сделать и какие-нибудь элементы геймплея, кроме перемещения, а уже потом заниматься освещением и прочими свистелками?
3. О мультиплеере (а уж тем более об ммо) думать нужно в первую очередь, ибо его наличие/отсутствие может в корне поменять архитектуру игры. Хотя, предчуствую, что архитектурой тут и не пахнет...

З.Ы.
Ockonal
> > Сразу, в данный момент мне 16 лет, под конец февраля будет 17, пусть это будет
> > дополнительным фактором, так что думайте, серьёзные дяди.
> Убери, не позорься.
Хитро, очень хитро :D Особенно, учитывая статус участника.
Удали пост, не позорь беднягу. Я свой тоже удалю (часть З.Ы.)

#18
18:28, 17 янв. 2011

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

> Хотя, предчуствую, что архитектурой тут и не пахнет...
В данный момент код полностью переписан, какое-то подобие объектной системы, что-то добавить или что-то убрать выполняется изменением нескольких строк кода.

> а уже потом заниматься освещением
Ключевая часть этой игры, что монстры ведут себя в зависимости от наличия освещения в клетках вокруг, без него никак нельзя :(.

#19
18:48, 17 янв. 2011

Rulexec
Как избежать того, что на третьем скрине я описал. Того, что на втором - без понятия, даже идей нет.

#20
19:04, 17 янв. 2011

Rulexec
На 2м рисунке по-моему, все правильно. Эту клетку и не должен он видеть.

Вообще по-моему какой то странный алгоритм для видимости. Я бы так делал: перебираем все клетки в каком-то радиусе от игрока, и из каждой клетки пускаем луч в игрока и проверяем на пересечение с горизонтальными и вертикальными стенками.

#21
21:12, 17 янв. 2011

Bigfoot
На втором проблема в том, что не видна дальняя клетка, но видна более ближняя, которая по идее за той же стеной и видна не должна быть. И зачем пускать луч из каждой клетки? Хватит тех, которые по периметру зоны видимости. И что есть горизонтальные и вертикальные стены?.

#22
11:08, 18 янв. 2011

Rulexec
Оформи тему пожалуйста получше (нулевой пост).

#23
12:12, 18 янв. 2011

По крайней мере работа идет и все заинтересованны ;)

#24
12:45, 18 янв. 2011

Траф
>На втором проблема в том, что не видна дальняя клетка, но видна более ближняя
Понял, да, действительно.

>что есть горизонтальные и вертикальные стены?
Ну вот клетка - 4 стены. 2 вертикальных и 2 горизонтальных.

>зачем пускать луч из каждой клетки? Хватит тех, которые по периметру зоны видимости
Не хватит же. Если на пути луча будет стена, то клетки от игрока до стены тогда невидимыми останутся. Однако оптимизировать все равно надо, например если луч попадает в клетку, уже определенную как "видимую" или "невидимую", то результат для данной клетки будет таким же.
Вообще этот алгоритм я навскидку предложил, надо просто посмотреть как это в существующих рогаликах сделано.

#25
16:30, 18 янв. 2011

Знаете, я подумал сегодня, и решил таки не делать игру на html5, эти кроссбраузерности, брр. Так же проблемы со звуком в дальнейшем могут быть и с сетью (для полной поддержки всех придётся писать с серверной и клиентской стороны как минимум 3 различных варианта (WebSockets, FlashSockets, Short/Long Polling, endless iframe)).

Так что перепишу всё текущенаписанное на какой-либо другой язык. Пока есть выбор между C++ и Java. Но я пока склоняюсь к C++.

#26
17:12, 18 янв. 2011

Траф
> Летает даже при дальности обзора в 50 клеток.
если такой запас по дальности просчета, что мешает разбить поле на более мелкие куски для повышения точности?
например каждую клетку на 4 поделить и если хотя бы 2 из этих частей в получатся тени то клетку целиком уводить в тень

#27
19:23, 18 янв. 2011

Bigfoot
>Ну вот клетка - 4 стены. 2 вертикальных и 2 горизонтальных.
Всёравно не понял.
>Не хватит же. Если на пути луча будет стена, то клетки от игрока до стены тогда невидимыми останутся.
Как так? Пускаем луч, каждую клетку проверяем, что на ней. Стена - break. Всё, луча нет, а всё, что до него - видимо. На этом основан весь принцип же. Ааа, стоп, я понял. Ты хочешь пустить лучи от точек к персу, надо наоборот.
-AveNgeR-
А это мысль, можно попробовать.

#28
21:19, 18 янв. 2011

Rulexec
Отличная задумка, успехов.

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

#29
21:48, 18 янв. 2011

я сам хотел использовать зоны видимости подобным образом: NPC, которые не хотят быть замеченными бежали бы до ближайшего темного тайла.
по артефактам:
1. тебе надо сделать так, чтобы луч, наткнувшийся на стену, не тут же гасился, а продолжал освещать все следующие тайлы, если это стены, и гас, не освещая, когда выходил на свободную площадку.
2. так же ты можешь сделать карту света не в виде булевых да/нет, а в виде коэффициента. при каждом шаге луча приплюсовывать к тайлу равное количество света. тогда, ближе к ГГ будет больше попаданий - дальше затухание, так же будут более мягкие тени от столбов. в том числе не будет глюка как на втором скрине.
3. можешь сделать фильтр - сделать проходку тайлов выводимых на экран и каждое значение усреднить с соседними (усредненные данные записывать сразу в новый массив). но у тебя тайлы большие - может не выглядеть хорошо.

Страницы: 1 2 3 Следующая »
ПроектыФорумСобираю команду

Тема в архиве.

По вашему желанию брачные агентства на лучших условиях.