>>18332

Во-первых

команда move_towards_point устанавливает direction и speed того объекта, который исполнил эту команду.

Это равносильно тому, что ты бы написал

direction=point_direction(x,y,mousex,mousey)
speed = 50

После того, как ты задал эти команды с каждым шагом твои координаты будут меняться следующим образом

x += lengthdir_x(50,direction)
y += lengthdir_y(50,direction)

Поэтому бессмысленно выглядит твой цикл while - это будет бесконечный цикл, так как он у тебя запущен внутри одного step event

Что тебе нужно сделать?

if mouse_check_button_pressed(mb_left){

//заводим временные переменные. Почему? Потому что их легче передать объекту внутрь "with"
var _mx = mouse_x
var _my = mouse_y

if instance_exists(obj_npc){ //Это предохранитель. Его стоит вставлять всегда, когда хочешь что-то сделать с объектом, которого может и не быть в комнате
with obj_npc{ // Это означает "применить ко всем obj_npc в комнтае"
move_towards_point(_mx,_my,50) //эта строчка сообщает, что
if point_distance(x,y,_mx,_my) < 50{ //А это условие остановки движения
speed = 0
x = _mx
y = _my
}}}}

>>18336
Так, разовьём. Телепаты в отпуске, но попробую влезь тебе в голову
Наверное ты хочешь, чтобы твои obj_npc сами останавливались при достижении место, куда ты кликнул мышкой, да?

Тогда делай так:

В step event своего контроллера пиши:

if mouse_check_button_pressed(mb_left){

var _mx = mouse_x
var _my = mouse_y

if instance_exists(obj_npc){
with obj_npc{
mousex = _mx //таким образом мы устанавливаем переменную mousex у всех obj_npc в комнате, а не у контроллера
mousey = _my
move_towards_point(mousex,mousey,50) //эта строчка запустит движение объектов
}}

А потом в step event obj_npc добавь это:

if point_distance(x,y,mousex,mousey) < 50{
speed = 0
x = _mx
y = _my
}
тогда каждый obj_npc будет каждый шаг проверять, не добрался ли он достаточно близко до точки mousex,mousey и не пора ли ему прекратить движение.

>>46436
чтобы в объекте А выполнялся код объектом Б нужно в объекте А написать:
with (объект Б)
{
собственно код
}
если ты хош писать чтоб цвет поменял, то image_blend меняй так, ну или можно в объекте А написать:
objectB.image_blend = huy
если ты хочешь со всеми объектами хуйню крутить, то делаешь виз. Если хотишь делать с одним, то второе(но тогда он будет делать чето с первым созданным экземпляром объекта). Если хочешь чтобы работал с конкретным, то пытаешься его индекс(хуета для адресации) куда то впихать, к примеру во временную переменную, а дальше также как во втором варианте. Чтобы индекс взять нужно работать или через инстанс криейт или колижен.Также есть функции, возвращающие индекс
В итоге оно выглядеть будет как то так:
var B = instance_create(x,y, objectB);
B.image_blend = huy
Если хочешь не со всеми объектами Б делать, а лишь с горсткой, то пихаешь их в дс-лист, и через фор прогоняешься по ним. Пример:
var _list = ds_list_create();
collision_circle_list(x,y, 16, _list)//не помню всех аргументтов, но там есть штука куда лист пихать
for (var i = 0; i < ds_list_size(_list); i++)
{
_list[| i].image_blend = huy;
}
ds_list_destroy(_list)//после того как лист отработался, его надо удалять. иначе память жрать не ту бушь и комп при малой оперативке может хуету в игре выдавать
если же хочешь чтобы он собирал лист не по функциям, а смотрел по переменной какой то то можно сделать так:
var _list = ds_list_create()//перед работой с листом его над создать
with (objectB)
{
if peremennaya = "хуета которая нужна" then ds_list_add(_list, self);
}
а дальше также как и при работе с листом выше
А почему внутри кода тут я к листу обращался без адрессации(тоесть в коде другого объекта тыкал переменную другого объекта)? А потому что если у тебя в коде при событии введена временная переменная, то ее в виз можно использовать без адресовки. Если же ето не временная, то там пишешь не просто ds_list_add(_list) а ds_list_add(other._list)
other - хуета которая в визе хранит индекс объекта, который етот виз написал. Также его можно использовать в событии типа столкновений(колижен или collision), они отсылают к объекту с которым столкнулся
Советую почитать побольше по дс-листам в справке + справку гамака(даже с переводчиком)
Если же ты хочешь, чтобы код который написан в событии объекта Б исполнялся по желанию объекта А, то можешь:
- поковырять справку, тк сто проц функции для этого есть
- писать код события объекта Б в скрипт, и писать внутри объекта А:
with (objectB)
{
название_скрипта(аргументы скрипта, если ты их пихал канеш)
}

>>46442
Тебе чел расписал в общих чертах, как обращаться к другим объектам. Причём весьма сумбурно.

У тебя вообще был несколько другой вопрос:

>скрипты в гамаке - это как каммон эвенты, которые ты можешь вызывать в других эвентах для активации какого-то процесса вместо того, чтобы расписывать всё это охуллион раз?

Не знаю, что такое камон ивенты в рпг мейкере, но подозреваю, что они похожи на скрипты.

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

При этом можно поступить очень просто, и написать у каждого врага в ивенте obj_player.hp -= 1
Но это подходит только для очень простых игр. Если у тебя что-то по-сложнее, то ты создаёшь скрипт
sc_deal_dmg_to_player() и заменяешь строчку obj_player.hp -= 1 на него. После чего начинаешь игру развивать.

Попробую пояснить, как выглядит процесс.

Определяешь набор параметров, которые необходимы для того, чтобы наносить повреждения игроку.
Самое простое - величина урона. damage
Например ты хочешь, чтобы падающий сверху камень убивал игрока сразу, а укус собаки наносил 1 единицу урона.
Значит камню нужно назначить damage = 100 а собаке damage = 1.

Что ж, значит теперь от разных объектов приходит разный урон. Строчка obj_player.hp -= 1 нам теперь не подходит.
Меняем скрипт. Добавляем в него аргумент. Пусть скрипт внутри выглядит так:

///@param0 damage_to_deal
var dmg = argument0
obj_player.hp -= dmg

и вызывается он теперь так:
sc_deal_dmg_to_player(damage)

Так, уже можно наносить разный урон. Но нафига нам всё же скрипт, не очень понятно. Продолжим усложнять.
Добавим третьего врага - лягающуюся лошадь. Она наносит игроку 2 единицы урона и отбрасывает его назад. Хм..

Значит для нанесения урона теперь мало только знать damage. Нужно ещё в некоторых случаях отбрасывать игрока. Добавляем значит каждому врагу параметр knockback_power
Камню knockback_power=0
Собаке knockback_power=0
Лошади knockback_power=10

Меняем скрипт

///@param0 damage_to_deal
///@param1 knockback
var _dmg = argument0
var _kb = argument1
obj_player.hp -= _dmg

if _kb>0
{
var _kb_dir = point_direction(x,y,obj_player.x,obj_player.y) //вычисляем направление оброса

with obj_player{move_contact_solid(_kb_dir ,_kb )} //двигаем игрока в направлении отброса на силу отброса
}

А сам скрипт вызываем так:
sc_deal_dmg_to_player(damage,knockback)

Прикольно. Но всё равно, пришлось поменять create event каждого врага, добавив туда строчку knockback_power=0
И step_event каждого врага, изменив вызов скрипта с sc_deal_dmg_to_player(damage) на sc_deal_dmg_to_player(damage,knockback)

Так прекратим и это.

Предположим нам для описания всех типов урона понадобится 10 переменных. Для всяких станов, кнокбэков и т.д.
Где-нибудь в основном игровом объекте делаем enum - перечисление переменных
enum d_params
{
damage,
knockback_power,
stun_duration,
slow_debuf_duration,
disarm_debuf_duration,

number
}
Здесь мы перечисляем все необходимые для нанесения урона переменные. В конце пишем number чтобы можно было получить длину этого списка.

Модифицируем create_event каждого врага следующим образом

damage_parameters = array_create(d_params.number,0) // создаём массив, в котором столько же переменных, сколько в нашем списке и все они имеют значение ноль.
Потом, если нужно, выставляем отдельным переменным значение.

Для лошади, например пишем
damage_parameters = array_create(d_params.number,0)
damage_parameters [d_params.damage] = 2
damage_parameters [d_params.knockback_power] = 10

Получается лошадь может наносить 2 единицы урона и отбрасывать от себя на 10 пикселей.

Меняем соответственно скрипт sc_deal_dmg_to_player()
Пусть он теперь вызывается у нас так: sc_deal_dmg_to_player(damage_parameters)

А внутри у него сидит:
var _inc_array = argument0

var_dmg = _inc_array[d_params.damage]
var _kb = _inc_array[d_params.knockback_power]
var _std = _inc_array[d_params.stun_duration]

//обработка урона
if !obj_player.invulnerable obj_player.hp -= _dmg

if _kb>0
{
var _kb_dir = point_direction(x,y,obj_player.x,obj_player.y) //вычисляем направление оброса
with obj_player{move_contact_solid(_kb_dir ,_kb )} //двигаем игрока в направлении отброса на силу отброса
}

if _std>0
{
obj_player.stunned = true;
}

Отныне ты можешь в любой момент модифицировать то, как наносится урон игроку (заметил, я ввёл игроку параметр "неуязвимость") и это изменение коснётся сразу всех врагов. наносящих урон.
А как только ты захочешь ввести новый параметр урона, ты просто допишешь его в список enum, назначишь нужным врагам его величины и допишешь в скрипт его обработку.

Такие дела.

А в последствии ты сможешь, например, задавать все параметры врагов через ini файл. И каждый враг будет считывать свои параметры из этого файла. Когда врагов под сотню - это удобней.

>>46480

>По идее ты в create игрока назначаешь переменную invulnerable и приравниваешь её к нулю, так? Но в таком случае она не будет учитываться командой выше, если её значение не будет изменено в каком-либо сценарии на что-то выше нуля? Вопрос пиздец тупой, знаю, но что поделать.

Это я в качестве примера написал.
Да, в create event игрока добавляешь
invulnerable = false;
invulnerable_timer = 0;
invulnerable_time = 40;
saved_hp = hp

Потом в step_event что-нибудь типа:

if saved_hp > hp
{
invulnerable = true;
saved_hp = hp
}

if invulnerable
{
invulnerable_timer ++
if invulnerable_timer > invulnerable_time
{
invulnerable_timer =0;
invulnerable = false
}
}

Таким образом игрок становится неуязвимым на 40 фреймов после получения урона.

>Хотел бы создать главное меню, управляемое мышью

Ну постучи в телегу @doroboarashi

>>46431
var l7EB26BE3_0 = instance_place(x + hsp, y + 0, o_solid);
if ((l7EB26BE3_0 > 0))
{
collide = false;

while ((collide == false)) {
var l02F7CC12_0 = instance_place(x + sign(hsp), y + 0, o_solid);
if (!(l02F7CC12_0 > 0))
{
x = sign(hsp);
}

else
{
collide = true;

hsp = 0;
}
}
}

x += hsp;

var l64877E14_0 = instance_place(x + 0, y + vsp, o_solid);
if ((l64877E14_0 > 0))
{
collide = false;

while ((collide == false)) {
var l4AD85A33_0 = instance_place(x + 0, y + sign(vsp), o_solid);
if (!(l4AD85A33_0 > 0))
{
y = sign(vsp);
}

else
{
collide = true;

vsp = 0;
}
}
}

y += vsp;

>>46587
У тебя внатуре while циклы. Да ещё и коллизии с объектами.

Полагаю ты по расставлял коллизий в 1 пиксель шириной и в процессе поиска коллизий перепрыгиваешь через объекты.

Либо у тебя hsp или vsp имеет значение 0, но каким-то образом ты получаешь коллизию в instance_place и запускаешь цикл.

Ищи, где ты проебался.
Если слишком сложна искать проёб убери цикл while.

Например

while ((collide == false))
{
var b = instance_place(x + sign(hsp), y + 0, o_solid);
if (!(b > 0))
{
x = sign(hsp);
}
else
{
collide = true;
hsp = 0;
}
}

Поменяй на

repeat(ceil(hsp))
{
var b = instance_place(x + sign(hsp), y + 0, o_solid);
if (!(b > 0))
{
x = sign(hsp);
}
else
{
break;
hsp = 0;
}
}

>>55077

enum weapon_postions
{
low,
mid,
high,
}

Заводишь переменные weapon_y_offset, weapon_x_offset, weapon_position

в step_event оружия делаешь

x = owner.x + weapon_x_offset*owner.dirx
Где owner - id хозяина оружия.
Соответственно оружие у тебя будет привязано к Х координате хозяина и тому, куда он смотрит.

затем
switch weapon_position
{
case weapon_postions.low: weapon_y_offset= -10; break;
case weapon_postions.mid: weapon_y_offset= -20; break;
case weapon_postions.high: weapon_y_offset= -30; break;
}
y = owner.y + weapon_y_offset

высота оружия будет привязана к высоте хозяина + отступу от неё, который будет зависеть от переменной weapon_position

Соответственно хозяин сможет сменить высоту оружия приказав
my_weapon.weapon_position = weapon_postions.low

Привет. Я очень новенький во всем этом деле, но у меня уже возникла проблема, которую я не смог решить за последние 2 дня. Я гуглил, честно, прочитал про keyboard_check_pressed и пытался паузы после анимации делать, но в итоге у меня перестали анимации проигрывать вообще.
Суть проблемы такова:
Я использую физику в своем платформере. Я везде нажал галочки и с этим никаких проблем нет. Персонаж двигается туда и сюда:

/// идем вправо
if (keyboard_check(ord("D")))
{
phy_position_x += go;
}
/// теперь в другую сторону, налево
if (keyboard_check(ord("A")))
{
phy_position_x -= go;
}

После этого я сделал прыжок, все по туториалам (делал три часа, тупенький)
/// прыгаем ( х и у это координаты игрока, 0 - вектор относительно х, jump - вектор относительно у)
if (keyboard_check(vk_space)) && (jumping = false)
/// если нажат пробел и ИГРОК НЕ В СОСТОЯНИИ ПРЫЖКА, ТО
{
physics_apply_impulse (x, y, 0, imp_jump); ///придать импульс
jumping = true; /// состоянии в прыжка активно, что не дает jumping перейти в состояние false
}
/// не прыгаем кучу раз в воздухе, проверка на соприкосновение
if (place_meeting(x, y + 1 , ob_wall)) // если стоишь на объекте, то состояние прыжка НЕАКТИВНО, что
/// позволит нам его совершить согласно условию выше!
{
jumping = false;
}

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

В чем проблема?
А в том, что если зажать ПРОБЕЛ, то персонаж начинает ВСЕ ВРЕМЯ прыгать, без остановки, что убивает анимацию. Вопрос такой, анон, как правильно реализовать функцию прыжка при включенной физике? Может, поделитесь опытом?
Спасибо.

>>64327
возможно про дс листы писал я, мб нет
а твой код я в рот ебал читать, тк ты про таб не слышал
как использовать таб?
вот так
if (Uasshole) then
{
gofuckuself = true;
if (IamGAY = true) then
{
PrepareANUS = 1
}
}
или у тя табы съелись пастебинахуем
но если ты не понял, то все что внутри фигурных скобочек табается блять, даже еще одни фигурные скобочки и то что внутри тех захуяренных скобочек тоже
я кста не понимаю зачем ты хуяришь карту не тайлами. сделал бы мир по сетке, дабы не ебать мозг с врагами. просто нахуярил условный ds_grid(что является массивом, ес вдруг ты не шаришь), и хуяришь в нем внутри врагов клеточки - 1 свободна, и можно пиздохать и 0 знач там негры выебут
и изич у тя с врагами будет, более легче все по самому движению, а так чтобы оно выглядело мол они не тупо с клетки на клетку едут ето ж изич сделать
делаешь знач объект, куда пихаешь клеточки карты. можешь нахуярить алгоритм чтобы он по готовой комнате смотрел че у тя за шиза происходит, или нахуярить генерацию, или же говнокудахтор карт(в зависимости от твоих амбиций), куда ппихается собсна массив через ds_grid с клеточками
затем создаешь объект игрока. я не понимаю, как у тя должно быть, но путем моей скромной дедукции, у тебя игрок чето делает(двигается, пиздится, 1 действиее какое то), а затем мобы прогружаются и чето делают(1 тоже действие).
Для того чтобы это нахуярить просто пихаешь объект еще один, куда пишешь фазу хода. изначально пускай буит 0, затем ес игрок чето делает, то перед тем, как объект игрока(его герой так сказать) смотрит, че по фазе, и если фаза для игрока(тобишь 0), то чето делает, а затем ставит в переменную фазы 1. изза этого, игрок, пока карта не походит, нихуя сделать не смогет.
В это время нужно придумать как у тя окружение будет работать. по идее у тя онли мобы, так что делаешь объект-родитель для того чтобы как то обращаться ко всем мобам, а объекты собсна других мобов делаешь детьми этого объекта-родителя(буду называть в будущем монстромать)
берешь собсна свою монстромать, пихаешь ей переменную, которая бы показывала уже фазу монстра отдельно.
идешь в скрипт где обрабатывается фаза(я бы делал в объекте где массив с клетками у тя). собсна, в этом объекте пихаешь чето аля:
if phase = 1 then
{
var _check = 0;
with (monstromater)
{
if loc_phase = 0 then loc_phase = 1;
}
phase = 2;
}
if phase = 2 then
{
var _check = 0;
with (monstromater)
{
if loc_phase = 1 then _check = 1;
}
if _check = 0 then phase = 0;
}
таким образом, этот скрипт разделяет действие мобов на две фазы: в которых они принимают решщение, и, в котором они чето рисуют. При этом игроку не дастся контроль, тк фаза не будет 0 пока не сделает фазу каждый моб.
внутри уже каждого детеныша монстромамки пишешь чето когда локфаз = 1 тогда чето делать
это я все напихал без дс листов.
а всякую хуйню про скорость уже чиль в фазе где они рисуют мол чето делают
ес чето вопросы есть, то могу за скромные 500 рубликов в дискорде пояснить все более понятно

>>64372
Задай всем врагам переменную state

Сделай стейт машину. Когда кончается ход - переводишь всех врагов в состояние

Пусть контроллер хода делает что-то такое:
with obj_enemy
{
state = enemy_states.make_decision
}

А потом у врага в step event будет как-то так

switch state
{
case enemy_states.make_decision:
_{
принимаю решение что делать
if принял решение идти на клетку
__{
__ объявляю что клетка занята
__ записываю на какую клетку надо идти
__ state = enemy_states.move_to_cell // перехожу в состояние движения
__ break;
__}
_} break;

case enemy_states.move_to_cell:
_{
_ двигаюсь к нужной клетке
_ if достиг нужной клетки
__{
__ state = enemy_states.turn_fininshed
___break;
__}
_} break;
}

Вот и всё. А потом в контроллере хода проверяешь, что если у всех врагов state == enemy_states.turn_fininshed то считаешь, что все враги завершили свои действия и можно начинать новый ход.

>>65482
я не тот чел который изначально верещал хуйню на гамак, однако
у меня проект компилится 3 минуты, что значит что в нем:
а) много картиночег
б) много кода
тк я не долбоеб и делаю игру, а не фан проект, то у меня ЕСТЬ картиночки, однако и кода тоже дохуялиардномегаквадраллионное ебливое число
И вот тут тема такая, что как раз таки, изза отсутствия ООП составляющей в гамаке(хотя бы классов-методов etc я знаю что существует механика создания своих скриптов, и работы с ними как с недометодами, но ооп это далеко не только методы-классы) движок гамака достаточно требователен и щепетилен. Я не говорю, о том что нужны овер-крутые знания, я говорю о том, что есть к примеру задача: сделать редактор карт, и собсна, карты для него(сохраняемые-загружаемые). Тут встает ряд вопросов, один из главных это как сохранять это говно. Если мы не делаем говно из палок и костылей, то, очевидно, будем юзать буфферы. И вот тут настал для меня в некоторые времена ад, тк в документации гамака нету множества оговорок(к примеру, минимальный размер буфера, чтоб его можно было сжимать и при развертке он не пошел по пизде, были еще подъебки но не помню). Я проебал достаточно времени, в поисках инфы во всяких форумах гамака. Не было. Я не отрицаю, что возможно такая инфа где то есть, но это яркий пример где разрабы недосмотрели и в банальной справке не упомянули важную тему.
Итого претензии:
- язык примитивен, и имеет костыли(прив. пример: скрипты вместо методов)
- в справке(да и изза этого в инете вообще) нету дохуя моментов, которые приходится проверять путем экспериментов(когда инфа должна по логике лежать в справке)
- как бы так не звучало, но гамак реально бывает, что идет по пизде САМ. Я на мелких проектах этого не замечал, но на крупных оч часто. Самый изично добытый способ поймать - берешь кучу спрайтов, и рисуешь через сурфейсы чанками мир платформера(как в террарии). при этом в редакторе спрайтов пихаешь в какой нить спрайт слой, где 1 кадр будет с прозрачным кубиком любого цвета, а на остальных нихуя. В итоге у тебя или этот спрайт будет с прозрачностью, или же половина(у меня такое было, и я дохуя ебнулся когда думал где альфа проебана, в итоге удалил слой и все)
- расширения. Я слышал что гдето есть годные что то там, но мне хотелось бы, чтобы была доступность пилить моды как в майнкрафт, но в гамак. Я не видел нормального чего то подобного, чтоб прям норм функции добавлялись. Только лишь говноскрипты, за которые кто то ким то хуем покупает. Вот если бы было чудо, которое прочитав txt-шку, вгоняет ее в новый скрипт, то я бы сосал до конца жизни этому человеку. Однако, придется ковыряться самому если вдруг хочешь подобное создать... Ковыряться и изьебываться как портовая шлюха
- также есть претензия на счет лицензирования программы. Вот к примеру я молодой инди разраб. Я не имею денег на лицуху, вынужден сидеть на триалке. При этом, толи разрабы нарочно оставили это так, толи они конченные пиздец, но ты спокойно можешь просто зарегать новый акк и продлить триалку.
Таким образом, есть возможность бесконечного использования с некоторым гемороем, однако, в продвижении очень важно выкладывать свой продукт для жертвования(демки всякие, конкурсы, можно дохуя чего придумать), но с изи доступной триалки они нахуй заблочили компиляцию экзешника. В связи с этим придется изьебнуться и найти пиратку работающую(видел гдето были ссылки, но сам чето пробовал и не пашет норм), или изъебнуться и покорить кикстартер лишь с трейлером, что изза наплыва слитого говна недостижимый подвиг, а можно попросить добрых работяг одолжить лицухуесли вдруг у кого то хватит жалости к инди разрабу, то буду оч благодарен до конца дней своих, а если удастся с игрой еще и денюжку заплачу телеграмчег @XiDoS
если принять во внимание эти сильные минусы, то даже в кривых ручках движок все таки достаточно мощный у гмса, и, соответственно, в мощных ручках даж 3д покориться. Но оч костыльное, поэтому если и рассматривать гмс как потенциальный движок, то ток начальный, или же если пилишь всякое зашкварное непотребство аля платформеры
А так лучше юнити. Оч хочу сам на юнити некст проект пилить. Пиздец хочу. А если ща пытаться перейти, то еще пол года времени в пизду улетит (((( сам про юнити минусов не знаю, но там c#, который кажется мне сладенькой девонькой с привлекательными формами

>>65489

>Блин, у тебя серьёзные проекты или нет денег на лицуху? Покажи проект-то.

планирую через месяца 3-4 в ерли акцец идти но перед этим за месяц попрошайничать как вне себя, название будет fmi(сокращение)
ртс-очка
ядро игры готово(код), однако с графикой возникли траблы. Сижу пилю графику.
Пробовал найти толковых ребят, которым бы мог довериться в вопросе графики, однако без бабок ток куколды какие то лезут. Или не куколды, но которые слетают через неделю, тк нашли место с бабками или еще четовсе равно уебаны крч с другой стороны, наверно глупо верить в то, что нормальные люди готовы тратить свое время на сомнительный проект. В итоге решил пробовать сам - в начале пиксельартом, и было бы в разы проще, но говняво(я рисую хуево+есть пласт аудитории, которой не зайдут пиксели), потом пробовал в растр, что было лучше, но все равно больше похоже на поделки пятиклассника, и, в итоге решил делать по заветам олдовых ртс - пререндер(берешь рисуешь концепт-референс, пихаешь в моделкопрогу и там хуяришь модельку, после чего делаешь анимации и это все рендеришь в 2д спрайты). этот вариант не подойдет людям, которым лишь бы слить игру на бабки, тк оно того не стоит. да и сам думаю если изза графики игра по пизде пойдет то просто пойду на заводно надеюсь, что игровые механики вытянут это :D хочу умереть
Пизда крч
Задумка игры: 2д ртс с видом сбоку. Фишка и затея подобного решения в том, чтобы был режим контроля отдельного юнита через WASD, и соответствующие приколы аля окружение(аля укрытия всякие, и куча всего, ес буду все палить то стремно буит). Совет дня: если вы работаете один, или в команде менее 40 геймдизайнеров, то можете даже не пробовать нарулить баланс в ртску. даже ебаные близы до сих пор чето мутят со старкрафтом, а ты тут решил чето пробовать. шанс успеха = 0.5 процентов
Я сам то делал код игры где то половину года(местами учился, думал как делать, изза чего три раза с нуля переписывал все), затем подумал о том, в каком русле это все развивать, что затянуло еще на месяца три. после ебланил месяц. потом(в январе) начал думать за геймдезихан(юнитов-расы), и что то нарулил месяца два назад.
параллельно учился лепить графику или искал ребят чтоб те лепили мне ее
опять таки, если есть ребята, готовые поддержать как угодно, то прошу в телеграм @XiDoS