Groovy Testdrive

Рубрика: Development, Groovy | 12 May 2008, 12:18 | juriy

Начитавшись вдоволь книг и статей про Groovy мы решили опробовать этот инструмент на практике, чтобы получить о нем более полное представление. Ведь читая книги, создается образ “великого и всемогущего Groovy”. Так это или нет мы решили выяснить при помощи небольшого тест-драйва. Эта заметка – небольшой отчет о том, что у нас получилось. Команда состояла из авторов этого блога – Войтюка Вадима и Буры Юрия.
Когда в заметке встречаются рассуждения от первого лица – имеется в виду автор заметки (Юрий)
Начали мы с выбора проекта: хотелось написать что-то достаточно интересное, наглядное и разносторонее, поэтому мы остановились на простой многопользовательской игре. Первая мысль была – написать сетевой биллиард, но мы быстро поняли, что большая часть работы это физика движения шариков. Так, потратив большее количество времени на реализацию физ. движка мы, в лучшем случае, получим модель движения шайб с идеальными бортами.
Остановились на клоне всеми любимой игры Battle City. Не ставя перед собой слишком больших целей (совместного времени у нас было всего-то 5 часов) мы условились добиться синхронного движения танка на двух компьютерах.

Шаг 1. Setup.
Пол часа ушло на то, чтобы организовать сеть, создать SVN репозиторий, скачать нужные плагины, настроить пустой Groovy проект и съесть по куску пиццы.

Шаг 2. Начало разработки.
Тут мы немного смухлевали: TCP/IP слой писать на Groovy “с нуля” мы не стали. Я аккуратно вырезал пол-дюжины классов из другого проекта, устранил зависимости и протестировал “связь”. На реализацию NIO TCP/IP echo-сервера ушло около 20 минут.
Тем временем Вадим начал писать первый код на Groovy – Login Screen и логику “входа” на сервер. В качестве “протокола” мы использовали JSON. Он отлично интегрируется с Groovy и очень нагляден при отладке. Еще через час мы получили процедуру логина.

Шаг 3. Реализация GUI клиента.
После перерыва мы приступили к основному шагу – GUI клиента. Тут вся логика писалась только на Groovy. Мы скачали бесплатный Spritelib и получили милый набор анимированных танков и довольно большой набор спрайтов для фона. Остаток вечера ушел на то, чтобы “задвигать” танк.

Выводы первого дня.
Groovy довольно мощный инструмент, но пользоваться им нужно весьма и весьма осторожно. “Динамизм” дорого стоит – статический анализ кода становится бесполезным, а пресловутый Duck Typing сводит на нет большую часть преимуществ IDE (к примету, рефакторинг “переименовать поле” становится весьма опасным).

В то же время, писать код очень приятно: Signal to Noise ratio, которым хвастают поклонники Groovy, не пустые слова. Это особенно заметно, когда переписываешь код с Groovy на Java. Если сначала просто скопировать код в Java класс, а потом править его, чтобы он скомпилился, понимаешь, что все что ты делаешь, отнюдь не добавляет коду больше смысла и читабельности.

Шансов, что написанный код заработает с первого раза больше при разработке на Java, чем на Groovy – часть ошибок отлавливает среда, еще до запуска. Возможно, это дело привычки, ведь на Groovy я писал только несколько часов.

Немного о поддержке в различных IDE. Я начал писать код в Eclipse, но затем быстро переключился на Idea – поддержка Groovy там значительно более качественная. Ctrl+Space работает лучше чем в Eclipse, поиск потенциальных проблем правильнее. Кроме того, была ситуация, когда Groovy код компилировался из Idea и из командной строки, а Eclipse упорно показывал ошибку.

К концу первого вечера мы получили приложение, которое умело “входить” на сервер и двигать одну картинку танка (без анимации), отчего создавалось впечатление, что это не танк, а звездолет из Space Invaders.

Дальше работа проходила удаленно.
За второй вечер появились анимации и простой редактор карт. За третий вечер, клиенты начали передавать данные на сервер и отображать друг друга.

На этом запланированный объем работ мы завершили, а результатом исследования стала вот эта заметка.

P.S. При тестировании через интернет оказалось, что протокол TCP/IP непригоден для Real-Time игрушек вроде этой. Еще пару вечеров ушло на то, чтобы написать UDP сервер и перевести игру на UDP. Даже при тестировании на Dial-Up + GPRS (один компьютер подключен через Dial-Up, второй через GPRS) “рывки” хоть довольно заметны, но терпимы (мы не реализовывали никаких алгоритмов для компенсации рывков). При должном внимании и от этих неприятных эффектов можно будет избавиться (ну “почти” избавиться). При работе по локальной сети танки двигаются отлично.

Сейчас проект продвигается в весьма “сонном” режиме. Мне интересно, как добиться ощущения “плавности” и “синхронности” при игре через Internet. Как только будут свежие новости, обязательно выложу.

Комментариев: 5

5 Responses to “Groovy Testdrive”

Комментарии:

  1. Farcaller

    > Пол часа ушло на то, чтобы организовать сеть, создать SVN репозиторий, скачать нужные плагины, настроить пустой Groovy проект и съесть по куску пиццы.

    Да, люди не меняются :)

  2. Farcaller

    а спрайт танка знакомый, мой любимый для тестирования спрайтов вообще :)

  3. juriy

    Ты вот лучше подскажи, как реализовать Server Side lag compensation правильно и с минимальными усилиями. Вы же писали сетевую игрушку, помнится?

  4. Farcaller

    UDP – это must have. А дальше я простой интерполяцией аппроксимировал.

  5. Alx

    а если отрубить там всякие алгоритмы Найгла и глубже поковыряться в сокетах?

Leave a Reply