Доброанон в /b сильно помог протолкнуть проект вперёд. Приведу сюда все полезные сведения.

1.
По поводу увеличения количества левелпаков в игре (и в меню, соответственно).
Нужно внести изменения в файл a.class
Для этого декомпилировать его в файл a.java с помощью софта IntelliJ IDEA (powered by Fernflower decompiler).
Вот декомпилированный таким образом код:
http://pastebin.com/uBLRjwj8

Или с помощью софта JD-GUI
Вот декомпилированный таким образом код:
http://pastebin.com/dHeazw0U

Далее внести изменения, после скомпилировать с помощью софта javac.
При этом, кроме файла a.java

>еще подсунуть зависимости для этого jar-ника: kemulator.jar от твоего эмулятора должен подойти + нужно дизассемблировать еще и Bobby.class (скорее всего) и подсовывать компилятору

Другой вариант - внести изменения напрямую в файл a.class с помощью софта JBytedit

Что изменять? В jar файле есть 4 файла левелпаков 01.dat, 02.dat, 03.dat, 04.dat. Клонируем один из файлов в 05.dat и закидываем в jar.
Но нужно, чтобы игра хотела видеть больше четырёх левелпаков (пять в данном примере)
В коде файла a.java есть нужные нам моменты:

>try

{
InputStream localInputStream = getClass().getResourceAsStream((paramInt < 10 ? "0" : "") + paramInt + ".dat");
DataInputStream localDataInputStream = new DataInputStream(localInputStream);
localDataInputStream.readShort();
this.cu = localDataInputStream.readByte();
for (int i2 = 0; i2 <= i1; i2++)
{
this.cs = localDataInputStream.readUTF();
this.ct = localDataInputStream.readUTF();
}
localDataInputStream.close();
localDataInputStream = null;
}
catch (Exception localException)
{
c();
}
}
тут читается файл уровня (5111 строка), судя по всему их может быть 99

>private final void aa()

{
int i2 = 0;
for (int i1 = 1; i1 <= 4; i1++)
{
d(i1);
this.cv[i2] = this.cs;
this.cw[i2] = this.cu;
i2++;
}
}
Тут задаются количество левелпаков (5083 строка)
Сюда идет вызов от функции которая загружает файлы с именем 0<int>.dat

Но с четвёркой в строке i1 <= 4 не так просто (мало её поменять там пятёрку):

>В этом сорсе в куче мест это число заинлайнено, это же константа и явский байткод

>строки 202 и 203, редактировать так же как и в предыдущем случае (202 хранит названия левел паков, btw)

эта штука будет в одном из конструкторов класса a, там по имени уже найдешь поле

>долфин эмулирует под DirectX?

Да

Вообще надо определиться, клон какой игры мы делаем? BC5 или BC Forever.
BCF - это не переиздание, а ремейк.

BCF ремейк игры Bobby Carrot 5: Forever. Отличия от оригинала:
- высокое разрешение, добавлены эффекты, высокое качество звука
- добавлены сюжетные кат-сцены
- отсутствуют 4 левелпака (Memories, Easter Outing, Forest Castle, Farm2)
- добавлен новый финишный левелпак Finale
- добавлен третий бонусный уровень (с фотографом) в каждый левелпак (кроме первых шести)
- изменено расположение монет на некоторых уровнях
- изменены пользовательский интерфейс, локации выбора левелпака, поезда, магазина
- добавлены новые внутриигровые покупки
- уменьшена сложность игры

Изменения в правилах, повлёкшие к уменьшению сложности:
- на газонокосилке можно собирать монеты и морковь, заезжать на выход из уровня
- газонокосилка не скользит по льду
- в магазине доступна для покупки улучшенная газонокосилка (Red Lawnmower), на которой можно сбивать камни без ускорения
- в магазине доступен для покупки Cheat Blaster, который позволяет удалять морковь на уровне по 10 монет за штуку
- кролик во время скольжения на льду останавливается на моркови (в том числе и на лунках от уже собранной моркови)
- кролик после приземления на дельтаплане не делает шаг вперёд
- в бонусных уровнях увеличено число монет
- кролик бегает быстрее, газонокосилка ездит быстрее

Отличия iOS версии:
- присутствует только первые 2 мира Dreamland и Rainbow Valley (12 левелпаков)
- левелпак Surreal другой (основан на ориганальном левелпаке Surreal), в отличие от Wii версии, где этот левелпак основан на оригинальном левелпаке Fairyland
- отсутствуют обучающие уровни

>>402213
Начал писать интерфейс для главного меню, нужно было сделать что-бы при нажатии на старт, появлялась панелька с двумя кнопками выбором режима игры {Classicстандартные паки с картами, которые открываются по прохождению , Custom Паки сделанные пользователем или скачанные, вообщем пользовательские паки } После выбора типа игры, должна быть панелька с выбором конкретного пака, после выбора пака, панелька с выбором карты, ну и все, после уже писать контроллер игрока и запускать бегать, тестить, но как всегда не все так просто, казалась вроде что вся логика этих панелек уже реализована в редакторе карт ну панель загрузки/сохранения почти тоже самое что и должно быть в главном меню Я за час накинул почти весь код, скомпилировал билд и хуй, а сейчас я не тестирую проект в самой юнити, т.к. код заточен считывать различные бинарные файлы, карты,настройки и т.д, то есть если проверять в юнити он просто не найдет пути к файлам и не запустит нужный код, так как пути в проекте и в установленной игре разные, пользователь может установить игру куда угодно, поэтому приходиться после каждого добавления в проект компилировать билд и тестить в нем, следовательно у меня есть только дебаг ,ну и профайлер, только он нужен в конце, сейчас незачем. и о том что происходит под капотом я могу только догадываться, например файлы могут плодиться и куча разного говна, ну и вообщем я написал код который должен рисовать кнопки, а они не рисуются, расставляю в коде дебаг сообщения, по дебагу все работает , после нескольких часов последовательного дебага понимаю что кнопки рисуются, но где-то за пределами интерфейса, потом несколько часов не мог понять что за гавно ведь в редакторе тот-же код и кнопки выставляются в правильные векторы, а тут нет, сидел два часа и думал что за гавно, потом уже когда шел спать обдумывал проблемный участок кода, и понял что я долбоеб и проблема ровно в одной маленькой строчки, которую нужно просто переместить, суть такая.
Я инициализирую болванку кнопки, заполняю данными которые читаю из файла сложность коллекции, имя и т.д и устанавливаю вектор позиции относительно анкерной точки, добавляя кнопку к родительскому трансформу, но из-за того что я ставил вектор позиции до того как присоединял кнопку к родителю, анкерная точка рассчитывалась относительно экрана, а не родителя, из-за этого она рисовалась где-то в пизде. я тупо передвинул строчку кода, что-бы в начале кнопка добавлялась к родителю, а потом задавать ей позицию и проблема исчезла, лол.
Ну и пока думал о дизайне этого всего, решил использовать стандартный арт, на кнопке с выбором классического режима,теперь будет рандомная картинка с артом, о кнопке с пользовательскими паками еще не решил... и еще перекатился на Unity 5.6.1f1

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

>>497240
>>497537
Сначала запоздало исследовал дорожку.

Если отпустить кнопку направления сразу после захода на дорожку, то пробегаем 3 шага.
Если отпустить кнопку после 1 шага, то пробегаем 5 шагов
Если отпустить кнопку после 2 шага, то пробегаем 6 шагов
Если отпустить кнопку после 3 шага, то пробегаем 7 шагов

ИТОГО. По дефолту от "нулевой" позиции делается 3 шага. Либо (если держим кнопку), то +4 шага от позиции, где отпустили кнопку.

Кстати. Если заходить на дорожку с обратной стороны, то всё вышесказанное справедливо.

На 1 видео я захожу на дорожку прямо
0:13-0:16
Без нажатия

0:23-0:26
Отпустил на 1 шаге

0:37-0:40
Отпустил на 2 шаге

0:49-0:52
Отпустил на 3 шаге

На 2 видео я захожу на дорожку с обратной стороны
0:10-0:13
Без нажатия

0:14-0:17
Отпустил на 1 шаге

0:22-0:24
Отпустил на 2 шаге

0:27-0:29
Отпустил на 3 шаге

>>499163
Я тебя удивлю, но многие даже в простую архитектуру не могут, а тут как раз основная сложность в архитектуре, из-за большого кол-ва взаимодействий, считай каждый геймплейный элемент в степени взаимодействующих с ним элементов, приходиться продумывать все возможные события, это основная сложность, а что касается конкретно кувшинок, то тут может быть реальный ад, особенно если неправильно подойти к решению задачи, как я это делал в прототипе >>440726 и >>417404. Введу тебя в суть - игрок может наступать на кувшинки после чего те начинают плыть в направлении движения игрока пока все просто, вычисляем нормализованный вектор направления относительно игрока и кувшинки, и пускаем соопрограмму в которой их перемещаем в полученном векторе, попутно обновляя нужную информацию кувшинка может плыть только по воде, так же в игре есть волны, которые могут менять направление движения кувшинки, направление волн игрок может менять в любой момент кнопками уже сложней, а теперь добавляем сюда безумного пользователя с редактором, который может используя доступные ему геймплей элементы усложнить задачу кратно, например кувшинки могут столкнуться с другими кувшинками,но это столкновение может быть с кувшинкой плывущей со направлено или наоборот, к тому же кувшинка может пересчитать свой путь в любой момент, такие вычисления в динамической среде очень сложные и не тривиальные, простым A^{звездочка} не решишь, кувшинки должны не только вычислять путь себе, но так-же обмениваться информацией с другими, в то время как игрок неистово жмет на кнопки изменяя среду вычислений, вынуждая делать новые расчеты, в которые в любой момент может вклиниться другой геймплей элемент и все по новой, уже сложно Вообщем сложность в архитектуре и большом кол-ве взаимодействий, в плане геймплейного кода тут настоящая квинтэссенция, механик больше чем скажем в простой линейном FPS даже в ваших калл оф дути, где основной код это контроллер игрока, поиск путей A* и AI FSM, если по серьезней то GOAP делал в свое время и то и другое не КаллОффДути, могу гарантировать это я гарантирую это. Вообщем если брать механики по отдельности , то все просто и примитивно, но если это все собирать в целое , то трудности будут. А вообще сложности есть везде, даже если матч-3 писать для написаний которых бывает существует целый отдел из нескольких погромистов и студии их делают бывает годами, это повод задуматься. Можешь полистать эту доску, посмотреть на треды, и убедиться в том что сложности есть у каждого, просто пользователи видят интерфейсы, анимации, картинки, а разработчик видит сложные взаимодействия,алгоритмы, архитектуру и т.д. Твое непонимание связано я полагаю с этим.

>>499186

>Кувшинки считают путь на тайл вперед

Зачем?

Моё направление движения
dirx=0
diry=-1

Я нахожусь на клетке:
cell_x = 10;
cell_y = 2

Раньше у этой клетки было значение:
saved_tile_value_1 = вода.

if state == kuvshinka_states.thinking
{
Что там впереди?
var scan = tile_get_value(cell_x + dirx, cell_y + dir_y);

switch scan
{
case вода: state = kuvshinka_states.moving_to_next_tile; break;
case течение вниз: next_dir_y = -1; next_dir_x = 0; state = kuvshinka_states.moving_to_next_tile; break;
case течение вправо: next_dir_y = 0; next_dir_x = 1; state = kuvshinka_states.moving_to_next_tile; break;
case течение вверх: next_dir_y = 1; next_dir_x = 0; state = kuvshinka_states.moving_to_next_tile; break;
case течение влево: next_dir_y = 0; next_dir_x = -1; state = kuvshinka_states.moving_to_next_tile; break;
case тайл занят другой_кувшинкой: state = kuvshinka_states.waiting_for_obstacle_to_get_lost;
case мостик: state = kuvshinka_states.waiting_for_obstacle_to_get_lost; break;
case что-то ещё: state = kuvshinka_states.not_moving; break;
}

}

if state = kuvshinka_states.moving_to_next_tile
{
if !movement_init
{
movement_init = true;
saved_tile_value_2 = scan;
tile_set_value(cell_x + dirx, cell_y + dir_y, тайл занят другой_кувшинкой )

next_cell_x = cell_x + dirx;
next_cell_y = cell_y + dir_y
}

x += dirxvx;
y +=diryvy;

if (x div cell_size) == next_cell_x && (y div cell_size) == next_cell_y
{
state = kuvshinka_states.thinking
tile_set_value(cell_x - dirx, cell_y - dir_y, saved_tile_value_1 )
dirx = next_dir_x ;
diry = next_dir_y;
saved_tile_value_1 = saved_tile_value_2;
movement_init = false;
}

}

И вот это почти всё, что кувшинке нужно делать.