Мы смогли портировать игру только благодаря тестам. Так как проверить насколько правильно играет ИИ невозможно. В итоге мы сгенерили десятки тысяч раскладов и разыграли их на разных конвенциях и разными игроками используя оригинальную версию, потом сделали аналогичный шаг на Android версии.
Если у кого-то есть желание портировать игру преферанс Марьяж на винду — пишите. На данный момент игра успешно реализована для Android (native) + iOS (Unity).
в Британии нужно покупать лицензию на просмотр ТВ. Она стоит около £150 но если у вас чернобелый телик (шутка, да), то всеравно надо платить, но около £50.
Опять же, бизнес бизнесу рознь. Тот же клиент для онлайн банкинга должен выглядеть супер и быть понятным пользователю устройства. Можно, к примеру, написать кроссплатформ клиент, но клиентам это не понравится. В этом случае лучше написать два отдельных приложения, чтобы клиенты не разбежались.
Изучил Ваш блог и нашел 2 весьма интересных поста.
Первый пост — про разницу в реализации модальных форм на десктопе и мобильных девайсах. Да, в Android при запуске каждого окна старое не ожидает, пока новое закроется. Но ведь и колбеки не используются, потому что Android может в любой момент закрыть предыдущие окна, даже если они ожидают результата от других окон. Все компоненты действительно разделены и при необходимости будут убираться из памяти. В случае же Delphi в памяти будут висеть все предыдущие окна, так как они получают результаты в виде колбека, в котором могут модифицироваться элементы окна, где этот колбек был создан. Если уж стандартное поведение Андроида не используется, не проще было бы в собственной графической песочнице эмулировать привычное дельфистам поведение? Не говоря уже, что так лучше для кроссплатформенности.
Второй пост — про то что линии с одинаковой толщиной рисуются в Delphi по разному. В нашем Преферансе достаточно серьезно используется Canvas из Android SDK и такая проблема неведома. Координаты и размеры линий задается в числах с плавающей точкой и выглядят на экране сглажено и одинаково. Можете посмотреть на скриншоты пули в Android-версии преферанса. С градиентами и изогнутыми линиями. Мне страшно представить, каких бы усилий стоило бы нарисовать такое в Delphi.
Возникает вопрос — а не проще ли использовать нативный и предсказуемый инструмент, чем искать, как обходить баги вот в таком вот «кроссплатформенном»? Я уж не представляю, что будет, когда придется искать какую-то платформозависимую багу.
Еще вопрос, почему такой довольно взрослой и недешевой среде для каждой новой версии требуются патчи от некоего Andreas Hausladen? Неужели в такой бизнес-ориентированной компании как Embarcadero не могут нанять квалифицированный QA отдел и программистов, которые имея полный исходный код фиксили бы те баги, которые один скромный программист фиксит, имея лишь дизассемблер?
Кстати, по блогам и форумам пишут, что на FireMonkey нету контрола для отображения HTML. Врут? В Android и iOS SDK такие есть.
Я не считаю что заблуждаются, более того я всецело за кроссплатформ там где это можно. Просто опять же имхо, есть смысл сделать логику на сервере, а клиенту дать нативный интерфейс, к которому он привык.
Да и Преферанс затянул намного больше, я только указал сумму, в которую обошлось портирование логики. Самое интересное — это отладка на реальном железе.
Если надо писать хорошее приложение на маркет, то надо делать две отдельные версии для IOS и Android, если писать игру, то можно на юнити написать кросплатформ.
Написать на Делфи, теоретически можно что то с кнопочками для внутреннего пользования, владельцы айфонов на такое не клюнут.
В путешествии при открытии нового города выставляется минимальное возможное для этого города длина пули, в учебке должно все сохранятся. Мы посмотрим и если что не так — обязательно исправим. Спасибо!
itunes.apple.com/gb/app/preferans/id733924922?mt=8
Первый пост — про разницу в реализации модальных форм на десктопе и мобильных девайсах. Да, в Android при запуске каждого окна старое не ожидает, пока новое закроется. Но ведь и колбеки не используются, потому что Android может в любой момент закрыть предыдущие окна, даже если они ожидают результата от других окон. Все компоненты действительно разделены и при необходимости будут убираться из памяти. В случае же Delphi в памяти будут висеть все предыдущие окна, так как они получают результаты в виде колбека, в котором могут модифицироваться элементы окна, где этот колбек был создан. Если уж стандартное поведение Андроида не используется, не проще было бы в собственной графической песочнице эмулировать привычное дельфистам поведение? Не говоря уже, что так лучше для кроссплатформенности.
Второй пост — про то что линии с одинаковой толщиной рисуются в Delphi по разному. В нашем Преферансе достаточно серьезно используется Canvas из Android SDK и такая проблема неведома. Координаты и размеры линий задается в числах с плавающей точкой и выглядят на экране сглажено и одинаково. Можете посмотреть на скриншоты пули в Android-версии преферанса. С градиентами и изогнутыми линиями. Мне страшно представить, каких бы усилий стоило бы нарисовать такое в Delphi.
Возникает вопрос — а не проще ли использовать нативный и предсказуемый инструмент, чем искать, как обходить баги вот в таком вот «кроссплатформенном»? Я уж не представляю, что будет, когда придется искать какую-то платформозависимую багу.
Еще вопрос, почему такой довольно взрослой и недешевой среде для каждой новой версии требуются патчи от некоего Andreas Hausladen? Неужели в такой бизнес-ориентированной компании как Embarcadero не могут нанять квалифицированный QA отдел и программистов, которые имея полный исходный код фиксили бы те баги, которые один скромный программист фиксит, имея лишь дизассемблер?
Кстати, по блогам и форумам пишут, что на FireMonkey нету контрола для отображения HTML. Врут? В Android и iOS SDK такие есть.
Написать на Делфи, теоретически можно что то с кнопочками для внутреннего пользования, владельцы айфонов на такое не клюнут.