Структура классов для РПГ

[NikSa]

Доброго времени суток, очередной один из 20 таких же вопросов за сегодня. :-)
В очередной раз подхожу к вопросу создания игры и сталкиваюсь с тем же вопросом: "Как правильно и удобно построить структуру классов и методов"
1. Сколько и какие должны быть базовые классы?
- Character
- Item
- Location
- ?
2. Методы взаимодействия между объектами одинаковых и разных классов должны быть реализованы в этих же классах или должен быть отдельный action class?
Character1.Attack(Character2);
или
Action.Fight(Character1,Character2, "Attack");
может
Item1.AplyProperties(Character1);
или
Character.Aply(Item1);
или
Action.AplyProperties(Character1,It em1);

3. Какие из свойств объектов, например Character1 должны быть рассчитаны заранее (модификаторы, только базовые хар-ки, или только должны быть окончательно определены необходимые формулы расчета) перед применением действия. Насколько это безопасно с точки зрения возможности пропустить важный расчет модификатора, насколько целесообразно нагружать процессор расчетом с нуля каждого действия?

Честно говоря пока никак не укладывается в голове структура. Никак не могу выбрать, решить и до конца понять с чем столкнусь.

ЗЫ Как программист я пока себя похвалить не могу, в крупных проектах не участвовал, приходилось писать небольшие утилиты, небольшой модуль вебприложения на разных языках.

[Juffin]

1. Это решать тебе, сделай так, как тебе кажется логично и удобно. Так же все зависит от самой игры - РПГ бывают разные.
2. Смотря какие взаимодействия. Например, подбирание предмета можно сделать как метод персонажа, потому что он "главный", а бой процедурой ( Fight(Char1,Char2) ), потому что персонажи "равны". Опять же, все зависит от игры.
3. Тут тоже как хочешь. Единственное, что могу сказать - процессоры сейчас мощные, поэтому вычислением 5-6 характеристик ты его не сильно нагружишь.

[liljon]

как у вас вообще устроен АИ?

[NikSa]

Juffin спасибо за ответ.
В общем за вчера немного организовал в своей голове понимание что я хочу увидеть :-)
РПГ риалтаймовая, т.к. многопользовательская :-) по этому все будет обрабатываться за тики. На сейчас начал организовывать базовые классы со свойствами и обработчик действий. Т.е. Именно обработчик будет производить все действия над группами объектов. Сами базовые классы будут иметь только свойства действий по которым обработчик будет определять необходимые действия. Тем самым я огражу себя от несанкционированного изменения объекта, и смогу управлять ветвлениями в одном месте (классе). Но меня уже начал пугать этот обработчик, слишком он громоздкий представляется. Очень хочется описать интерфейсы, но никак не можется, т.к. до конца не ясно кто за что отвечает. Расчет параметров уходит на 3-й план, это даже не вопрос по сравнению с другими вставшими на повестку. :-)
liljon пока никак. И я не понимаю ваш вопрос :-)

ЗЫ Пишу на C# в свободное от работы время.

[liljon]

Объекты, с которыми взаимодействуют игроки, стоит рассматривать как аи (например теже предметы которые следует подбирать, магазины, боты и.т.д.), управлемый менеджером (основным классом).
Вообще как вы научита бота выполнять Action.Fight(Character1,Character2, "Attack") ? Как он узнает когда это надо выполнить?

Почитайте про технологию автоматов и вы меня поймете

[NikSa]

liljon, спасибо за статью. Исходя из того что я начал, похоже я начал описывать второй тип ИИ, т.е. глобальный. На данный момент я вижу основной менеджер, который будет обрабатывать все объекты-автоматы (работающие по "правилам"). Конечно нейронные сети это круто, но как замечает автор "CHOREOGRAPHED AI" до сих пор достоен внимания. :-)
Жаль, что эта статья не попалась мне вначале сэкономила бы мне время :-) Видимо не то гуглил.

Буду благодарен за советы. :-)

[Вадим Буренков]

Почитайте про технологию автоматов и вы меня поймете

Полезная статья. Хотя до нечто подобного я в свое время сам додумался.

[Виталий Желтяков]

Насколько Я понимаю ситуацию, у Вас очень неправильный подход к делу. Дело в том, что Вы хотите использовать классы - решение, конечно, красивое и в некоторой степени удобное, но обработка классов весьма трудоемкое занятие (для компьютера). Это может привести в итоге к "томозам". На Вашем месте Я бы использовал массивы данных.

[Пепел Феникса]

но обработка классов весьма трудоемкое занятие (для компьютера).

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

ЗЫ: тут очень многое зависит от реализации.

[NikSa]

Спасибо за дискуссию.
Однажды, очень давно, когда я только изучал программирование, я написал какую то программку на паскале использовав рекордсеты и функции. Чуть позже я стал изучать классы и ООП и решил ради интереса переписать свою программу. Я ее полностью переписал, заменил рекордсеты на классы, а функции сделал методами этих классов. Фактически в программе ничего не поменялось, лишь блоки кода перенеслись в другие места. После чего я откомпилировал обе программы и засек время их выполнения, вариант с классами отработал в полтора раза дольше :-( Это было еще на ЕС 1840, в те года, когда о "двойках" только мечтали ;-) и естественно производительность стояла не первом плане. Сейчас я глубоко сожалею о том опыте, потому, как он заставил меня бросить изучать ООП и фактически направил меня в другое русло.

Но сейчас я ни за какие коврижки не откажусь от использования классов, потому, что ту мощь возможностей программирования, которую предоставляет ООП просто не может затмить проблема с быстродействием. В конце концов распараллелить процессы заставить их исполняться в нитях, использовать более мощное железо, вынести тяжелые процессы в отдельные службы, в конце концов на отдельное железо, оптимизировать код до бесконечности, но никогда не возвращаться к процедурному подходу!

Однако, хотя я написал пока очень мало, :-) меня уже смущает моя реализация обработки правил. На данный момент для этого уже существует 3 базовых класса и пара производных. А ведь это основное, что будет выполняться постоянно. :-(