Двач.hk не отвечает.
Вы видите копию треда, сохраненную 14 сентября в 12:05.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Chubrike VS Dog NULL_POINTER 973651 В конец треда | Веб
##Chubrike VS Dog

"Чубрики против сабаки!"
Жанр: Экшн
Год выпуска: 2024
Платформы: FreeBSD, Windows
Бюджет: 5000$
Описание: эта история о великай сабаке которая защищалась от чурак. Чурки хатели трхнуть сабаку но она спасалась гав гав. Как тока сабака пападает в красный крест умирает один чубрик, сабака впалает в рейдж и начинает мачитьь чураккк. ой то есть чубрикафф канешно. А патом снова убигать ат чубрикаффф)) Глубокий смысл что прочентов.
Игра быстро завоевала сердца игровой публики и стала хитом продаж на steam greenlight.

[Скачать игру под Windows]
dropbox.c om/scl/fi/dpoq1rgy5uuvs3skwwiaa/chubrike_VS_dog.exe?rlkey=9gry5cpoygatst4j7xipzz0w8&st=vj5oejf5&dl=0

[Скачать игру под FreeBSD]
dropbox.c om/scl/fi/j3f0qc8b1ni5rogbo204r/chubrike_VS_dog.bin?rlkey=bq43ygr36ebvkh9o1m0bfroti&st=8drzk8rk&dl=0
3 973657
>>655
Узнаёшь эти адреса?
TCP 142.250.125.94:443
TCP 151.101.22.172:80
TCP 23.216.81.152:80
TCP 20.99.186.246:443
TCP 23.195.231.244:443
NULL_POINTER 4 973658
>>657
И че и чего? Игру проходи давай, кулхакер.
NULL_POINTER 5 973660
>>657
Нет не узнаю если честно. Я думал это мой адрес, (потому что dropbox палит айпишники), но это не мой адрес, от чего ещё более страшно.
6 973663
>>660

>от чего ещё более страшно


Да это просто VirusTotal обнаружил, что твоя игра обращается зачем-то по этим адресам. Возможно, телеметрия Microsoft или что там у них...
NULL_POINTER 7 973668
>>663
Хз. Кстати тот файл что в шапке я неверно откомпилил он dll требует. Вот тот что 610 кб тот статически прилинкован.

Это не вирусы, если ты копаешь (хотя очевидно что любой экзешник нужно проверять).
Я просто хотел сделать "основу" любой игры.
Пораскинув немного мозгами я понял что у игры есть две вещи которое способны изменить её состояние: ввод со стороны пользователя, внутренние события. То есть таким образом игра - это конечный автомат который обрабатывает события.

Сделать трёхмерный рендер у меня получилось. Но куда девать его? Надо же как-то игру делать, чтобы не просто какая-то картинка была, а чтобы за этой картинкой код какой-то происходил. Поэтому я решил на простой модели проверить, че будет. Вот, результат демонстрирует следующее: 1)собака может умереть от чубрика даже если ничего не делает (от внутренних событий игры, а конкретно от ситуации "столкновение" ).
2)собака может выживать благодаря действиям игрока (просто избегая ситуации "столкновение")
3)собака может менять свойства оъектов из-за какого нибудь случая.

Это три таких вещи которых я хотел продемонстрировать. В дальнейшем, вполне возможно событие "столкновение", может банально служить для расчёта колизий и дэмэджбоксов: точка персонажа находится на поверхности (± 10% погрешность), значит он не может провалиться внутрь.

Типо такого.
NULL_POINTER 8 973670
по сути "чубрик" это примитивный ИИ
9 973685
>>668

>хотел сделать "основу" любой игры


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

>Пораскинув немного мозгами я понял что


Молодец, но всё придумано до нас, например:
http://gameprogrammingpatterns.com/contents.html
В частности, см. статью "Game Loop".

Изучив уже изобретённое будешь меньше времени тратить на изобретение колёс и больше времени посвящать дизайну новых видов транспорта.
NULL_POINTER 10 973689
>>685

>Игровой движок с нуля? Нормально для обучения, но для разработки игр соло - только зря замедляет.


Ну, во-первых я думаю что не должно замедлять. Я смотрел движок дума, и там основная "хардрвость" разработки в том что это были 90е и тогда компьютеры совсем ничего не могли, поэтому приходилось оптимизировать вообще все.
Мне кажется уже давно не 90е, и можно себе позволить средний пк времен 2008-го года. И тогда можно игру особо и не оптимизировать: ну находится весь уровень в памяти и находится, чего такого то, от лишних 500 кб ОЗУ ничего не будет
Тем более, что я и не знаю что пока хочу сделать. Движок он ограничивает мышление и прикрепляет тебя к конкретному API. Документация движка обычно заключается в клубе умелые ручки:"здравствуйте ребятки сегодня будем делать шутер". То есть чисто обезъянья работа "ткните это - получите то". Получается что разработчики делают моды на пресеты для игр, в не игры. Ну это не разработка, это песочница какая-то, garrys mod на максмалках.
Если уж и брать движок, то godot, более менее сойдёт, судя по документации (годо хотя бы следует некоторой парадигме из "нодов" и пытается этой паралигме обучить разработчика. Поэтому годо намного более выгоден чем Unity)

>Молодец, но всё придумано до нас, например:


http://gameprogrammingpatterns.com/contents.html
Какая разница что придумано до тебя. Это не повод не думать.
И на счёт gameloop. Можно ли поступить иначе, во-первых цикл может не иметь активного ожидания: например он может системным вызовом select ожидать изменений хотя бы в одном событии и только тогда проводить итерацию цикла. Активное ожидание - добавляет активный процесс в планировщик задач, и твой процессор начинает зря переключаться нв пустую задачу. С другой стороны, в игре задача то не пустая, ведь каждую итерацию может что-то происходить. Можно конечно выделить отдельный процесс под внутренние события игры, но тогда мы вместо одного активного процесса получим два - выигрыша никакого. Собственно говоря об этом я бы и хотел порыскать инфу: как вообще события организовывабтся. Сейчас у меня все просто в одном цикле, потому что игра простая. А если игра будет сложнее, нужно ли будет все распределять?!
Зачем вообще нужны процессы? Я все пытался их как-то применить, но пока не смог найти ни одного полезного применения. Надеюсь может в играх найдётся польза от параллельных процессов. Ведь классическая "последовательность действий", всегда работает быстрее. Я подумал, может только если будет куча всяких трёхмерных штук, то возникнет потребность что-то распаралелить для ускорения отклтка.
NULL_POINTER 10 973689
>>685

>Игровой движок с нуля? Нормально для обучения, но для разработки игр соло - только зря замедляет.


Ну, во-первых я думаю что не должно замедлять. Я смотрел движок дума, и там основная "хардрвость" разработки в том что это были 90е и тогда компьютеры совсем ничего не могли, поэтому приходилось оптимизировать вообще все.
Мне кажется уже давно не 90е, и можно себе позволить средний пк времен 2008-го года. И тогда можно игру особо и не оптимизировать: ну находится весь уровень в памяти и находится, чего такого то, от лишних 500 кб ОЗУ ничего не будет
Тем более, что я и не знаю что пока хочу сделать. Движок он ограничивает мышление и прикрепляет тебя к конкретному API. Документация движка обычно заключается в клубе умелые ручки:"здравствуйте ребятки сегодня будем делать шутер". То есть чисто обезъянья работа "ткните это - получите то". Получается что разработчики делают моды на пресеты для игр, в не игры. Ну это не разработка, это песочница какая-то, garrys mod на максмалках.
Если уж и брать движок, то godot, более менее сойдёт, судя по документации (годо хотя бы следует некоторой парадигме из "нодов" и пытается этой паралигме обучить разработчика. Поэтому годо намного более выгоден чем Unity)

>Молодец, но всё придумано до нас, например:


http://gameprogrammingpatterns.com/contents.html
Какая разница что придумано до тебя. Это не повод не думать.
И на счёт gameloop. Можно ли поступить иначе, во-первых цикл может не иметь активного ожидания: например он может системным вызовом select ожидать изменений хотя бы в одном событии и только тогда проводить итерацию цикла. Активное ожидание - добавляет активный процесс в планировщик задач, и твой процессор начинает зря переключаться нв пустую задачу. С другой стороны, в игре задача то не пустая, ведь каждую итерацию может что-то происходить. Можно конечно выделить отдельный процесс под внутренние события игры, но тогда мы вместо одного активного процесса получим два - выигрыша никакого. Собственно говоря об этом я бы и хотел порыскать инфу: как вообще события организовывабтся. Сейчас у меня все просто в одном цикле, потому что игра простая. А если игра будет сложнее, нужно ли будет все распределять?!
Зачем вообще нужны процессы? Я все пытался их как-то применить, но пока не смог найти ни одного полезного применения. Надеюсь может в играх найдётся польза от параллельных процессов. Ведь классическая "последовательность действий", всегда работает быстрее. Я подумал, может только если будет куча всяких трёхмерных штук, то возникнет потребность что-то распаралелить для ускорения отклтка.
11 973694
>>685
Да. Вот я ещё немного подумал.
Этот твой вечный цикл имеет явный недостаток:
Представь, отрисовка кадра это будет отрисовка всех мешей на уровне, учитывая вычисление Z-буфера.
А если такое вычисление будет занимать пол-секунды? Это много между прочим, и заметно. И все эти пол-секунды ты не можешь двигать мышью.
Очевидный лаг.
А если мышь будет отдельным процессом, которая ставить в очередь свои действия и подаёт их стримом в процесс игры, то тогда можно спокойно вертеть мышью, и будет просадка только по фпс.
Похоже что параллельные процессы имеет смысл применять чтобы длинный цикл заменить на несколько маленьких.
Обновить тред
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 14 сентября в 12:05.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /gd/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски