Концепция Ресурсов

[sweeper]

<div class='quotetop'>Цитата(Aku_Aku * 19.7.2009, 21:35) [snapback]296406[/snapback]</div>

Вот если я например, возьмусь делать боевую систему для которой нужно передвигать юниты-армии по карте? Через какой интерфейс мне цеплятся к вашей карте-сфере? Как на ней отображать юниты?
[/b]

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

Шучу ли я? Почти нет.

[Peter]

можно поподробнее о виртуальных деструкторах

[serzhant]

<div class='quotetop'>Цитата(Finansist&#39;s sworn brother * 27.7.2009, 23:57) [snapback]297483[/snapback]</div>

serzhant, ты ставишь комментарий // , ты не программист?
[/b]

нет))) просто так удобнее. а уровень знаний по програмированнию - очень начальный)

[bartalbe]

<div class='quotetop'>Цитата</div>

А, это как раз просто. Нужно создать адаптеры, а в базовых классах - виртуальные функции, потом перейти на архитектуру модель-представление. Использовать подходящий паттерн. И не забывать о виртуальных деструкторах.[/b]

Ну да, если с такой позиции смотреть на наследование, то, да, плевое дело

<div class='quotetop'>Цитата</div>

можно поподробнее о виртуальных деструкторах [/b]

У меня есть вопрос к, так сказать, программистам. Вы примерно представляете себе объем работы?

[Peter]

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

[sweeper]

<div class='quotetop'>Цитата(Peter * 28.7.2009, 10:24) [snapback]297500[/snapback]</div>

можно поподробнее о виртуальных деструкторах
[/b]

Можно.

Предположим, мы хотим рисовать на экране круги и квадраты. Причем, возможно также, через некоторое время к ним добавятся другие фигуры. То, что мы хотим рисовать, надо где-то хранить. ООП-шный программист поступает так: объявляет базовый класс "Фигура", и наследующие от него "круг" и "квадрат". Базовый класс вбирает в себя всё общее, что есть у этих фигур. Каждый наследующий класс - это базовый класс плюс еще что-то.

Базовый класс имеет функцию-член для рисования. Но она чисто виртуальная, то есть для самого класса "Фигура" операция "нарисовать" бессмысленна. Смысл она обретает в потомках.

Удобно хранить всю картинку как список указателей на фигуры (пусть примеры будут в контексте Qt):

QList<CFigure*> list;

Тогда отображение всего списка по порядку будет вызов операции рисования для каждого указателя.
Это удобно, и можно добавлять новые фигуры, не трогая код собственно рисования всей картинки.

Теперь при чем тут виртуальные деструкторы. Когда элемент списка надо будет уничтожить, к нему будет применен оператор delete. Но если не объявить деструктор в базовом классе виртуальным, вызовется деструктор для базового класса, который уничтожит все объекты, о которых он знает. Однако объекты, содержащиеся в разнице между всем классом и базовым, то есть то, что собственно, составляет расширение базового класса до наследника, останется неуничтоженным. Иногда это очень существенно, и утечка памяти в такой ситуации - меньшее из зол. Поэтому вместе с виртуальной функцией рисования нужно объявить в базовом классе еще и виртуальный деструктор, который будет реализован в каждом потомке по-своему.

[Peter]

Понятно, sweeper.
я пишу под .NET, там при создании/уничтожении объекта вызываются все конструкторы и деструкторы какие есть у классов в цепочке наследования.
поэтому про виртуальные деструкторы я не слыхал
раньше писал на дельфи, там их тоже вроде не было

[PavelZ]

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

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

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

Кстати когда художник начинает говорить о экономике на меня тоже может напасть зевота...

На счёт языков программирования лагерь разделился, у кого Питон, у кого Си ++, у кого Си шарп, вроде даже на Дельфи где-то был намёк, конечно профессиональным программистом не являюсь, но основы так сказать ведомы. Поэтому могу на себя взять смелость посоветовать всё таки объединить усилия и сконцентрироваться на одной среде и .NET в нашем случае может подойти большинству из присутствующих. А в качестве движка взять Unity3D .

Теперь прихожу к аргументации и прошу желающих поспорить отвечать по существу

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

В Unity3D можно программировать сразу на трёх языках основанных на .NET: на специально разработанном для Юнити диалекте Action Script, Си шарп и диалекте Питона Boo имеющем более короткий синтаксис, а главное более приближенным к функциональной парадигме. Мне последний вариант наиболее симпатичен, так как он наиболее удобен для реализации игрового ИИ. Впрочем большинство кода написанного на Си шарпе и Питоне можно с лёгкостью переложить на него и получить более компактный код с одной стороны, а с другой сделать его более шустрым даже по отношению к Си шарп.

[sweeper]

Да, хорошо бы иметь в сутках 50 часов, а в неделе - 500. Тогда можно и шарп изучить, и юнити. А еще лучше это всё было сделать 20..30 лет назад, когда мозх был еще податливый.

[Aku_Aku]

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

Например вон с репозиториями никто не знаком.

[Peter]

под Boo компилируемый код пишется или интерпретируемый? Если второе то быстрее си шарп он не будет.

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

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

Юнити3д - надо будет посмотреть что за зверь. Вообще графикой сейчас занимается superregistr, и он это делает на опенГЛ.

[PavelZ]

<div class='quotetop'>Цитата</div>

Да, хорошо бы иметь в сутках 50 часов, а в неделе - 500. Тогда можно и шарп изучить, и юнити. А еще лучше это всё было сделать 20..30 лет назад, когда мозх был еще податливый.[/b]

Как я тебя понимаю!!! Мне как инженеру электронщику, занимающемуся этим с детства, очень сложно сейчас осваивать программирование на современном уровне, хотя в юности были и Паскаль, и Бейсик, и даже ассемблер.

Я немного приукрасил Бу, в Юнити он работает всё под той же Моно, но сами по себе примеры функционального программирования на нём выглядят изящнее и не секрет что многие программы написанные в функциональном стиле работают быстрее ООПэшных.

Репозиторий понадобится когда определимся всё таки с единой средой. Я могу у себя на VDS предоставить место под это всё, а участникам научиться пользоваться тоже думаю не станет проблемой.

Кстати Юнити именно игровой движок, а не чистый рендер, там есть всё что нужно для игры в том числе и физика, кде-то мысль проскакивала расчитывать бой нескольких единиц по принципу соударения тел... Также пусть не пугает аббревиатура 3Д, на нём можно делать и что попроще, к примеру 2,5