Войти
WarZesФорум

Система сцены для движка (комментарии)

Страницы: 1 2 3 4 5 Следующая »
#0
17:57, 25 окт. 2013

Система сцены для движка (комментарии)

Это сообщение сгенерировано автоматически.

#1
17:57, 25 окт. 2013

Весьма кстати ты взялся за это дело, я как раз думаю как бы более или менее по человечески переписать систему сцены, если конечно ее так можно назвать в моем исполнении ).

+ Показать

Мб на что-нибудь полезное твое повествование мну наведет. Пышы исче )

#2
18:25, 25 окт. 2013

Я бы не стал делать игроков, врагов и т.д. У меня будет только GameObject. У него есть некие свойства (колайдер, меш, скрипты, в любых комбинациях). А его поведение задано с помощью скриптов. Здесь я как раз и беру лучшую сторону из компонентной системы - а именно отсутсвие наследников ГО.

#3
18:51, 25 окт. 2013

>Я бы не стал делать игроков, врагов и т.д. У меня будет только GameObject.
А как тогда у тебя они будут представлены? Коллекции свойств и все чель? В какой-то класс это все-таки должно вылиться, не?
И как ты тогда будешь отличать эти наборы разных свойств, перед тобой гвоздь или червяк, и можно ли ему (этому наборуамебе) обработать коллизии, провернуть внутреннюю логику событий,  раздать люлейсообщений другим объектам, нарисовать 25-й кадр 3-его состояния ?

А я вот наоборот думаю что легче и быстрее сделать основные игровые объекты:
+Времени нужно меньше.
+Логика связей менее запутанная, элементы и система она как бы сразу видна - их имена, а значит назначение. Можно меньше нагружать мозг как бы их связать и обработать те или иные события, взаимодействия. И добавлять новые свойства никто не запретит, но у же в рамках имени объекта.
+Не люблю я компонентную систему. Объект Бог (если не ошибаюсь в терминах) - для простых и быстрых реализаций самое то.

Конечно я погляжу что у тебя получится, мб я сильно ошибаюсь. Меньше - слов, больше - кода! (он понятнее)

#4
20:44, 25 окт. 2013

Rayman2
> А как тогда у тебя они будут представлены? Коллекции свойств и все чель? В
> какой-то класс это все-таки должно вылиться, не?
Как в юнити. Именно скрипты и будут определять, что вот этот ГО - игрок, а вон тот ГО - вообще игровое меню. для движка все один будут только ГО. Почему так? Потому что деление на игроков, врагов, и т.д. уменьшают расширяемость движка

Rayman2
> И как ты тогда будешь отличать эти наборы разных свойств, перед тобой гвоздь
> или червяк
А зачем? Если пользователю надо, он напишет скрипт, в котором будет переменная
string type;
и сам проверит что это гвоздь или червяк. движку на такое плевать

Rayman2
> и можно ли ему (этому наборуамебе) обработать коллизии,
Если у ГО есть колайдер, то значит надо боработать коллизии и физику, если нет (то есть нулевой указатель), то не надо

>>провернуть внутреннюю логику событий
Скрипты, вся логика именно в них

>>раздать люлейсообщений другим объектам
Для этого не надо знать что это за объекты

Rayman2
> А я вот наоборот думаю что легче и быстрее сделать основные игровые объекты:
Только для одной игры, когда решишь делать другую игру с другой концепцией, то  все эти объекты будут мешать. именно поэтому например из движка doom 3 не сделать стратегию, потому что там тоже захардкоренно все только для шутера, и замучаешься выпиливать

Rayman2
>>Конечно я погляжу что у тебя получится, мб я сильно ошибаюсь. Меньше - слов, больше - кода! (он понятнее)
Вообще все таки советую посмотреть как сделанно в юнити... не на компонентную систему, а именно на то, как скрипты определяют характер и поведение игрового объекта. То есть для движка это все GameObject, а вот для скриптера, это может быть и главное меню, и игрок, и небо, и даже просто набор глобальных переменных игры, все это описывается скриптом и движок никогда об этом не узнает

#5
19:47, 26 окт. 2013

>Система сцены для движка
И всего один абзатц, и то только вода про саму сцену:
>Теперь про сцену
а остальное про некие геймобжекты (и так и не понятно чем всё закончилось)

Что-то здесь не так... 8-)

#6
5:21, 27 окт. 2013

slava_mib
> Что-то здесь не так... 8-)
Я только начал:) будет и продолжение. Пока это такой концептик, к чему я буду идти

#7
10:19, 27 окт. 2013

war_zes
Ты хочешь как юнити только  скрипты для пользователей дать, или на С++ писать дашь возможность?
Для скриптов что хочешь взять? Lua?

#8
11:44, 27 окт. 2013

TirexiK
> Ты хочешь как юнити только  скрипты для пользователей дать, или на С++ писать
> дашь возможность?
Дам. Под скриптами подразумевается в том числе и возможность наследовать компонент Script и менять ему методы - если присмотреться к юнити, то можно увидеть что там есть важные методы Update(), Start() и т.д. и весь код так или иначе выполняется в них, а значит если написать так

class Script
{
    virtual void Start() = 0;
    virtual void Update() = 0;
};

class MyScript
{
    void Start()
    {
    }
    void Update()
    {
    }
};
Принцип работы будет тем же что в юнити.

TirexiK
> Для скриптов что хочешь взять? Lua?
С# :) только разберусь как это делается - но все равно до этого еще далеко. Есть идеи как прикрутить С++ скрипты (точнее как сделать так чтобы из скриптов собирался код, который потом компилировался любым С++ компилятором), но нет идей - как избавится от долгой компиляции

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

#9
14:00, 27 окт. 2013

Похвастаюсь травой которую курю:)

+ Показать

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

#10
14:41, 27 окт. 2013

> Для скриптов что хочешь взять? Lua?
>С# :)
а можно в качестве скриптов питона заюзать ? есть что-то подобное для с++ ?

#11
20:00, 27 окт. 2013

> Похвастаюсь травой которую курю:)
war_zes, совсем уныло 8-)
Надо разнообразить размер/цвет(оттенок)/отзеркаливание

>да еще и в дебагсборке
В данном случае не должно иметь значения.

#12
22:16, 27 окт. 2013

war_zes
Биллбордная трава - плохая идея. Лучше делать процедурную траву геометрией в геометрическом шейдере:
Изображение

#13
17:39, 19 ноя. 2013

Потихоньку доразвиваю идею и позже выложу в виде статьи с исходниками (даже наверное в виде игры будет:) ).

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

Вот немного из текущего (только начатого) кода

class GameObject : public Node<GameObject>
{
public:
  void Update();

  Transform transform;
  MeshRenderer *meshRenderer;
  std::vector<Script *> scripts;
};
Один важный момент, НИКТО не наследует GameObject. Это полноценный класс. То есть обычно в случае Entity-системы, мы либо наследуем, либо агрегируем некий Entity. А в моей системе такого не будет. Все что на сцене - GameObject.

Как же я собираюсь делать всяких юнитов, игрока, камеру и т.д.? За счет скриптов (Script) и уникальных компонент (в данном случае только MeshRenderer). Вот класс Script:

class Script
{
public:
  virtual ~Script(){}

  virtual void Start() = 0;

  virtual void Update() = 0;

  virtual void Finalize() = 0;

  GameObject *gameObject;
  Transform *transform;
  MeshRenderer *meshRenderer;
};

Вот его мы наследуем, и именно через него и определяем, что это будет - юнит, игрок, или стен.

То есть идея как в юнити - создаем GameObject, пишем Script с нужным поведением. Заполняем созданный GameObject этими скритами - вот и получили что нужно. Примерно так

class PlayerScript : public Script
{
public:
  void Update()
  {
    // что-то делаем для игрока
  }
};

...
GameObject *go = new GameObject;

Script *player = new PlayerScript;

go->AddScript(player);
И в данном примере go - это игрок.

При этом, можно смешивать разные скрипты и получать разные интересные комбинации, что невозможно при обычной энтитисистеме. например смешать скрипт камеры и скрипт игрока... Или повесить сразу два скрипта - игрока и врага, скрипт игрока выключить. А потом при применении какой-нибудь способности (типа переселения в новое тело) переключать эти скрипты (выключить скрипт врага, и включить скрипт игрока).

#14
18:11, 19 ноя. 2013

Вот я даже пример покажу. Пусть на сцене будет дерево и игрок. Дерево... это просто дерево, оно ничего не делает, но через него нельзя проходить. Игрок должен управляться, и у него есть своя логика. При этом пусть это будет игра от первого лица, а значит игрока не нужно представлять моделью

В моей системе это будет создаваться так

GameObject TreeGO;
GameObject PlayerGO;

TreeGO.AddMesh("tree.mesh");
TreeGO.AddCollider("tree_collider.mesh");
TreeGO.Pos(100,0,100);


PlayerGO.AddCollider(COL_BOX);
PlayerGO.AddScript(FPSCamera);
PlayerGO.AddScript(PlayerScript);
TreeGO.Pos(80,0,100);
То есть в создании дерева мы только добавили меш и колайдер. В создании игрока только колайдер, без меша, и два скрипта, один отвечающий за управление камерой, второй, отвечающий за остальные действия игрока. Но для движка это оба GameObject.

А теперь сама красота. Допустим мы решаем что дерево должно расти. пишем скрипт роста. И добавляем строку:

TreeGO.AddScript(GrowScript);
И теперь дерево растет. Чуть позже мы решаем добавить зелье роста... И вуаля, тот же скрипт вешаем на игрока
PlayerGO.AddScript(GrowScript);

В случае энтити-системы пришлось бы дублировать код или извращаться с наследованием.

Страницы: 1 2 3 4 5 Следующая »
WarZesФорум

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