Денис Загаевский

Даже если исправить все синтаксические ошибки в коде, то всё равно выражение
arr[num - '0'] адресует область памяти перед массивом, а не сам массив, т.к. символ '0' имеет код 48.

Создаётся переменная типа unsigned short int, которая почти во всех современных компиляторах имеет размер 2 байта. Затем ей присваивается значение 1. В случае архитектуры Little Endian, единица запишется в младший байт переменной, а в случае Big Endian - в старший байт. Дальше именно это и проверяется - конструкция *((unsigned char *) &x) получает значение младшего байта переменной. Если там оказался ноль, значит архитектура Big Endian.

Код, делающий то же самое, но проверяющий старший байт:

#include <stdio.h>
unsigned short x = 1; /* 0x0001 */
int main(void)
{
  printf("%s\n", *((unsigned char *) &x + 1) == 0 ? "little-endian" : "big-endian");
  return 0;
}

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

Вот напиример функция из питона с более уместным использованием goto

static int
ast_type_init(PyObject *self, PyObject *args, PyObject *kw)
{
    Py_ssize_t i, numfields = 0;
    int res = -1;
    PyObject *key, *value, *fields;
    fields = _PyObject_GetAttrId((PyObject*)Py_TYPE(self), &PyId__fields);
    if (!fields)
        PyErr_Clear();
    if (fields) {
        numfields = PySequence_Size(fields);
        if (numfields == -1)
            goto cleanup;
    }

    res = 0; /* if no error occurs, this stays 0 to the end */
    if (numfields < PyTuple_GET_SIZE(args)) {
        PyErr_Format(PyExc_TypeError, "%.400s constructor takes at most "
                     "%zd positional argument%s",
                     Py_TYPE(self)->tp_name,
                     numfields, numfields == 1 ? "" : "s");
        res = -1;
        goto cleanup;
    }
    for (i = 0; i < PyTuple_GET_SIZE(args); i++) {
        /* cannot be reached when fields is NULL */
        PyObject *name = PySequence_GetItem(fields, i);
        if (!name) {
            res = -1;
            goto cleanup;
        }
        res = PyObject_SetAttr(self, name, PyTuple_GET_ITEM(args, i));
        Py_DECREF(name);
        if (res < 0)
            goto cleanup;
    }
    if (kw) {
        i = 0;  /* needed by PyDict_Next */
        while (PyDict_Next(kw, &i, &key, &value)) {
            res = PyObject_SetAttr(self, key, value);
            if (res < 0)
                goto cleanup;
        }
    }
  cleanup:
    Py_XDECREF(fields);
    return res;
}

Для больших игр неминуемо пишется свой инструментарий, потому что художникам надо быстро проверять, как смотрится арт в игре, геймдизайнерам править баланс, нарративщикам добавлять запятые в диалоги и так далее, а заставлять каждого компилять игру из C++-сорцов запрещено международной конвенцией по гуманному обращению с пленными и декларацией прав человека. Поэтому неизбежно будут какие-то тулзы, куда можно скормить png, mp3 или txt, подвигать ползунки и посмотреть, как это будет в игре.
Иногда из этого выходит вот Unity3D или UE, иногда TES Construction Set, иногда оно так и остается в недрах.

Disclaimer: я никогда не работал в геймдеве:)

public static class Integer implements MyRandom <java.lang.Integer> {
        private Random rand = new Random();

        public java.lang.Integer GetRandom() {
            return rand.nextInt(10);
        }
    }

Сделать вот так

Ну или переименовать свой класс из Integer во что-то другое

Странный вопрос!
Это приложение не Ваше, а Заказчика.
Вам за него заплатили деньги!
Поэтому ответ однозначен: разместите на аккаунте Заказчика.

UPD:
1. Вам необходимо было заранее договориться с Заказчиком о том, что Вы впишите себя в Credits/About внутри приложения, возможно оформить письменное соглашение на то, что заказчик имеет право использовать ваш продукт в любых целях, сохраняя информацию о Вашем авторстве в заранее утверждённом разделе приложения (Credits/About).
Теперь - можете попробовать сделать это сейчас, но заказчик Вам ничем не обязан, хотя авторство автоматом сохраняется за Вами.
2. Можете написать в гугл, чтобы он добавил поле автора отдельно. Возможно, они прислушаются и сделают это.

Это вообще разные вещи.
Нужно отличать изучение API, от изучения технологии. Если вы хотите выучить просто API, учите что угодно, ибо разницу заметите только, когда поймёте основы, базу.

OpenGL проектировался когда были другие архитектуры железа. Мультипроцессорность была только в теории, и считалась уделом суперкомпьютеров и ненужной для пользовательских ПК.
Можно привести аналогию: OpenGL == C++, Vulkan == асинхронный Assembler + hardware threads. Например, в C++ сейчас довольно много архитектурных косяков, которые пытаются решить новыми стандартами, объявляют какие вещи устаревшими, потому что они концептуально неверны и не подходят под современные реалии.
Но, при этом, вы можете всё то же самое написать на ассемблере, но нужно намного лучше понимать, как работает процессор и ОС, самому писать примитивы синхронизации, и т. п.

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

В итоге, я бы ответил так:

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

Если же вы пишете простые прикладные вещи, которым нужно показать какую-то графику, то учите OpenGL. Здесь вы учите только API, соглашаясь с уже готовым, слегка устаревшим, архитектурным дизайном.

Если хотите писать игры не мирового класса, то учите готовые движки, Unity или Unreal. Они уже поддерживают за вас Vulkan, продумали за вас API и архитектуру.