Если в корне SD-карты создать папку Maps, то в приложении появится возможность создавать и редактировать файлы локально, без аккаунта в облаке. На данный момент эта возможность бесплатна. И ее можно скомбинировать со сторонними облачными сервисами, например, Dropbox.
Есть поддержка карт .mm в приложении от Mindjet
Совместимость, конечно, не полная, но проблем у меня за все время использования не было.
Нужно создать папку Maps на sd-карте, тогда станет доступна опция работы с файлами на устройстве — после этого можно будет подключиться и к Dropbox
Это странно, но, судя по комментариям, многие люди хотят использовать карты памяти с несколькими корневыми узлами, что, на мой взгляд, в корне не верно. Я встречал такое суждение и раньше, но думал, что это скорее редкое исключение.
На мой взгляд, каждая карта памяти создается с какой-то целью: будь то решение научной проблемы, внедрение коммерческого проекта или планирование насыщенного отпуска. Именно эта цель и должна быть корнем (центром) карты памяти, все остальное — это всего лишь пути, ведущие к этой цели. Это важно как с точки зрения составления карты (чтобы помнить, на решении чего нужно концентрироваться, а что является вспомогательной активностью), так и с точки зрения чтения — чтобы любой другой человек знал, откуда ему надо начинать.
Если решать такую задачу именно картой памяти, то я бы создал единый корень, назвав его, например, заголовком книги, а у него уже дочерними узлами перечислил все сущности (может быть предварительно сгруппировав их еще по типу). Большинство программ (я пользуюсь Freemind, но также видел Mindjet — в обеих есть) для карт памяти поддерживают ссылки между узлами, в т.ч. с возможностью просмотреть, на что ссылается данный узел и кто ссылается на него.
Во Freemind:
4. есть
5. на всякий случай уточню: есть экспорт в png
6. нет, но кроссплатформенность решается тем, что это open source и написано на java
7. нет, но, возможно, это не так уж и нужно: можно все равнозначные цели сделать дочками одного корня (например, имя проекта или программы проектов). Кросс-ссылки между узлами любых веток легко задаются, причем, как визуальные связи, так и гиперссылки для перехода.
8. есть и скрипты (но я сам скриптами не пользовался — не было необходимости) и аналог тегов (атрибуты)
9. не совсем понял, что имеется ввиду. Возможно, это также решается путем задания связей и ссылок между узлами карты (также можно вложить ссылки на любое внешнее содержимое, будь то файл или url)
Конечно!
Например во время работы над одним крупным проектом, возникла необходимость в трансформации скоупа релиза, а точнее в разделении одного релиза на несколько. Рабочая группа заказчика состояла из двух уровней: ключевая и расширенная (core и extended). Любые решения в проекте сначала обсуждались и согласовывались с ключевой группой, а потом в письменном виде согласовывались с расширенной группой.
Для обсуждения с ключевой группой, я составил карту памяти по структуре проекта, где на различных уровнях детализации были представлены все фичи, изначально затребованные бизнесом:
бизнес-процессы,
интеграция,
интерфейсы,
вспомогательные модули
и т.п.
Для целей обсуждения формат карты памяти был удобен благодаря тому, что можно вывести одновременно на проектор разные узлы в разных степенях детализации (например, ключевой процесс в детализации по шагам, вспомогательные процессы по этапам, учетные интерфейсы по страницам, процессные интерфейсы по группам, остальные особенности — крупными блоками), и проставлять визуальные отметки приоритетов и связей с различными целями проекта.
В результате каждой атомарной фиче присваивалось сразу несколько показателей по разным измерениям:
важность для использования,
важность для достижения бизнес-цели,
трудоемкость разработки,
трудоемкость внедрения,
внутренние затраты заказчика при внедрении
и т.п.
Составив такую карту и, совместно с заказчиком и командой разработки, оценив каждую фичу по необходимым критериям, дальше ее через xslt выгружали в несколько различных срезов в формате CSV, один из которых уже в виде Excel файла рассылался на согласование с расширенной группой и фиксировался в реестре согласованных документов. Другие срезы, одновременно с примененными фильтрами, использовались для планирования внутренних работ команды и отчетности по течению проекта.
Таким образом, карта памяти использовалась как основной инструмент для тесного взаимодействия. При каждом круге согласования изменения вносились только в нее, причем, наиболее наглядным образом как для команды разработки, так и для команды заказчика. А XSLT экспорт использовался для получения различных срезов согласованной информации, необходимых в данный конкретный момент времени для данной конкретной задачи.
В последней версии переоткрывать уже не нужно. Хотя подсветки последних изменений, увы, все еще нет.
Как вариант, можно использовать для этого систему контроля версий, но это уже лишние телодвижения.
Все это поддерживается во Freemind.
Единственное, не поддерживается одновременная работа через Dropbox с разных машин. На одной сохранил, на другой нужно дать время, чтобы из dropbox-а обновилось, только потом можно редактировать.
Вы не обновили таблицу поддержки платформ. С учетом того, что под android карты FreeMind можно использовать в стороннем приложении, будет честно поставить не чистый плюс, а некую сноску на пояснения под таблицей, где указать на стороннее приложение.
На счет Freemind вы ошиблись дважды:
1) Он поддерживается (последняя версия вышла 12.04.2014). Отсюда, кстати, «основная особенность» XMind перестает быть таковой.
2) Карты freemind (формата .mm) поддерживаются под android с приложением от MindJet. Возможно, есть поддержка и под iOS, к сожалению, не могу проверить.
В качестве же очень сильной возможности, присутствующей у FreeMind, я бы отметил экспорт через XSLT преобразование. При грамотно продуманных тегах или значках, это очень мощный инструмент получается, аналога которому я, на вскидку, не знаю.
Я для себя решил эту дилемму так: цель любого бизнеса — безусловно получение прибыли. Эта фраза у меня долго была в конфликте с понятием миссии бизнеса: с одной строны примеры, когда миссии либо нет, либо она без колебаний приносится в жертву сиюминутной прибыли, а с другой стороны — если бизнес не создает прибыль, то он заведомо не может достичь своей миссии.
Тогда я пришел к выводу, что если бизнес — это прибыль, то миссия — это выручка. Если делать что-то полезное для людей и делать это хорошо (в соответствии с миссией), то люди будут заинтересованы в продукте, что создаст выручку. А дальше уже задача бизнеса так управлять своими ресурсами, чтобы выручка перекрывала затраты, т.е. генерировать прибыль.
В моем восприятии книги являются скорее инструментами. И их, как любой инструмент, кто-то применяет правильно, а кто-то нет. И тут, вы правы, многое зависит от здравого смысла. Но иногда проще показать человеку примеры, чем вызывать к его разуму.
Хотите цикл постов про мою практику (не только в Мосигре), которые могут сложиться в набор знаний по маркетингу для вашего проекта?
Я был бы крайне заинтересован. Вы хорошо пишете. И особо интересны примеры, какие компании в России следуют пути, описанному у Котлера, если такая информация есть.
К слову, когда я на своей прошлой работе упомянул его книгу, в ответ услышал: «В России по Котлеру не работают». И предложение быть первыми было встречено в штыки, такие дела.
Скорее всего текст действительно рисуется каждый кадр, т.к. он может может быть динамическим. Я использовал GUIText для вывода значения рейтинга на игровом поле.
Вы правы в том, что к разработке OnGUI необходимо подходить очень тщательно, чтобы не было проблем с производительностью. Об этом пишут в т.ч. сами разработчики Unity, и уже вышла бета-версия с новым механизмом UI, который должен заменить устаревший OnGUI. Вы, кстати, ее уже попробовали? На чем делали свой интерфейс?
Однако, вы ошибаетесь в том, что раздельные сцены не позволят сделать красивые переходы: это вещи совершенно не связанные.
Возможно, раздельные сцены не позволят сделать переходы так, как они сделаны у вас, но это совсем другая формулировка, верно?
Разделение на сцены объективно имеет как преимущества, так и недостатки. Но субъективную оценку красоты предлагаю оставить игрокам, все-таки, это им должно нравится приложение, а не нам с вами.
Вам правда интересно про таблицу рекордов? Просто в вашей фразе
Посчитали ненужным или не захотели перегружать игру излишним функционалом?
оба варианта суть одно и то же. Обычно так говорят, когда для себя уже все решили, что печально. Если все же интересно, то онлайн таблицу рекордов мы планируем сделать одновременно с дополнительным режимом игры — прохождением кампании.
Если бы у меня были простые рецепты, я бы их написал, но, к сожалению, это не так. Предлагаю вместе двигаться в сторону открытия этих рецептов.
Я вижу преимущество в разделении сцен в том, что независимые компоненты максимально разделены, в т.ч., при добавлении различных новых режимов игры (например, кампании), я буду только расширять состав сцен и модифицировать интерфейс меню. Основная же логика останется в неприкосновенности, это должно минимизировать вероятность внесения новых ошибок в отлаженную функциональность.
А выплывающие меню можно сделать путем переиспользования классов, отвечающих за построение меню, например, в моем случае это можно сделать так:
Взять код, отвечающий за построение интерфейса меню (содержимое метода OnGUI) и выделить его в отдельный класс.
Изменить класс MainGUI (или SettingsGUI — в зависимости от того, какое именно меню хотим выделить), убрав из него отрисовку меню, но пронаследовав от нового созданного класса.
Пронаследовать GameGUI от нового класса и добавить вызов отрисовки меню + анимацию выезжания
Собственно, я бы сделал именно так, независимо от того, была бы у меня одна сцена или несколько.
Но в любом случае, я инкапсулировал всю логику, связанную со сценами, в один класс GUINavigator, так что в моем случае замена на одну сцену — дело 15 минут, если возникнет такая необходимость.
Совместимость, конечно, не полная, но проблем у меня за все время использования не было.
Нужно создать папку Maps на sd-карте, тогда станет доступна опция работы с файлами на устройстве — после этого можно будет подключиться и к Dropbox
На мой взгляд, каждая карта памяти создается с какой-то целью: будь то решение научной проблемы, внедрение коммерческого проекта или планирование насыщенного отпуска. Именно эта цель и должна быть корнем (центром) карты памяти, все остальное — это всего лишь пути, ведущие к этой цели. Это важно как с точки зрения составления карты (чтобы помнить, на решении чего нужно концентрироваться, а что является вспомогательной активностью), так и с точки зрения чтения — чтобы любой другой человек знал, откуда ему надо начинать.
4. есть
5. на всякий случай уточню: есть экспорт в png
6. нет, но кроссплатформенность решается тем, что это open source и написано на java
7. нет, но, возможно, это не так уж и нужно: можно все равнозначные цели сделать дочками одного корня (например, имя проекта или программы проектов). Кросс-ссылки между узлами любых веток легко задаются, причем, как визуальные связи, так и гиперссылки для перехода.
8. есть и скрипты (но я сам скриптами не пользовался — не было необходимости) и аналог тегов (атрибуты)
9. не совсем понял, что имеется ввиду. Возможно, это также решается путем задания связей и ссылок между узлами карты (также можно вложить ссылки на любое внешнее содержимое, будь то файл или url)
Например во время работы над одним крупным проектом, возникла необходимость в трансформации скоупа релиза, а точнее в разделении одного релиза на несколько. Рабочая группа заказчика состояла из двух уровней: ключевая и расширенная (core и extended). Любые решения в проекте сначала обсуждались и согласовывались с ключевой группой, а потом в письменном виде согласовывались с расширенной группой.
Для обсуждения с ключевой группой, я составил карту памяти по структуре проекта, где на различных уровнях детализации были представлены все фичи, изначально затребованные бизнесом:
Для целей обсуждения формат карты памяти был удобен благодаря тому, что можно вывести одновременно на проектор разные узлы в разных степенях детализации (например, ключевой процесс в детализации по шагам, вспомогательные процессы по этапам, учетные интерфейсы по страницам, процессные интерфейсы по группам, остальные особенности — крупными блоками), и проставлять визуальные отметки приоритетов и связей с различными целями проекта.
В результате каждой атомарной фиче присваивалось сразу несколько показателей по разным измерениям:
Составив такую карту и, совместно с заказчиком и командой разработки, оценив каждую фичу по необходимым критериям, дальше ее через xslt выгружали в несколько различных срезов в формате CSV, один из которых уже в виде Excel файла рассылался на согласование с расширенной группой и фиксировался в реестре согласованных документов. Другие срезы, одновременно с примененными фильтрами, использовались для планирования внутренних работ команды и отчетности по течению проекта.
Таким образом, карта памяти использовалась как основной инструмент для тесного взаимодействия. При каждом круге согласования изменения вносились только в нее, причем, наиболее наглядным образом как для команды разработки, так и для команды заказчика. А XSLT экспорт использовался для получения различных срезов согласованной информации, необходимых в данный конкретный момент времени для данной конкретной задачи.
Как вариант, можно использовать для этого систему контроля версий, но это уже лишние телодвижения.
Единственное, не поддерживается одновременная работа через Dropbox с разных машин. На одной сохранил, на другой нужно дать время, чтобы из dropbox-а обновилось, только потом можно редактировать.
1) Он поддерживается (последняя версия вышла 12.04.2014). Отсюда, кстати, «основная особенность» XMind перестает быть таковой.
2) Карты freemind (формата .mm) поддерживаются под android с приложением от MindJet. Возможно, есть поддержка и под iOS, к сожалению, не могу проверить.
В качестве же очень сильной возможности, присутствующей у FreeMind, я бы отметил экспорт через XSLT преобразование. При грамотно продуманных тегах или значках, это очень мощный инструмент получается, аналога которому я, на вскидку, не знаю.
Тогда я пришел к выводу, что если бизнес — это прибыль, то миссия — это выручка. Если делать что-то полезное для людей и делать это хорошо (в соответствии с миссией), то люди будут заинтересованы в продукте, что создаст выручку. А дальше уже задача бизнеса так управлять своими ресурсами, чтобы выручка перекрывала затраты, т.е. генерировать прибыль.
Я был бы крайне заинтересован. Вы хорошо пишете. И особо интересны примеры, какие компании в России следуют пути, описанному у Котлера, если такая информация есть.
К слову, когда я на своей прошлой работе упомянул его книгу, в ответ услышал: «В России по Котлеру не работают». И предложение быть первыми было встречено в штыки, такие дела.
Однако, вы ошибаетесь в том, что раздельные сцены не позволят сделать красивые переходы: это вещи совершенно не связанные.
Возможно, раздельные сцены не позволят сделать переходы так, как они сделаны у вас, но это совсем другая формулировка, верно?
Разделение на сцены объективно имеет как преимущества, так и недостатки. Но субъективную оценку красоты предлагаю оставить игрокам, все-таки, это им должно нравится приложение, а не нам с вами.
Вам правда интересно про таблицу рекордов? Просто в вашей фразе
оба варианта суть одно и то же. Обычно так говорят, когда для себя уже все решили, что печально. Если все же интересно, то онлайн таблицу рекордов мы планируем сделать одновременно с дополнительным режимом игры — прохождением кампании.
Я вижу преимущество в разделении сцен в том, что независимые компоненты максимально разделены, в т.ч., при добавлении различных новых режимов игры (например, кампании), я буду только расширять состав сцен и модифицировать интерфейс меню. Основная же логика останется в неприкосновенности, это должно минимизировать вероятность внесения новых ошибок в отлаженную функциональность.
А выплывающие меню можно сделать путем переиспользования классов, отвечающих за построение меню, например, в моем случае это можно сделать так:
Собственно, я бы сделал именно так, независимо от того, была бы у меня одна сцена или несколько.
Но в любом случае, я инкапсулировал всю логику, связанную со сценами, в один класс GUINavigator, так что в моем случае замена на одну сцену — дело 15 минут, если возникнет такая необходимость.