##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
"Чубрики против сабаки!"
Жанр: Экшн
Год выпуска: 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
[Актуальная ссылка под Windows]
https://www.dropbox.com/scl/fi/dpoq1rgy5uuvs3skwwiaa/chubrike_VS_dog.exe?rlkey=9gry5cpoygatst4j7xipzz0w8&st=9uxmr6mk&dl=0
https://www.dropbox.com/scl/fi/dpoq1rgy5uuvs3skwwiaa/chubrike_VS_dog.exe?rlkey=9gry5cpoygatst4j7xipzz0w8&st=9uxmr6mk&dl=0
>>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
Узнаёшь эти адреса?
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
>>657
И че и чего? Игру проходи давай, кулхакер.
И че и чего? Игру проходи давай, кулхакер.
>>657
Нет не узнаю если честно. Я думал это мой адрес, (потому что dropbox палит айпишники), но это не мой адрес, от чего ещё более страшно.
Нет не узнаю если честно. Я думал это мой адрес, (потому что dropbox палит айпишники), но это не мой адрес, от чего ещё более страшно.
>>660
Да это просто VirusTotal обнаружил, что твоя игра обращается зачем-то по этим адресам. Возможно, телеметрия Microsoft или что там у них...
>от чего ещё более страшно
Да это просто VirusTotal обнаружил, что твоя игра обращается зачем-то по этим адресам. Возможно, телеметрия Microsoft или что там у них...
>>663
Хз. Кстати тот файл что в шапке я неверно откомпилил он dll требует. Вот тот что 610 кб тот статически прилинкован.
Это не вирусы, если ты копаешь (хотя очевидно что любой экзешник нужно проверять).
Я просто хотел сделать "основу" любой игры.
Пораскинув немного мозгами я понял что у игры есть две вещи которое способны изменить её состояние: ввод со стороны пользователя, внутренние события. То есть таким образом игра - это конечный автомат который обрабатывает события.
Сделать трёхмерный рендер у меня получилось. Но куда девать его? Надо же как-то игру делать, чтобы не просто какая-то картинка была, а чтобы за этой картинкой код какой-то происходил. Поэтому я решил на простой модели проверить, че будет. Вот, результат демонстрирует следующее: 1)собака может умереть от чубрика даже если ничего не делает (от внутренних событий игры, а конкретно от ситуации "столкновение" ).
2)собака может выживать благодаря действиям игрока (просто избегая ситуации "столкновение")
3)собака может менять свойства оъектов из-за какого нибудь случая.
Это три таких вещи которых я хотел продемонстрировать. В дальнейшем, вполне возможно событие "столкновение", может банально служить для расчёта колизий и дэмэджбоксов: точка персонажа находится на поверхности (± 10% погрешность), значит он не может провалиться внутрь.
Типо такого.
Хз. Кстати тот файл что в шапке я неверно откомпилил он dll требует. Вот тот что 610 кб тот статически прилинкован.
Это не вирусы, если ты копаешь (хотя очевидно что любой экзешник нужно проверять).
Я просто хотел сделать "основу" любой игры.
Пораскинув немного мозгами я понял что у игры есть две вещи которое способны изменить её состояние: ввод со стороны пользователя, внутренние события. То есть таким образом игра - это конечный автомат который обрабатывает события.
Сделать трёхмерный рендер у меня получилось. Но куда девать его? Надо же как-то игру делать, чтобы не просто какая-то картинка была, а чтобы за этой картинкой код какой-то происходил. Поэтому я решил на простой модели проверить, че будет. Вот, результат демонстрирует следующее: 1)собака может умереть от чубрика даже если ничего не делает (от внутренних событий игры, а конкретно от ситуации "столкновение" ).
2)собака может выживать благодаря действиям игрока (просто избегая ситуации "столкновение")
3)собака может менять свойства оъектов из-за какого нибудь случая.
Это три таких вещи которых я хотел продемонстрировать. В дальнейшем, вполне возможно событие "столкновение", может банально служить для расчёта колизий и дэмэджбоксов: точка персонажа находится на поверхности (± 10% погрешность), значит он не может провалиться внутрь.
Типо такого.
по сути "чубрик" это примитивный ИИ
>>668
Игровой движок с нуля? Нормально для обучения, но для разработки игр соло - только зря замедляет. Тоже люблю изобретать велосипеды, а потом часто понимаю, что лучше бы взял готовый инструмент. Внутри игровых движков много нюансов, о которых изначально ничего не знаешь, но их реализация или багфиксы могут занять месяцы сложного труда. Так что если цель - сделать игру, то лучше брать готовое.
Молодец, но всё придумано до нас, например:
http://gameprogrammingpatterns.com/contents.html
В частности, см. статью "Game Loop".
Изучив уже изобретённое будешь меньше времени тратить на изобретение колёс и больше времени посвящать дизайну новых видов транспорта.
>хотел сделать "основу" любой игры
Игровой движок с нуля? Нормально для обучения, но для разработки игр соло - только зря замедляет. Тоже люблю изобретать велосипеды, а потом часто понимаю, что лучше бы взял готовый инструмент. Внутри игровых движков много нюансов, о которых изначально ничего не знаешь, но их реализация или багфиксы могут занять месяцы сложного труда. Так что если цель - сделать игру, то лучше брать готовое.
>Пораскинув немного мозгами я понял что
Молодец, но всё придумано до нас, например:
http://gameprogrammingpatterns.com/contents.html
В частности, см. статью "Game Loop".
Изучив уже изобретённое будешь меньше времени тратить на изобретение колёс и больше времени посвящать дизайну новых видов транспорта.
>>685
Ну, во-первых я думаю что не должно замедлять. Я смотрел движок дума, и там основная "хардрвость" разработки в том что это были 90е и тогда компьютеры совсем ничего не могли, поэтому приходилось оптимизировать вообще все.
Мне кажется уже давно не 90е, и можно себе позволить средний пк времен 2008-го года. И тогда можно игру особо и не оптимизировать: ну находится весь уровень в памяти и находится, чего такого то, от лишних 500 кб ОЗУ ничего не будет
Тем более, что я и не знаю что пока хочу сделать. Движок он ограничивает мышление и прикрепляет тебя к конкретному API. Документация движка обычно заключается в клубе умелые ручки:"здравствуйте ребятки сегодня будем делать шутер". То есть чисто обезъянья работа "ткните это - получите то". Получается что разработчики делают моды на пресеты для игр, в не игры. Ну это не разработка, это песочница какая-то, garrys mod на максмалках.
Если уж и брать движок, то godot, более менее сойдёт, судя по документации (годо хотя бы следует некоторой парадигме из "нодов" и пытается этой паралигме обучить разработчика. Поэтому годо намного более выгоден чем Unity)
http://gameprogrammingpatterns.com/contents.html
Какая разница что придумано до тебя. Это не повод не думать.
И на счёт gameloop. Можно ли поступить иначе, во-первых цикл может не иметь активного ожидания: например он может системным вызовом select ожидать изменений хотя бы в одном событии и только тогда проводить итерацию цикла. Активное ожидание - добавляет активный процесс в планировщик задач, и твой процессор начинает зря переключаться нв пустую задачу. С другой стороны, в игре задача то не пустая, ведь каждую итерацию может что-то происходить. Можно конечно выделить отдельный процесс под внутренние события игры, но тогда мы вместо одного активного процесса получим два - выигрыша никакого. Собственно говоря об этом я бы и хотел порыскать инфу: как вообще события организовывабтся. Сейчас у меня все просто в одном цикле, потому что игра простая. А если игра будет сложнее, нужно ли будет все распределять?!
Зачем вообще нужны процессы? Я все пытался их как-то применить, но пока не смог найти ни одного полезного применения. Надеюсь может в играх найдётся польза от параллельных процессов. Ведь классическая "последовательность действий", всегда работает быстрее. Я подумал, может только если будет куча всяких трёхмерных штук, то возникнет потребность что-то распаралелить для ускорения отклтка.
>Игровой движок с нуля? Нормально для обучения, но для разработки игр соло - только зря замедляет.
Ну, во-первых я думаю что не должно замедлять. Я смотрел движок дума, и там основная "хардрвость" разработки в том что это были 90е и тогда компьютеры совсем ничего не могли, поэтому приходилось оптимизировать вообще все.
Мне кажется уже давно не 90е, и можно себе позволить средний пк времен 2008-го года. И тогда можно игру особо и не оптимизировать: ну находится весь уровень в памяти и находится, чего такого то, от лишних 500 кб ОЗУ ничего не будет
Тем более, что я и не знаю что пока хочу сделать. Движок он ограничивает мышление и прикрепляет тебя к конкретному API. Документация движка обычно заключается в клубе умелые ручки:"здравствуйте ребятки сегодня будем делать шутер". То есть чисто обезъянья работа "ткните это - получите то". Получается что разработчики делают моды на пресеты для игр, в не игры. Ну это не разработка, это песочница какая-то, garrys mod на максмалках.
Если уж и брать движок, то godot, более менее сойдёт, судя по документации (годо хотя бы следует некоторой парадигме из "нодов" и пытается этой паралигме обучить разработчика. Поэтому годо намного более выгоден чем Unity)
>Молодец, но всё придумано до нас, например:
http://gameprogrammingpatterns.com/contents.html
Какая разница что придумано до тебя. Это не повод не думать.
И на счёт gameloop. Можно ли поступить иначе, во-первых цикл может не иметь активного ожидания: например он может системным вызовом select ожидать изменений хотя бы в одном событии и только тогда проводить итерацию цикла. Активное ожидание - добавляет активный процесс в планировщик задач, и твой процессор начинает зря переключаться нв пустую задачу. С другой стороны, в игре задача то не пустая, ведь каждую итерацию может что-то происходить. Можно конечно выделить отдельный процесс под внутренние события игры, но тогда мы вместо одного активного процесса получим два - выигрыша никакого. Собственно говоря об этом я бы и хотел порыскать инфу: как вообще события организовывабтся. Сейчас у меня все просто в одном цикле, потому что игра простая. А если игра будет сложнее, нужно ли будет все распределять?!
Зачем вообще нужны процессы? Я все пытался их как-то применить, но пока не смог найти ни одного полезного применения. Надеюсь может в играх найдётся польза от параллельных процессов. Ведь классическая "последовательность действий", всегда работает быстрее. Я подумал, может только если будет куча всяких трёхмерных штук, то возникнет потребность что-то распаралелить для ускорения отклтка.
>>685
Ну, во-первых я думаю что не должно замедлять. Я смотрел движок дума, и там основная "хардрвость" разработки в том что это были 90е и тогда компьютеры совсем ничего не могли, поэтому приходилось оптимизировать вообще все.
Мне кажется уже давно не 90е, и можно себе позволить средний пк времен 2008-го года. И тогда можно игру особо и не оптимизировать: ну находится весь уровень в памяти и находится, чего такого то, от лишних 500 кб ОЗУ ничего не будет
Тем более, что я и не знаю что пока хочу сделать. Движок он ограничивает мышление и прикрепляет тебя к конкретному API. Документация движка обычно заключается в клубе умелые ручки:"здравствуйте ребятки сегодня будем делать шутер". То есть чисто обезъянья работа "ткните это - получите то". Получается что разработчики делают моды на пресеты для игр, в не игры. Ну это не разработка, это песочница какая-то, garrys mod на максмалках.
Если уж и брать движок, то godot, более менее сойдёт, судя по документации (годо хотя бы следует некоторой парадигме из "нодов" и пытается этой паралигме обучить разработчика. Поэтому годо намного более выгоден чем Unity)
http://gameprogrammingpatterns.com/contents.html
Какая разница что придумано до тебя. Это не повод не думать.
И на счёт gameloop. Можно ли поступить иначе, во-первых цикл может не иметь активного ожидания: например он может системным вызовом select ожидать изменений хотя бы в одном событии и только тогда проводить итерацию цикла. Активное ожидание - добавляет активный процесс в планировщик задач, и твой процессор начинает зря переключаться нв пустую задачу. С другой стороны, в игре задача то не пустая, ведь каждую итерацию может что-то происходить. Можно конечно выделить отдельный процесс под внутренние события игры, но тогда мы вместо одного активного процесса получим два - выигрыша никакого. Собственно говоря об этом я бы и хотел порыскать инфу: как вообще события организовывабтся. Сейчас у меня все просто в одном цикле, потому что игра простая. А если игра будет сложнее, нужно ли будет все распределять?!
Зачем вообще нужны процессы? Я все пытался их как-то применить, но пока не смог найти ни одного полезного применения. Надеюсь может в играх найдётся польза от параллельных процессов. Ведь классическая "последовательность действий", всегда работает быстрее. Я подумал, может только если будет куча всяких трёхмерных штук, то возникнет потребность что-то распаралелить для ускорения отклтка.
>Игровой движок с нуля? Нормально для обучения, но для разработки игр соло - только зря замедляет.
Ну, во-первых я думаю что не должно замедлять. Я смотрел движок дума, и там основная "хардрвость" разработки в том что это были 90е и тогда компьютеры совсем ничего не могли, поэтому приходилось оптимизировать вообще все.
Мне кажется уже давно не 90е, и можно себе позволить средний пк времен 2008-го года. И тогда можно игру особо и не оптимизировать: ну находится весь уровень в памяти и находится, чего такого то, от лишних 500 кб ОЗУ ничего не будет
Тем более, что я и не знаю что пока хочу сделать. Движок он ограничивает мышление и прикрепляет тебя к конкретному API. Документация движка обычно заключается в клубе умелые ручки:"здравствуйте ребятки сегодня будем делать шутер". То есть чисто обезъянья работа "ткните это - получите то". Получается что разработчики делают моды на пресеты для игр, в не игры. Ну это не разработка, это песочница какая-то, garrys mod на максмалках.
Если уж и брать движок, то godot, более менее сойдёт, судя по документации (годо хотя бы следует некоторой парадигме из "нодов" и пытается этой паралигме обучить разработчика. Поэтому годо намного более выгоден чем Unity)
>Молодец, но всё придумано до нас, например:
http://gameprogrammingpatterns.com/contents.html
Какая разница что придумано до тебя. Это не повод не думать.
И на счёт gameloop. Можно ли поступить иначе, во-первых цикл может не иметь активного ожидания: например он может системным вызовом select ожидать изменений хотя бы в одном событии и только тогда проводить итерацию цикла. Активное ожидание - добавляет активный процесс в планировщик задач, и твой процессор начинает зря переключаться нв пустую задачу. С другой стороны, в игре задача то не пустая, ведь каждую итерацию может что-то происходить. Можно конечно выделить отдельный процесс под внутренние события игры, но тогда мы вместо одного активного процесса получим два - выигрыша никакого. Собственно говоря об этом я бы и хотел порыскать инфу: как вообще события организовывабтся. Сейчас у меня все просто в одном цикле, потому что игра простая. А если игра будет сложнее, нужно ли будет все распределять?!
Зачем вообще нужны процессы? Я все пытался их как-то применить, но пока не смог найти ни одного полезного применения. Надеюсь может в играх найдётся польза от параллельных процессов. Ведь классическая "последовательность действий", всегда работает быстрее. Я подумал, может только если будет куча всяких трёхмерных штук, то возникнет потребность что-то распаралелить для ускорения отклтка.
>>685
Да. Вот я ещё немного подумал.
Этот твой вечный цикл имеет явный недостаток:
Представь, отрисовка кадра это будет отрисовка всех мешей на уровне, учитывая вычисление Z-буфера.
А если такое вычисление будет занимать пол-секунды? Это много между прочим, и заметно. И все эти пол-секунды ты не можешь двигать мышью.
Очевидный лаг.
А если мышь будет отдельным процессом, которая ставить в очередь свои действия и подаёт их стримом в процесс игры, то тогда можно спокойно вертеть мышью, и будет просадка только по фпс.
Похоже что параллельные процессы имеет смысл применять чтобы длинный цикл заменить на несколько маленьких.
Да. Вот я ещё немного подумал.
Этот твой вечный цикл имеет явный недостаток:
Представь, отрисовка кадра это будет отрисовка всех мешей на уровне, учитывая вычисление Z-буфера.
А если такое вычисление будет занимать пол-секунды? Это много между прочим, и заметно. И все эти пол-секунды ты не можешь двигать мышью.
Очевидный лаг.
А если мышь будет отдельным процессом, которая ставить в очередь свои действия и подаёт их стримом в процесс игры, то тогда можно спокойно вертеть мышью, и будет просадка только по фпс.
Похоже что параллельные процессы имеет смысл применять чтобы длинный цикл заменить на несколько маленьких.