Платформер Поделиться Опции

[Грустный]

Разработку предлагаю разделить на:
Графика - перегнать в png, склеить спрайты.
Совместимость с MIDP 1.0 - Sprite и TiledLayer.
Физика – вектора, кинематика.
Поведенческие классы для «персонажей» - отрисовка, анимация, перемещение, столкновение.
Движок – игровой цикл, реакция на клавиши.
Меню.
Тестирование.

Порядок работы над проектом:
Все выносят идеи по каждому разделу.
Если есть готовые наработки – предлагать.
Каждым разделом занимается один-два человека – потом выкладывают результаты на общее обсуждение.
Если есть вопросы – спрашивать у всех, и все помогают .
В каждом разделе – сделать базовые наброски с минимально необходимым функционалом с последующим наращиванием.
По запросу разработчиков из других тем добавляют функционал.

[Грустный]

Следующий проект будет:
Платформенная игра J-Rio.
Пример реализации: Java cooperation

Естьжелающие делать вместе?

Сообщение отредактировал Грустный - 22.10.2006, 22:28

[Stranger]

Грустный, можно будет попробовать :)

[dmtrlbdv]

Я желающий , хотелось-бы попробовать поработать в комманде , но и бесполезным прицепом быть тоже не хотелось-бы , ибо опыт пока маловат , но если возьмёте , постараюсь быть максимально полезен :)

[Грустный]

Stranger, dmtrlbdv
На досуге подумал:
т.к. в JME нет масштабирования картинок (по крайней мере я не знаю :) ), то вижу несколько способов сделать игру под разные разрешения экрана:
1) делать под каждое разрешение свою версию
2) реализовать масштабирование
3) сделать картинки разных размеров и при запуске подгружать нужную
4) урезать игровое поле
5) совместить 3 и 4 варианты
6) генерить картинки в программе (как я это делал в тетрисе)
Есть ли другие варианты?

Ещё один вопрос: надо ли поддерживать совместимость с MIDP 1.0?

Надо определиться, как лучше сделать.

[FMC]

Грустный,
По поводу совместимости с разными разрешениями, самое простое и имхо правильное решение - отказаться от всей рисованной графики и рисовать все по средствам явы (см. в мою подпись, в совей игре я так и сделал)... ну просто по-моему не очень удобно рисовать картинки под разные разрешения, да и на весе это все скажется отрицательно. По поводу поддержки MIDP 1.0, думаю, стоит сделать... и тогда игра будет на самом деле мультиплатформенная :)

[Stranger]

Грустный,
из всех предложенных тобой вариантов реально в мире работает только 1. Многие пытались/пытаются создать универсальную версию под все девайсы...ну не получается, и не получится... моё имхо
Мы сейчас работаем как раз с такой системой, которой даешь на вход графику под все телефоны(все разрешения), исходники(предельно напичканные параметрами) + список констанст, а на выходе(в идеале) получаешь готовое приложение под нужное устройство. На практике получается так, что мы портируем игру уже месяца 3-4, хотя если бы все делали сами, то справились бы за срок наверняка меньший раза в два...
По поводу мидп 1.0 устройств. Эти модели присутствуют в списке портингов. И еще будут там присутствовать. Зачастую, эти устройства требуют отдельных версий. Так, например, существуют такие "замечательные" телефоны, как Сонька T610, Nokia 6100, 7210... у которых маленький хип, ограничение на размер джара...Приходиться выкидывать лишнюю графику, звуки, менять код.
Но это все нужно делать, поскольку проект то коммерческий.
В нашем случае планируется ведь создание игры не в этих целях, насколько я понимаю?
Что касается масштабирования, то почитай тут Масштабирование в J2ME

P.S.
В качестве маленького отступления....
Обычно игры стараются делать так, что минимизировать затраты времени и усилий при портировании(потому ленивые :)). Поэтому разрабатывают движок игры так, чтобы он работал и в таком разрешении и в другом одинаково(в плане функциональности), но по-разному(возможно) - в плане видимости на экране...Вот так...

[dmtrlbdv]

По поводу рисования средствами JAVA - IMHO для платформеров критична эффектность картинки , чего не добиться , если не исользовать картинки , нарисованные заранее. Я за рисованные.
По поводу портов или универсальности - опять всё упирается в то , что это платформер. Например у нас для шахмат и шашек ( www.wapportal.ru ) используется 3 набора графики , которые выводятся в зависимости от размера экрана , НО графики не так много , поэтому это не критично (размер остаётся приемлимым). Если графику масштабировать , то реально хорошо она будет выглядеть на референсном телефоне , а в остальных случаях пользователи будут чувствовать себя ущербно. Можно выбрать один размер и начать делать под него , но с оглядкой на то , что в будущем размер будет меняться (т.е. так , как описал Stranger в P.S ). А потом уже править графику. Не обязательно делать под каждое разрешение - выбрать несколько самых распространённых (т.е. например 128x128 , .... , ...... , 240x320).
Высказал своё мнение , не претендующее на истину :)

[FMC]

Просто для сравнения, до того, как я убрал всю рисованную графику из см. подпись, вес был неслабый... теперь же все это весит 13кб (а если учесть мой жутко кривой код, то все это могло бы весить втрое меньше) :)

[Грустный]

Тогда надо определиться с первоначальным разрешением.
На моём V360 максимум, что можно получить - 176х204.
(Если кто знает, как выжать 176х220 - буду благодарен. У знакомого на SE К700 в FullScreenMode - 176х220.)
Есть ещё V180 (128х116) - но на нём тестировать не удобно.
Предлагаю ширину 176 (с "равнением" на 128).

Работая над тетрисом, столкнулся с проблемой перевода приложения в фоновый режим:
- на "раскладушке" при закрытии "флипа" вызывается MIDlet.pauseApp() и приложение "уходит в фон"
- на К700 есть кнопка "возврат", которая в некоторых приложениях даёт такой же эффект, но по ней вызывается MIDlet.destroyApp(), а MIDlet.pauseApp() - только при входящем звонке

Т.к. на телефонах играют (по крайней мере я) - когда есть свободная минутка, то очень хотелось бы возможность перевести игру в паузу, чтобы потом начать с того же места. (Если просто остановить и написать "Пауза", то, по крайней мере на К700, быстро садится аккумулятор, да и неудобно - ни позвонить, ни записную книжку посмотреть).

[Грустный]

Что может понадобиться из MIDP2.0, чего нет в MIDP1.0:
- из GameCanvas: flushGraphics(), getKeyStates() - если без второго можно обойтись :) , то без двойной буферизации нет
- Sprite
- TiledLayer

Если делать разные версии для MIDP2.0 и MIDP1.0, тогда эти классы придётся эмулировать для MIDP1.0.

Использовать Float нет смысла, так как это накладывает ещё большие ограничения на совместимость (Float только с CLDC 1.1) и производительность.

По поводу getKeyStates():
я хотел отказаться от этого в тетрисе - обрабатывая keyRepeated(), но в V180 keyRepeated() не работает :( .