Oxoron

Идешь на json2sharp.com, там вбиваешь текст из своего файла.
Тыкаешь Generate.

Получаешь набор классов:

public class GameResultSetings
{
    public int TargetPoint { get; set; }
}

public class GameLevel
{
    public int ID { get; set; }
    public string Name { get; set; }
    public int Rows { get; set; }
    public int Cols { get; set; }
    public List<int> TilesLayout { get; set; }
    public GameResultSetings GameResultSetings { get; set; }
}

public class RootObject
{
    public List<GameLevel> GameLevels { get; set; }
}

Потом снова глядишь ответы тут, выдираешь код

internal static class Serializer
    {
        internal static void Serialize<T>(this T arg, string fileName)
        {
            string res = JsonConvert.SerializeObject(arg, Formatting.Indented);
            File.WriteAllText(fileName,res);
        }

        internal static T Deserialize<T>(string fileName)
        {
            string json = File.ReadAllText(fileName);
            T res = JsonConvert.DeserializeObject<T>(json);
            return res;
        }
    }

internal можешь поменять на public.

Там где тебе нужны данные из файла прописываешь

var yourFileFullPath = ...; // Здесь путь к твоему файлу
var gameLevels = Serializer.Deserialize<RootObject>(yourFileFullPath).GameLevels;

В переменной gameLevels у тебя хранится список уровней (List<GameLevel>), используй его с умом. Удачи.

Upd1. Не забудь подключить библиотеку Newtonsoft.json. Как это сделать в Unity - не в курсе, погугли или еще вопрос на тостере задай. Но лучше сначала загугли.

Нельзя выравнивать объекты по одному смещению. Структуры можно.
Попробуй буферы фиксированного размера:
public fixed byte Test[256]

Тут возникает вопрос: зачем 2 сервера систем контроля версий? Путаница же будет.

Если есть желание просто перенести репу с BitBucket на TFS - создайте командный проект, Git в качестве контроля версий, в свежесозданный локальный репозиторий закиньте уже существующий проект, первый коммит закинет репу в ТФС.

Попросите у ТФС список файлов в Pending Changes, определите его длину.
Пример. Если нужно, можете код загнать в PS скрипт.

Ответ от поддержки хабра:

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

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

---
Служба поддержки «Хабрахабра»

Проблема: недостаток времени.
Проблема: ухудшение здоровья. Напрямую вытекает из первой (в данном случае).

Цель: взять знаний по математике по максимуму. (ИТ потом сам догонишь, раз для тебя это проще. Даже полгода это не проблема). Вывод: забиваешь на ИТ-предметы. Изучаешь ровно настолько, чтоб пропустили в следующий семестр. Матан грызешь дальше, в освободившееся от ИТ время спишь. Побольше спрашиваешь у однокурсников, у всех. Один-два смогут обеспечить тебе прорыв, относительный.
На лекции ходить обязательно, но через раз. Наблюдай, что эффективнее. Через месяц будешь знать, ходить или не ходить.
Обязательно высыпаться. Обязательны прогулки. Или велосипед. Или плавание. Упражнения для глаз, раз в час.
То, что не понимаешь половины - это нормально. Большинство не понимает, просто привыкают. Рекомендую почитать книги Дмитрия Письменного. Минимум доказательств, много примеров. Думаю, на контрасте Письменного и классических учебников сможешь что-нибудь понять.
Еще вариант: пытайся понять, зачем доказывают теоремы. Трать на это час в день. Выбираешь лемму\теорему и задаешь себе вопрос: для чего её доказывают? Для какого док-ва она нужна? Для какой задачи?
Еще вариант: готовься не к прошедшим лекциям, а к будущим. То есть, если идешь на лекцию - прочитай её материал предварительно. На лекции ты возможно не успеваешь что-то понять, и буксуешь из-за этого. При предварительной подготовке некоторые вещи будут уже понятны, и сможешь поинтересоваться у лектора о действительно непонятных деталях. Готовься к такому скачку. В пятницу хорошо выспись, в выходные сосредоточься на изучаемом предмете.

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

P.S. Стать профи за год в ИТ - это тоже нелегко.

Запрос в гугл "Не удается найти точку входа c#"
forum.sources.ru/index.php?showtopic=295689
www.programmersforum.ru/showthread.php?t=280832
Попробуй оба решения, посмотри линки в ответе по второму адресу.

Смотри, для нормальных занятий наукой нужны несколько вещей.
1. Горящие глаза. Это есть у многих неофитов.
2. Усидчивость, настойчивость, упорство. Важно понять: многие вещи наскоком не решаются, а наука полна рутины. Написать статью в научный журнал, диссертацию (без диссертации вращаться в этом котле КРАЙНЕ неудобно), описание нового робота\датчика\алгоритма - после непосредственно размышлений\экспериментов этим заниматься скучно.
3. Минимальная пригодность к бумажной работе. Бумаг, не связанных с наукой напрямую, будет много.
4. Время\деньги.
5. Коллектив. Если в твоем ВУЗе нет нормальной кафедры - науку двигать будет тяжело. Желательно наличие одного профессора "в теме", и кого-нибудь из "молодежи", кто серьезно работает по спецухе. С этими людьми еще нужно будет отыскать контакт - сложности маловероятны, но, все-таки, возможны.

Как это все развивать-тренировать.
1. Никак. Либо есть, либо нет.
2. Изучай гуманитарные дисциплины по лекциям. Хотя бы одну-две. Тщательно записывай все лекции, дополнительно изучай их дома, делай доклады. В идеале выбирай ту дисциплину, которая не нравится. Во-первых, разберешься в теме (в это трудно поверить, но среди всех моих гуманитарных дисциплин, в итоге не нашлось ни одной бесполезной), во-вторых, привыкнешь делать неинтересную работу.
3. Стань старостой, активной участвуй в профкоме на какой-либо секции, работай секретарем на кафедре\лаборатории\деканате. Староста - самый простой вариант: меньше будут донимать с учебой, напряг минимальный. Профком - идеальный вариант: много знакомств, начнешь понимать, что такое бумаги, зачем их пишут, когда их нужно писать, когда можно не писать, кому нужно сдавать и зачем. Приличный опыт общения. Секретарь - вариант, пожалуй, худший. Бумаг много, да, на времени и нервов отнимает слишком много.
4. Время. Оно же деньги. Если нет возможности устроиться по специальности на минимально-необходимые деньги (квартира\питание\стандартные_расходы) - даже не дергайся. Работать на несвязанной работе и двигать науку тяжело. С появлением семьи\подружки\друга - крайне тяжело. В принципе, если есть пассивный доход - все проще.
5. Коллектив придется искать самостоятельно.

Удачи.

Базовый ответ: значение переменной хранится в стеке. Есть программа, ей при запуска ОС выдает кусок памяти. В этом куске есть стек переменных, там и хранится эта глобалка.

Любая переменная скрывает собой указатель. Грубо говоря, ты пишешь int a=2, что во время выполнения трансформируется в mov 00ff00aa, 2. Прога во время работы попросит у ОС кусок памяти, и в нем жестко выделит место под примитив. Везде, где в исходниках стоит переменная 'a', в бинарниках будет выделенный адрес (компилятор постарается).

Плюс, есть сильная зависимость от языка. Если используется Java, примитив может оказаться в куче (сам не джавист, но в .NET подобные ситуации возможны). Там, по идее, точное расположение в памяти зависит от реализации сборщика. Но тут нужен джавист-спец.

Ищете все файлы с расширением .cs.
Там банальным Replace заменяете "String.Format" на нужный метод. При необходимости, добавляете "using specialNamespace;" в начало файла.
Одноразовая утила пишется либо на PS, либо на самом шарпе.

Читай про закон Деметры. Если в проекте куча вызовов типа

SomeClass.SomeField.SomeMethodWhichReturnsOtherObject().AnyOtherField = 15;

или
a.b.c().d = e.f.h().g; - вполне возможно, в архитектуре перебор с SR.
Хотя возможна ситуация, когда архитектор пытается подготовиться ко всем возможным изменениям; SR в таком случае лишь следствие (одно из), и разумные аргументы будут лежать вне SOLID принципов.

Тут рецензия хорошей книги "Art of Unit Testing", плюс, несколько ссылок на доп-материалы. Книга не только расписывает плюсы-минусы тестов, но и объясняет, как лучше внедрять TDD в команды\проекты.