То-ли движок ради рогалика... то-ли рогалик ради движка...
Модератор: Jolly Roger
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: То-ли движок ради рогалика... то-ли рогалик ради движка...
Это первый способ.
GameObject будет иметь минимум свойств
Метод ответа если на него пытаются наступить виртуальный.
Координаты на карте не виртуальные
Отмечен на карте.
Видимый.
методы думаю не виртуальные.
Привязать к карте.
Установить координаты на каком-то месте карты.
Удалить с какого-то места карты.
ну и указатель на следующий игровой обьект. (в случае если их несколько на одном месте карты).
Ну еще я до сих пор не решил где хранить "картинку"(цвет\букву\фон) которую надо отрисовывать.
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: То-ли движок ради рогалика... то-ли рогалик ради движка...
Согласен что наследование ЗЛО но так хочется разобратся в нем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: То-ли движок ради рогалика... то-ли рогалик ради движка...
А если попробовать реализовывать отличия флагами?
Писать диздок спустя несколько лет разработки и множества изменений концепции - исконная русская девелоперская традиция.
- Aerton
- Сообщения: 503
- Зарегистрирован: 11 авг 2007, 02:58
- Откуда: Новосибирск
- Контактная информация:
Re: То-ли движок ради рогалика... то-ли рогалик ради движка...
Лучше в данном случае оперирвать не в тех понятиях классов, которые ты привёл в начале, а подсистем, отвечающих каждая за одну задачу. Т.е. каждая игровая сущность является собою набором подсистем.Jesus05 писал(а):1. Создать класс у которого будут указатели на все нужные мне классы
Код: Выделить всё
class Entity {
MovementSystem *move;
DamageSystem *damage;
UseSystem *use; // не придумалось имя получше - эта система работает когда предмет используют
};
Аналогично делаются подситсема повреждений, использования, атаки и все остальные.
Тогда описание сущности в файле - это перечень использумых в ней подсистем и параметров для них.
Код может выглядит и не слишком по-другому, но разница в подходе. Это уже не Object-Oriented, а Data-Driven.
Одно из главных преимуществ - подсистемы можно заменять на лету. Например, potion of flight при распитии заменяет подсистему перемещения на летучую.
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: То-ли движок ради рогалика... то-ли рогалик ради движка...
я хочу уйти от методов которые будут не нужны данному обьекту. т.е. не реализовывать всем все.Jolly Roger писал(а):А если попробовать реализовывать отличия флагами?
А вот это мне нравится, есть ссылочки что-нить почитать по Data-Driven(новый для меня термин и Вики + Google ничего внятного на русском не подкинули) подходу?Aerton писал(а):...
Код может выглядит и не слишком по-другому, но разница в подходе. Это уже не Object-Oriented, а Data-Driven.
Одно из главных преимуществ - подсистемы можно заменять на лету. Например, potion of flight при распитии заменяет подсистему перемещения на летучую.
- Aerton
- Сообщения: 503
- Зарегистрирован: 11 авг 2007, 02:58
- Откуда: Новосибирск
- Контактная информация:
Re: То-ли движок ради рогалика... то-ли рогалик ради движка...
К сожалению, каких-либо обширных работ по этой теме мне не встречалось, в основном какие-то отдельные статьи, как например в первом томе Game Programming Gems. В принципе, Jeff Lait на rgrd практикует подобный подход и иногда описывает его в своих постах.Jesus05 писал(а):А вот это мне нравится, есть ссылочки что-нить почитать по Data-Driven(новый для меня термин и Вики + Google ничего внятного на русском не подкинули) подходу?
А так даже не знаю, есть ли в русском устоявшийся перевод термина, чтобы искать по нему.
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: То-ли движок ради рогалика... то-ли рогалик ради движка...
Я правильно нарисовал? общую идею?Aerton писал(а):...
Лучше в данном случае оперирвать не в тех понятиях классов, которые ты привёл в начале, а подсистем, отвечающих каждая за одну задачу. Т.е. каждая игровая сущность является собою набором подсистем.
Например, MovementSystem имеет несколько методов, отвечающих за перемещение. И именно от него уже наследуются различные классы перемещения: для обычных монстров это хождение по полу, для плавающих - по воде, и тп., для предметов - заглушка или просто нулевой указатель.Код: Выделить всё
class Entity { MovementSystem *move; DamageSystem *damage; UseSystem *use; // не придумалось имя получше - эта система работает когда предмет используют };
Аналогично делаются подситсема повреждений, использования, атаки и все остальные.
Тогда описание сущности в файле - это перечень использумых в ней подсистем и параметров для них.
...
т.е. От игрового обьекта наследуется класс Предмет который выглядит как
Код: Выделить всё
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();
};
??
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: То-ли движок ради рогалика... то-ли рогалик ради движка...
Прочитал еще раз... подумал еще раз...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: То-ли движок ради рогалика... то-ли рогалик ради движка...
В общем, верно.Jesus05 писал(а):Я правильно нарисовал? общую идею???
Только пример разделения кажеся излишне конкретизированным - восстановление или изменение по сути ничем не отличаются, кроме срока действия. Это можно обозначить одним параметром, не вводя новых классов.
А классы использовать для реализации более существенной разницы в функционировании. Та же команда use у предметов нередко может произвести целую кучу разных действий: изменение параметров прочитавшего, изменение параматров оружия прочитавшего, телепортация, создание предмета или монстра, открытие карты, активация заклинания и тп. Иначе говоря, классы водить для эффектов, которым требуется новая игровая логика, новый программный код, а какого именно монстра создавать, в каком кол-ве и надолго ли - это уже просто параметры.
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: То-ли движок ради рогалика... то-ли рогалик ради движка...
Ну тут подразумевалось Восстановление это снятие эффекта.Aerton писал(а):...
Только пример разделения кажеся излишне конкретизированным - восстановление или изменение по сути ничем не отличаются, кроме срока действия. Это можно обозначить одним параметром, не вводя новых классов.
А классы использовать для реализации более существенной разницы в функционировании. Та же команда use у предметов нередко может произвести целую кучу разных действий: изменение параметров прочитавшего, изменение параматров оружия прочитавшего, телепортация, создание предмета или монстра, открытие карты, активация заклинания и тп. Иначе говоря, классы водить для эффектов, которым требуется новая игровая логика, новый программный код, а какого именно монстра создавать, в каком кол-ве и надолго ли - это уже просто параметры.
Изменение превращение в что-то другое (в монстра).
Временно действующие это Наложение эффекта.
но это все уже не принципиально
Спасибо большое всем буду думать и может чуть чуть писать
- Jolly Roger
- Сообщения: 2973
- Зарегистрирован: 27 ноя 2009, 09:10
- Откуда: Minsk, Belarus
Re: То-ли движок ради рогалика... то-ли рогалик ради движка...
я хочу уйти от методов которые будут не нужны данному обьекту. т.е. не реализовывать всем все.Jesus05 писал(а):Jolly Roger писал(а):А если попробовать реализовывать отличия флагами?
[/quote]
А если захочется сделать, что-то оригинальное?
Например меч с лечением, зелье с бронёй или книгу с ядом?
Писать диздок спустя несколько лет разработки и множества изменений концепции - исконная русская девелоперская традиция.
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: То-ли движок ради рогалика... то-ли рогалик ради движка...
Опиши как это сделать флагами... может я и не прав...Jolly Roger писал(а):А если захочется сделать, что-то оригинальное?Jesus05 писал(а):я хочу уйти от методов которые будут не нужны данному обьекту. т.е. не реализовывать всем все.Jolly Roger писал(а):А если попробовать реализовывать отличия флагами?
Например меч с лечением, зелье с бронёй или книгу с ядом?
Меч с лечение по принципу.
Во первых это меч.
во вторых это юзабельный предмет?
или
Во первых это мечь
Во вторых на нем заклинание HealSelf после каждого удара.
или
Во первых это мечь
Во вторых кем его удариш тех он лечит.
зелье с броней те-же вопросы..
1. Бутылек можно надеть на тело, но еще и выпить.
2. Бутылек можно надеть на тело, и он постоянно действует. (плаваешь в лечащей мазе\жидкости)
Книгу с ядом....
Учитывая что предметами будут все предметы в игре (Стены\Ловушки\Книги\Бутыльки\Одежда\Оружие)
Они будут иметь одинаковый набор возможных подсистем.
Что мешает совместить Книгу(узабельный предмет)\ловушку(действие срабатвающее при определенных условиях) при таком построении я пока не вижу.
- Jolly Roger
- Сообщения: 2973
- Зарегистрирован: 27 ноя 2009, 09:10
- Откуда: Minsk, Belarus
Re: То-ли движок ради рогалика... то-ли рогалик ради движка...
Кхе-кхе, не нужно привязываться к описанным предмета, я специально привёл такие, достаточно нелепые предметы, что описать саму идею, можно, что угодно броня заражающая болезнью, шлем пускающий огненные шары и даже статуэтка динозавра с контейнером для зелья, что угодно.
Примерно, кстати, как ты и описал, (правда про зелье с бронёй я думал о бронированной бутылочке, но не суть) но для того, чтобы что-то можно было сделать эти особенности у предмета должны быть, сама по себе идея наследования в том, чтобы потомок не видел и не получал лишнего и если передавать предмету доп свойства просто как запас, это несколько противоречит (хотя и логична для рогалика) озвученным выше идеям ООП.
С флагами просто, если у предмета есть флаг CAN_HEAL_SELF то он может лечить.
Примерно, кстати, как ты и описал, (правда про зелье с бронёй я думал о бронированной бутылочке, но не суть) но для того, чтобы что-то можно было сделать эти особенности у предмета должны быть, сама по себе идея наследования в том, чтобы потомок не видел и не получал лишнего и если передавать предмету доп свойства просто как запас, это несколько противоречит (хотя и логична для рогалика) озвученным выше идеям ООП.
С флагами просто, если у предмета есть флаг CAN_HEAL_SELF то он может лечить.
Писать диздок спустя несколько лет разработки и множества изменений концепции - исконная русская девелоперская традиция.
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: То-ли движок ради рогалика... то-ли рогалик ради движка...
Хорошо.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: То-ли движок ради рогалика... то-ли рогалик ради движка...
Вот тут то и загогулина, как это сделать лучше?
Честно говоря, сам мучаюсь.
Что касается заглушек, то они, относительно, есть только в параметрах предметов.
Например у бутылочки с зельем есть показатель брони и силы атаки и бронебойности. По большому счёту, они не нужны, но потом, может захочется сделать метательные зелья или зелье попадёт в ситуацию Которая Никогда Не Должна Произойти, например будет атаковано или будет использовано NPC для атаки, программа сохранит стабильность.
Что касается флагов, то им присуща, как мне кажется, даже излишняя мобильность, которая может вылиться в ошибки управления.
В общем, как пишут вконтактные хомяки в графе семейное положение: всё сложно.
Честно говоря, сам мучаюсь.
Что касается заглушек, то они, относительно, есть только в параметрах предметов.
Например у бутылочки с зельем есть показатель брони и силы атаки и бронебойности. По большому счёту, они не нужны, но потом, может захочется сделать метательные зелья или зелье попадёт в ситуацию Которая Никогда Не Должна Произойти, например будет атаковано или будет использовано NPC для атаки, программа сохранит стабильность.
Что касается флагов, то им присуща, как мне кажется, даже излишняя мобильность, которая может вылиться в ошибки управления.
В общем, как пишут вконтактные хомяки в графе семейное положение: всё сложно.
Писать диздок спустя несколько лет разработки и множества изменений концепции - исконная русская девелоперская традиция.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 47 гостей