Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > разработка игр, графический дизайн и моделирование > Gamedev - cоздание игр: Unity, OpenGL, DirectX
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 28.07.2013, 12:41   #31
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

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

Игра, конечно, будет оконная, то есть не консольная, реализована на Qt. Но конкретная реализация (через WinAPI или библиотеки) не так важна, поскольку та же работа с окнами будет инкапсулирована в отдельный менеджер, реализацию которого можно будет сделать какой угодно.

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

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

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

А пост про проектирование практически готов, осталось только вычитка и оформление, так что сегодня-завтра наконец его выложу. Получился действительно очень большой, хотя я и пытался не растекаться мыслию по древу. История поста могла бы послужить поучительной иллюстрацией к собственному содержанию. Рефакторинг там был тот еще...
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 29.07.2013, 06:08   #32
intmain
Играюсь с Python
Форумчанин
 
Аватар для intmain
 
Регистрация: 12.12.2012
Сообщений: 340
Лампочка

Цитата:
Вообще, в связи с предложениями
Есть еще предложение постоянно править 0 пост или последний.
Добавлять туда ссылки на сообщения, с кратким описанием.
Выстроить четкий лист, иерархию ссылок, этапов, оглавление.
Чтобы чел. с улицы в первом(последнем) же сообщении мог обратиться к интересующему его этапу, и не читать 2001000 сообщений треда. Имхо это один из важных моментов поскольку разбираться в линейном долгом повествовании мало кто хочет. (Этот косяк есть у другой местной теме, где людей часто тыкают в то что они поленились и не прочли все 100500 сообщений треда и а потом сообщают им номера особо просветляющих постов.)

Цитата:
Насчет представления кода на суд общественности пока думаю
тут кто-то писал в своей подписи, что слова ничто... покажите мне код, так я от части согласен )


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

Вот в качестве примера там хоть и тема другая но подача инфы самая классная имхо. и музло, доставляет )
Что ел то - в долг, что жил то - зря.
Для избранных. ))
Секретные разработки
intmain вне форума Ответить с цитированием
Старый 29.07.2013, 09:37   #33
Fanyuus
Форумчанин
 
Аватар для Fanyuus
 
Регистрация: 07.05.2011
Сообщений: 169
По умолчанию

О, жаль что наши с intmain'ом сообщения удалили, ну да ладно.

Там ещё было предложение по поводу ссылок на вэбресурсы или книги (автор, название, глава, страница), чтобы упростить работу с пояснентями, так как у меня с opengl никак вообще, как и у intmain'a.))) Т.е., это бы намного облегчило процесс с перевариванием инфы. Вооот))
Fanyuus вне форума Ответить с цитированием
Старый 29.07.2013, 14:52   #34
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

Цитата:
Есть еще предложение постоянно править 0 пост или последний.
Добавлять туда ссылки на сообщения, с кратким описанием.
Выстроить четкий лист, иерархию ссылок, этапов, оглавление.
Чтобы чел. с улицы в первом(последнем) же сообщении мог обратиться к интересующему его этапу, и не читать 2001000 сообщений треда. Имхо это один из важных моментов поскольку разбираться в линейном долгом повествовании мало кто хочет. (Этот косяк есть у другой местной теме, где людей часто тыкают в то что они поленились и не прочли все 100500 сообщений треда и а потом сообщают им номера особо просветляющих постов.)
Собственно, это с самого начала задумывалось, но поскольку первый пост не резиновый (50к символов, причем с учетом всех ББ-кодов), то ссылки будут только на совсем важные посты.
Цитата:
можешь попытаться когда пишешь код, захватывать его в видео поток.
потом повставлять пауз в каком-нибудь редакторе с всплывающими сносками что щас делается и почему. голос не нужен. лучше музон и сноски с паузами )
Подумаю над этим вариантом, хотя пока еще до этого дойдет...

Цитата:
Там ещё было предложение по поводу ссылок на вэбресурсы или книги (автор, название, глава, страница), чтобы упростить работу с пояснентями, так как у меня с opengl никак вообще, как и у intmain'a.))) Т.е., это бы намного облегчило процесс с перевариванием инфы. Вооот))
Ссылок по каждому поводу точно не будет, т.к. я предполагаю, что базовая матчасть читателю известна (к учебнику по игрострою добавлять еще и учебник по плюсам, OpenGL, DirectX и куче всего остального я просто тресну). Будут они разве что по каким-то нетривиальным моментам (плюс к тем пояснениям, которые я сам буду давать) или какие-то общие.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 29.07.2013, 15:24   #35
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

Проектирование и программирование - галопом по Европам

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

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

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

Предмет беседы

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

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

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

Но вообще - да, программист потом будет просто воплощать то, что написано в проекте. Даром что сам проект составлялся на основе того, что до этого писал тот же самый программист.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 29.07.2013, 15:25   #36
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

Разделяй и властвуй

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

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

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

Однако, довольно лирики, вернемся к проектированию программ, и игр в частности. Осознав сложность системы в целом, мы разбиваем ее на независимые подсистемы, каждая из которых будет проще исходной системы. Затем их также разбиваем на части - и так до тех пор, пока не получим фрагменты, которые уже легко сможем реализовать без необходимости дальнейшего упрощения. Это, кстати, и есть канонический принцип "Разделяй и властвуй".

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

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

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

Связи и зависимости подсистем друг от друга определяют их внешний интерфейс, а также то, как именно они взаимодействуют друг с другом.
Создавая интерфейс (то есть набор доступных пользователю функций, классов и т.п.), важно не добавлять какие-то возможности "чтобы было" в надежде, что когда-нибудь они кому-то понадобятся (подобная идея лежит в основе принципа YAGNI - You Ain't Gonna Need It, "Вам это не понадобится"). Некоторые возможности могут оказаться совершенно невостребованными в реальности, но при этом не только отнимут время на их реализацию, но и могут наложить неприятные ограничения на систему, что приведет к никому не нужному усложнению и снижению полезности системы. Гораздо легче добавить вновь понадобившуюся функциональность, чем выкинуть не пригодившиеся возможности и затем "починить" систему, избавив ее от старых ограничений.

То, как именно будут взаимодействовать подсистемы, поможет лучше описать каждую из них. Описание, для чего та или иная часть используется, является хорошим дополнением к описанию того, что она из себя представляет.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 29.07.2013, 15:25   #37
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

User story и Epic story

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

К примеру, user story для игры обычно являются частью ее диздока (зачастую в неявном виде).

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

Существует разновидность пользовательских историй, называемая epic story. Если user story может описывать отдельные аспекты использования системы или ее части, то эпик характеризует в общих чертах главную цель, преследуемую при использовании системы целиком.

Например, для моего проекта эпик можно сформулировать так: "Ведя проект, я буду писать игру и описывать процесс ее создания, что повысит мои навыки игростроения, поможет мне создать себе некоторую репутацию и сформирует своеобразный учебник геймдева для начинающих". При этом можно выделить отдельные user story, такие как "По мере работы над проектом я буду публиковать посты на своем сайте, в которых буду описывать свои наработки, проблемы и методы их решения, что поможет мне собрать фидбек, сделать себе репутацию и представит наглядное учебное пособие для посетителей сайта". При этом такая отдельная user story проекта может служить epic story для сайта проекта.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 29.07.2013, 15:25   #38
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

Иерархические уровни проекта

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

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

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

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

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

Наконец, самая нижняя ступень (по крайней мере, в объектно-ориентированных языках подобных C++) - это отдельные классы. Они являются элементарными составляющими проекта. Например, Страуструп в "Специальном издании" в основном говорил о проектировании отдельных классов. На этом уровне определяется как минимум полный интерфейс каждого класса (возможно, не учитывая детали реализации, скрытые от пользователя в private-секции или с помощью методики pimpl).
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 29.07.2013, 15:25   #39
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

Проектирование и программирование - итеративный клубок

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

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

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

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

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

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

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

В-третьих, код, содержащий множество таких грубых локальных правок, очень трудно модифицировать. Поскольку подобные костыли выбиваются из четкой структуры приложения, при внесении изменений крайне сложно оценить их влияние на тот или иной кусок подобного кода. Тем более трудно подогнать специфичные костыли под новую структуру, особенно если необходимость подгонки обнаруживается только после двухдневной возни с отладчиком в попытках понять, что именно так неожиданно сломалось. Если же костылей много - код становится практически не модифицируемым, и проект просто не сможет развиваться.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 29.07.2013, 15:26   #40
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

Подготовка проекта и кода к изменениям

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

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

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

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

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

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

В итоге, хотя мы изначально собирались делать нашу игру только для Windows, совершенно забыв о двух наших хороших знакомых - убежденном линуксоиде и сотруднике некоего ящика, мы смогли без особых проблем обеспечить кроссплатформенность. Для этого потребовалось только написать два новых класса (забудем на время о всех прочих системах уровня движка), поскольку задел в виде абстрактного класса с унифицированным интерфейсом уже существовал.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Электронно учебное пособие gloomy_jr Общие вопросы Delphi 1 23.05.2012 14:07
Создание игры::особенности коллективной разработки флеш приложений АТИКОН Gamedev - cоздание игр: Unity, OpenGL, DirectX 9 21.08.2011 19:51
Мультимедийное учебное пособие world12_tk Помощь студентам 4 21.04.2011 17:37
статья - Может-ли ПО работать быстрее или взгляд изнутри Pblog Обсуждение статей 0 27.02.2011 23:10
Электронное учебное пособие Zeibel Помощь студентам 10 31.05.2010 10:55