Kotlin и стоимость разработки игры (+ немного оффтопика)

[TerraV]

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

[ijsgaus]

BehaviorSubject даст то же поведение за бесплатно, только перегрузкой сеттера

[TerraV]

Спасибо огромное за подсказку, не знал. Это вообще отличная иллюстрация к тому, что мы только думаем что программируем на языке/фреймворке, а на деле используем только часть (порой малую) а на остальное городим велосипеды. Честно обещаю исправиться по крайней мере с BehaviorSubject :)

[Legion21]

Спасибо за статью, а не думали использовать unity для разработки игры? Я думаю, что так можно еще раза в 2 снизить цену разработки

[TerraV]

Рассматривал этот вариант, но у Unity есть несколько недостатков которые делают эту платформу мне не интересной.

• Узкая специализация. Навыки, полученные при разработке в Unity можно продать только фирмам, занимающимся разработкой игр на Unity. В случае Java/Kotlin + LibGDX я успешно использовал полученные знания для собеседований. В данный момент у меня оффер на релокацию в Прагу и в Лимассол (Кипр).
• Unity дает очень большой оверхед в плане потребления ресурсов. К примеру запуск подавляющего большинства приложений на юнити это 5-10 секунд. Мое приложение запускается вместе с прогрузкой ресурсов около 1.5-2 секунд. Ну и каждая вторая игра на Unity превращает телефон в обогреватель. Может из-за плохой оптимизации. Не знаю.

[sargeras55]

Очень странная статья и вопрос стоимости разработки почти не раскрыли, и на Kotlin написали «Hello world», еще и не в лучшем виде.

[TerraV]

Да, я понимаю что статья странная. На то она и первая чтобы делать ошибки и учиться. Могли бы вы сформулировать вопрос чтобы я его раскрыл подробно?

[jericho_code]

«Kotlin выполняется на jvm 6» — уже можно и на 8, а за статью спасибо, как раз начинаю свой проект, некоторые мысли из «мотивации» были кстати.

[TerraV]

Обычно требование JVM 6 возникает не от хорошей жизни. Это могут быть старые веб сервера или поддержка старых версий Android. К примеру Java 8 появилась только в IBM WebSphere 8.5.5.9. А многим беднягам приходится до сих пор работать с WebSphere 7, это та самая JVM 6 и есть. И получить вкусняшки Kotlin'a на мой взгляд огромный плюс.

В зависимости от Target JVM (а котлин умеет и в 6 и как вы заметили в 8) меняется байткод. Что как я понимаю сказывается в первую очередь на производительности.

[jericho_code]

Мой комментарий — это просто небольшое уточнение, чтобы не было лишних нападок в сторону языка. Уже не раз видел как Kotlin в минус ставят jvm 6)

[mr-garrick]

Что-то последнее время стали много везде говорить про Kotlin, даже подозрительно как-то…

[vvgladoun]

Действительно, с чего бы это. Вроде ничего не произошло, кроме признания языка гуглом и оффициальной поддержке как first-class citizen-а, начиная с Android Studio 3.0.

[mezastel]

.filter { aboveLimit -> aboveLimit == true }

это какой-то ад, разве нельзя написать

.filter{it}

?

[TerraV]

Можно, конечно можно. Просто статья писалась для людей не владеющими kotlin. И использование явных параметров обусловлено исключительно лучшей читаемость. Просто представьте этот же фрагмент кода но с it. Там три раза меняется контекст этого ключевого слова.

[TerraV]

я больше не буду комментировать с телефона :)

cars.forEach { 
        val car = it
        car.rxSpeed
                   .map { it > 60 } // преобразует double скорость в boolean скоростьПревышена
                   .distinctUntilChanged()
                   .filter { it }
                   .subscribe { writeTicket(car) }
       }

[vagran]

Тем не менее модификаторы final смотрятся крайне неуместно и визуально засоряют программу. Это приводит к тому, что final используется в Java гораздо реже чем следовало бы.

Не большой специалист по Java, но кажется где-то встречал понятие effectively final. Разве современный компилятор не в состоянии сам определить, что переменная не меняется и является по сути константой со ваеми вытекающими оптимизациями?

[TerraV]

https://stackoverflow.com/questions/20938095/difference-between-final-and-effectively-final
В приведенном случае переменная никак не может быть effective final, т.к. она постоянно пересчитывается. В начале операции sum = 0, но для каждого элемента больше нуля происходит инкремент на величину элемента.

Плюс еще один момент: если вы пишете final String — вы можете определить значение или немедленно, или в конструкторе. Любая попытка переопределить будет кидать compile error. В случае effective final ну станет переменная не-финальной. Никаких предупреждений и тем более ошибок не возникнет. А если это проект да с индусами в команде, вы никогда не можете знать откуда ваше поле изменят. Да и наши порой жгут. Привет, Юра!

[vagran]

Пример с sum, честно говоря, пропустил (чукча не читатель). Сейчас посмотрел, но ведь он не корректен. Корректный эквивалент на java как-то так:

int sum = data.stream().filter(value -> value > 0).mapToInt(Integer::intValue).sum();

И тут sum ничто не мешает быть final.

[TerraV]

Да, вы правы. Для меня было не очевидно что Integer нужно мапить в intValue. Замечание принято. Правда не могу устоять против приведения аналога на котлине :) Но это уже конкретная вкусовщина и на стоимость разработки/поддержки почти не влияет.

        val data: List<Int> = ArrayList()
        var sum = 0
        data.filter { it > 0 }.forEach { sum += it }

[samally]

вот так суммировать будет лаконичнее и эффективнее:

val data = ArrayList<Int>()
val sum = data.filter { it > 0 }.sum()

Изменяемая переменная захваченная в функцию в котлине оборачивается во враппер – объект, например, IntRef. И так пока что даже для заинлайненных анонимок (это вроде оптимизируют со временем).

[vagran]

del