То-ли движок ради рогалика... то-ли рогалик ради движка...

Закрытые или заброшенные проекты, не состоявшие в Клубе, но имевшие ветку на форуме.

Модератор: Jolly Roger

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Jesus05 » 03 май 2010, 07:20

map.GIF
Стрелочками наследование :) жирными линиями включение :)
Это первый способ.
GameObject будет иметь минимум свойств
Метод ответа если на него пытаются наступить виртуальный.
Координаты на карте не виртуальные :)
Отмечен на карте.
Видимый.
методы думаю не виртуальные.
Привязать к карте.
Установить координаты на каком-то месте карты.
Удалить с какого-то места карты.
ну и указатель на следующий игровой обьект. (в случае если их несколько на одном месте карты).

Ну еще я до сих пор не решил где хранить "картинку"(цвет\букву\фон) которую надо отрисовывать.

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Jesus05 » 03 май 2010, 07:31

Yozka писал(а):Множественное наследование это ЗЛО.
Вообще наследование это зло, нужно использовать только там где оно действительно неообходимо. 3 - 4 потомка это норма, но когда их штук 10... да ище с виртуальными функциями. Компилятор такие "пирамиды в коде строит", распухает таблица виртуальных функций, вся производительность идет втран тарары.
Мне вот интересно, как поведет себя компилятор, когда есть базовый объект, с виртуальными функциями например draw() далее от этого объекта идут множество других...
а потом это множество других сливается в один класс... компилятор не даст это сделать. ибо он не сможет слинковать виртуальныую функцию draw().
Согласен :) что наследование ЗЛО :) но так хочется разобратся в нем :)

если верить этому http://www.citforum.ru/programming/cpp_ ... _080.shtml то сможет, тока использовать эту Draw() придется указывая какую именно хотим использовать.

Аватара пользователя
Jolly Roger
Сообщения: 2973
Зарегистрирован: 27 ноя 2009, 09:10
Откуда: Minsk, Belarus

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Jolly Roger » 03 май 2010, 11:10

А если попробовать реализовывать отличия флагами? :oops:
Писать диздок спустя несколько лет разработки и множества изменений концепции - исконная русская девелоперская традиция.

Аватара пользователя
Aerton
Сообщения: 503
Зарегистрирован: 11 авг 2007, 02:58
Откуда: Новосибирск
Контактная информация:

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Aerton » 03 май 2010, 11:30

Jesus05 писал(а):1. Создать класс у которого будут указатели на все нужные мне классы
Лучше в данном случае оперирвать не в тех понятиях классов, которые ты привёл в начале, а подсистем, отвечающих каждая за одну задачу. Т.е. каждая игровая сущность является собою набором подсистем.

Код: Выделить всё

class Entity {
MovementSystem *move;
DamageSystem *damage;
UseSystem *use; // не придумалось имя получше - эта система работает когда предмет используют
};
Например, MovementSystem имеет несколько методов, отвечающих за перемещение. И именно от него уже наследуются различные классы перемещения: для обычных монстров это хождение по полу, для плавающих - по воде, и тп., для предметов - заглушка или просто нулевой указатель.

Аналогично делаются подситсема повреждений, использования, атаки и все остальные.

Тогда описание сущности в файле - это перечень использумых в ней подсистем и параметров для них.

Код может выглядит и не слишком по-другому, но разница в подходе. Это уже не Object-Oriented, а Data-Driven.

Одно из главных преимуществ - подсистемы можно заменять на лету. Например, potion of flight при распитии заменяет подсистему перемещения на летучую.

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Jesus05 » 03 май 2010, 11:59

Jolly Roger писал(а):А если попробовать реализовывать отличия флагами? :oops:
я хочу уйти от методов которые будут не нужны данному обьекту. т.е. не реализовывать всем все.
Aerton писал(а):...
Код может выглядит и не слишком по-другому, но разница в подходе. Это уже не Object-Oriented, а Data-Driven.

Одно из главных преимуществ - подсистемы можно заменять на лету. Например, potion of flight при распитии заменяет подсистему перемещения на летучую.
А вот это мне нравится, есть ссылочки что-нить почитать по Data-Driven(новый для меня термин и Вики + Google ничего внятного на русском не подкинули) подходу?

Аватара пользователя
Aerton
Сообщения: 503
Зарегистрирован: 11 авг 2007, 02:58
Откуда: Новосибирск
Контактная информация:

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Aerton » 03 май 2010, 12:30

Jesus05 писал(а):А вот это мне нравится, есть ссылочки что-нить почитать по Data-Driven(новый для меня термин и Вики + Google ничего внятного на русском не подкинули) подходу?
К сожалению, каких-либо обширных работ по этой теме мне не встречалось, в основном какие-то отдельные статьи, как например в первом томе Game Programming Gems. В принципе, Jeff Lait на rgrd практикует подобный подход и иногда описывает его в своих постах.

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

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Jesus05 » 03 май 2010, 12:38

Aerton писал(а):...
Лучше в данном случае оперирвать не в тех понятиях классов, которые ты привёл в начале, а подсистем, отвечающих каждая за одну задачу. Т.е. каждая игровая сущность является собою набором подсистем.

Код: Выделить всё

class Entity {
MovementSystem *move;
DamageSystem *damage;
UseSystem *use; // не придумалось имя получше - эта система работает когда предмет используют
};
Например, MovementSystem имеет несколько методов, отвечающих за перемещение. И именно от него уже наследуются различные классы перемещения: для обычных монстров это хождение по полу, для плавающих - по воде, и тп., для предметов - заглушка или просто нулевой указатель.

Аналогично делаются подситсема повреждений, использования, атаки и все остальные.

Тогда описание сущности в файле - это перечень использумых в ней подсистем и параметров для них.

...
map.GIF
Я правильно нарисовал? общую идею?

т.е. От игрового обьекта наследуется класс Предмет который выглядит как

Код: Выделить всё

class Items : public GameObject
{
  UseSystems* pUseSystem;
  WearSystems* pWearSystem;
};
класс системы использования выглядит примерно так

Код: Выделить всё

class UseSystems
{
  virtual void Use() = 0;
};
ну и классы Восстанавливающие\Изменяющие\Временно действующий выглядят

Код: Выделить всё

class UseSystemRestore : public UseSystems
{
  void Use();
};
class UseSystemChange : public UseSystems
{
  void Use();
};
только с разной реализацией метода Use()

??

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Jesus05 » 03 май 2010, 12:53

Yozka писал(а):не первый не второй вариант не подходит.
В первом варианте, нет масштабируемости, новый класс без переписки кода не добавить.
Второй вариант. наплодить кучу классов, что есть нехорошо.
Я бы сделал следующие.
Написалбы обстрактный базовый класс
Код типа токой, тобишь есть метод add(CObject * aObj) он привязывает к одностороннему внутреннему списку некий объект.
далее, исопльзовать можно вот так

CObject * obj = new CObject;
obj->add(new CObjectArmor);//добавим в список объекта амуницию
obj->add(new CObjectMove);//объект может перемещатся
...

далее отрисовываем вот так:
obj->draw(...);

в базовом методе ну это только идея.
Нужно решить еще ряд вопросов, это при деструкторе объекта, чтобы удалялись следующие по списку объекты.
Нужен сделать внутренний индификатор объекта, чтобы фабрика классов (которая создает объекты) могла точно знать что ей какой класс создовать.
Ну и нужно грамотно описать базовый абстрактный клаасс. чтобы туда больше нелезть.
--
что делать когда есть некий класс потомок, у которого ессть совершенно космичесткие методы которые есть только у этого потомка а у другого нет?
МОжно сделать так. пробежатся по всему списку, найти по индификатору объект "CObjectCosmos" привезти его к типу CObjectCosmos, и выполнить у него метод CObjectCosmos::superGood();
Будет лучше, если этот функционал по поиску нужных функций в нужных объъектов завернуть в некий класс под именим execFunction;
тобишь, в итоге можно получить следующие

CObject * obj = new CObject;
obj->add(new CObjectArmor);//добавим в список объекта амуницию
obj->add(new CObjectMove);//объект может перемещатся
obj->add(new CObjectCosmos);//космическая поебень

....
new execFunction_superGood(obj); //выполняем функцию космической поебени
//тоесть execFunction бежит по всему списку объекта, ищет там нужный класс и дергает для него функцию супергуд.
..
типа так.
Прочитал еще раз... подумал еще раз...
я не вижу огромных различий между этим способом и способом описанном в последнем сообщении только то что ты предлагаешь имеет возможность даже создать предмет(обьект) с 2-мя одинаковыми свойствами типа
obj->add(new CObjectMove);
obj->add(new CObjectMove);
и он сможет перемещатся вдвойне...
все-же пока жесткое закрепление одного указателя на одну подсистему(понравился термин) мне нравится больше, чем связанный список подсистем. но вообще спасибо :) знания они всегда полезны :) отказался счас может в будущем где пригодится главное я понял все-же :) что ты имел ввиду!

Аватара пользователя
Aerton
Сообщения: 503
Зарегистрирован: 11 авг 2007, 02:58
Откуда: Новосибирск
Контактная информация:

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Aerton » 03 май 2010, 13:53

Jesus05 писал(а):Я правильно нарисовал? общую идею???
В общем, верно.

Только пример разделения кажеся излишне конкретизированным - восстановление или изменение по сути ничем не отличаются, кроме срока действия. Это можно обозначить одним параметром, не вводя новых классов.

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

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Jesus05 » 03 май 2010, 14:21

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

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

но это все уже не принципиально :)

Спасибо большое всем :) буду думать и может чуть чуть писать :)

Аватара пользователя
Jolly Roger
Сообщения: 2973
Зарегистрирован: 27 ноя 2009, 09:10
Откуда: Minsk, Belarus

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Jolly Roger » 04 май 2010, 05:55

Jesus05 писал(а):
Jolly Roger писал(а):А если попробовать реализовывать отличия флагами? :oops:
я хочу уйти от методов которые будут не нужны данному обьекту. т.е. не реализовывать всем все.
[/quote]
А если захочется сделать, что-то оригинальное?
Например меч с лечением, зелье с бронёй или книгу с ядом?
Писать диздок спустя несколько лет разработки и множества изменений концепции - исконная русская девелоперская традиция.

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Jesus05 » 04 май 2010, 06:42

Jolly Roger писал(а):
Jesus05 писал(а):
Jolly Roger писал(а):А если попробовать реализовывать отличия флагами? :oops:
я хочу уйти от методов которые будут не нужны данному обьекту. т.е. не реализовывать всем все.
А если захочется сделать, что-то оригинальное?
Например меч с лечением, зелье с бронёй или книгу с ядом?
Опиши как это сделать флагами... может я и не прав...

Меч с лечение по принципу.
Во первых это меч.
во вторых это юзабельный предмет?

или
Во первых это мечь
Во вторых на нем заклинание HealSelf после каждого удара.

или
Во первых это мечь
Во вторых кем его удариш тех он лечит.

:) зелье с броней те-же вопросы..
1. Бутылек можно надеть на тело, но еще и выпить.
2. Бутылек можно надеть на тело, и он постоянно действует. (плаваешь в лечащей мазе\жидкости)

Книгу с ядом....
Учитывая что предметами будут все предметы в игре (Стены\Ловушки\Книги\Бутыльки\Одежда\Оружие)
Они будут иметь одинаковый набор возможных подсистем.
Что мешает совместить Книгу(узабельный предмет)\ловушку(действие срабатвающее при определенных условиях) при таком построении я пока не вижу.

Аватара пользователя
Jolly Roger
Сообщения: 2973
Зарегистрирован: 27 ноя 2009, 09:10
Откуда: Minsk, Belarus

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Jolly Roger » 04 май 2010, 07:03

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

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

С флагами просто, если у предмета есть флаг CAN_HEAL_SELF то он может лечить.
Писать диздок спустя несколько лет разработки и множества изменений концепции - исконная русская девелоперская традиция.

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Jesus05 » 04 май 2010, 07:28

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

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

С флагами просто, если у предмета есть флаг CAN_HEAL_SELF то он может лечить.
Хорошо.
Ну вот на уровне подсистем.
Предмет имеет подсистемы (все предметы имеют указатель на эти подсистемы)
1. Ношение
2. Использование
3. Постоянное действие
4. Действия по событию

отсюда мы можем создать
Стену которую нельзя носить, которая не имеет постоянных действий, которая не имеет действий по событию и которая не используется. Значит все эти указатели будут либо NULL либо указывать на классы пустышки. (типа "Этот предмет нельзя использовать", "Этот предмет нельзя одеть"... и т.д.)
Броню которая будет иметь 2 нормальных класса Ношение и Дейтсвия по событию. а на оставшихся 2-х будут заглушки.
В ношении будет Наследованный класс у которого защит слот в который броню можно надеть и параметры которые броня может дать. (ну как-то так... я же еще не все обдумал)...
В Действиях по событию (а тут еще класс\флаги\стурктуру событий надо строчить) если броня на ком-то надета то она каждый ход (или каждые N-тиков(о времени я пока даже не задумывался... но уже читал где-то в соседней теме) лечит того на ком надето.

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

а вообще если честно надо бросать эти все сложности.... и писать игру а не размышлять о вариантах...
а тут еще Ева (eve-online) всплыла... Спасите!!! меня снова затягивает в этот водоворот :)

Аватара пользователя
Jolly Roger
Сообщения: 2973
Зарегистрирован: 27 ноя 2009, 09:10
Откуда: Minsk, Belarus

Re: То-ли движок ради рогалика... то-ли рогалик ради движка...

Сообщение Jolly Roger » 04 май 2010, 07:36

Вот тут то и загогулина, как это сделать лучше?
Честно говоря, сам мучаюсь.

Что касается заглушек, то они, относительно, есть только в параметрах предметов.
Например у бутылочки с зельем есть показатель брони и силы атаки и бронебойности. По большому счёту, они не нужны, но потом, может захочется сделать метательные зелья или зелье попадёт в ситуацию Которая Никогда Не Должна Произойти, например будет атаковано или будет использовано NPC для атаки, программа сохранит стабильность. :?

Что касается флагов, то им присуща, как мне кажется, даже излишняя мобильность, которая может вылиться в ошибки управления.

В общем, как пишут вконтактные хомяки в графе семейное положение: всё сложно.
Писать диздок спустя несколько лет разработки и множества изменений концепции - исконная русская девелоперская традиция.

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 5 гостей