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

Вот список типичных проблем:

1. в репозиторий попадают ненужные файлы или наоборот не попадают нужные
2. множество больших файлов раздувает размер репозитория
3. проблема с мерджем yaml файлов Unity
4. в репозиторий добавлен только сам файл или только meta
5. в проекте присутствуют пустые папки
6. сложность автоматической нумерации версий и билдов
7. неудобство использования кода между несколькими проектами

О решение этих проблем, связанных с совместным использованием git и Unity, вы можете прочитать в моем цикле статей.

В этой статье будет описано решение первых трех проблем

В данной статье речь пойдет об отладке кода под Android.
За последнее время произошло много подвижек в этом направление. Появился Android Studio, google добавило поддержку отладки нативного кода в eclipse.
Если необходимо отладить только Java, то Android Studio покроет ваши потребности полностью.
Если необходима отладка с++ или Java кода то ADT Bundle со встроенным Eclipse опять же поможет решить вашу проблему.
Если вкратце

• Дать понять Eclipse что проект содержит нативную часть(Add native support)
• Убедиться что в команде сборки стоит NDK_DEBUG=1
• Нажать Debug as Android Native Application

на некоторых девайсах реобходимо еще и поставить в манифесте debuggable в true
Но если необходимо отлаживать jni код, где попеременно работают c++ и Java функции, то вам этот способ не подойдет, потому-что в зависимости от выбранного способа отладки(Android Native Application, Android Application) работает отладка либо с++ либо java кода.
О том как отлаживать смешанный код пойдет речь далее в статье.

В статье «String enum — строковые enum» я писал о том как связывать текстовые представления с enum class — метод хороший но только если все элементы заранее известны, но зачастую бывает что строки являются некими идентификаторами и конечно же заранее не известны, а зачастую будут добавляться позднее и причем без пересборки программы.

Требования к библиотеке все теже:

• Кроссплатформенность;
• Минимум зависимостей;
• Скорость чтения;
• Простой синтаксис;

Пример конфига

{
    "objects":
    [
        {
            "id": "object1",
            "events":
            {
                "event1":{
                    "give": {"object2": 4}
                },
            }
        },
        {
            "id": "object2",
            "events":
            {
                "event2":{
                    "give": {"object1": 3}
                },
            },
            {
            "id": "object3",
            "events":
            {
                "event3":{
                    "give": {"object3": 4}
                },
            }
        },

Первая и самая простая идея которая напрашивается это:

    std::map<std::string,script> events;

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

Вторая идея парсить этот конфиг в 2 прохода тогда на 2-м проходе object1, object2, object3 будут уже известны и можно будет записать на них прямо указатели или ссылки. Но если зависимости еще более сложные то такой подход может и не сработать.

Я предлагаю способ позволяющий существенно сократить runtime издержки подобных конструкций

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

"type":
[
	{
		"id": 1,
		"type": "one",
	},
	{
		"id": 2,
		"type": "two",
	},
	{
		"id": 6,
		"type": "three",
	}
]

Но в тоже время в кодe хочется использовать структуры типа:

enum Type
{
	one,
	two,
	three
};

Далее в теле статьи будут приведены несколько вариантов решения.