Клон соптвича.
Реализован странновато:
1) Меню вначале для красоты — все само запускается и все.
2) Управление дерганое какое-то — только две скорости самолета.
3) После столкновения с аэростатом самолет остается висеть в воздухе, об него можно дальше ударится.
4) Если полететь налево вначале, то самиолета видно не будет, но полет будет продолжаться.
5) Можно ли сесть на полосу? У меня не получилось.
6) Чего он меня Реталиком обзывает?
7) При выходе виснет через раз, занимая по 90 процентов процессора.
Можно сделать коммерческим. Но нужно довести до нормального вида.
Можно добавить поддержку мультиплеера.
Можно делать только для PC, а лучше, если исходник будет таким, что его можно будет откомпилировать для чего угодно, включая наладонники ( уж для WinCE-то это не сложно, но в принципе можно и для палма. ) Если сделаешь поддержку мультиплеера достаточно общо, а потом разберешься с голубыми зубами и красными глазами, и сможешь сделать так чтобы можно было на двух PDA-шках играть например в метро, то будет вообще супер, хотя не знаю насколько это реализуемо вообще. Кстати насколько?
Здравствуйте, Рома Мик, Вы писали:
РМ>Клон соптвича.
Ага, шаришь!
Объективный анализ также без труда обнаружит элементы Worms от Team17, а также еще несколько заимствований. Но дело в том, что я написал именно то (ну за исключением мелких моментов), во что хотелось поиграть. После Planers в Sopwitch играть неинтересно!
РМ>Реализован странновато: РМ>1) Меню вначале для красоты — все само запускается и все.
Угу, недоделка.
РМ>2) Управление дерганое какое-то — только две скорости самолета. РМ>3) После столкновения с аэростатом самолет остается висеть в воздухе, об него можно дальше ударится.
Это все вызвано слишком быстрым компьютером (см. пост в шареваре). Некоторые события (гравитация, ускорение полета, частота стрельбы) просчитываются с задержками в тактах процессора, а не тиках таймера, поэтому такое уродство. Кстати, хинт будущим геймописателям: не повторяйте этой старой ошибки. Вот скорость полета самолета у меня не зависит от частоты.
РМ>4) Если полететь налево вначале, то самиолета видно не будет, но полет будет продолжаться.
А что бы ты предложил?
1) раньше я "разбивал" самолет о край карты, как о стенку. Народ не понял.
2) У сопвича высокие горы по бокам были. Это выход, но довольно искусственный.
3) ну можно карту зациклить (наверное, тоже странновато выглядит).
РМ>5) Можно ли сесть на полосу? У меня не получилось.
Увы, нет. Руки не дошли. Предполагал возможность дозаправки, как сам знаешь где.
РМ>6) Чего он меня Реталиком обзывает?
Ну поменяй имя в конфиге — делов то! Кстати, в Hall Of Fame имя можно редактировать (backspace), не заметил?
РМ>7) При выходе виснет через раз, занимая по 90 процентов процессора.
Вот такого не наблюдал, странно.
Кстати, можешь попробовать поставить в конфиге fullscreen и видеорежим побольше (mode=7, например). Некоторая нагрузка на процессор ему только на пользу
РМ>Можно сделать коммерческим. Но нужно довести до нормального вида.
Я тоже это подозреваю.
РМ>Можно добавить поддержку мультиплеера.
У меня была DOS-версия с мультиплеером IPX. Могу рассказать общественности, как НЕ надо делать мультиплеер
Кстати, Hidden Feature!!!
Игра включает в себя возможность игры вдвоем — на split-screen. Для этого в конфиге надо прописать
duel=yes
Правила такие: побеждает тот, кто первым разбомбит цели противника (или собъет противника в воздушном бою). Режим не для слабонервных, нужно правильно настроить профиль каждого пилота (там скан-коды клавиш надо указывать в конфигах ).
РМ>Можно делать только для PC, а лучше, если исходник будет таким, что его можно будет откомпилировать для чего угодно, включая наладонники ( уж для WinCE-то это не сложно, но в принципе можно и для палма. ) Если сделаешь поддержку мультиплеера достаточно общо, а потом разберешься с голубыми зубами и красными глазами, и сможешь сделать так чтобы можно было на двух PDA-шках играть например в метро, то будет вообще супер, хотя не знаю насколько это реализуемо вообще. Кстати насколько?
Идея очень даже ничего. Если серьезно займемся игрушками для PDA, надо будет попробовать.
Подытожим:
1. Нужна программа настроек. Конфиги никто править не будет.
2. Графика устарела. Сейчас модны полупрозрачные взрывы и динамическое освещение.
3. Динамика игры нуждается в коррекции с учетом современных CPU.
4. Кучу разномастного (натыренного, прямо скажем) звука надо заменить на нечто цельное.
Здравствуйте, retalik, Вы писали:
R>Здравствуйте, Рома Мик, Вы писали:
РМ>>Клон соптвича. R>Ага, шаришь!
Игра суперская была... жаль что тока была (извини — твое пока не принимаем за "есть"..
РМ>>7) При выходе виснет через раз, занимая по 90 процентов процессора. R>Вот такого не наблюдал, странно.
Бывает... надо переключиться в игру (мышой) и нажать Enter (кстати, Tasm Manager оно запустить не дает почему-то...) R>Кстати, можешь попробовать поставить в конфиге fullscreen и видеорежим побольше (mode=7, например). Некоторая нагрузка на процессор ему только на пользу
R>Еще пожелания будут?
На чем писал?
... << RSDN@Home 1.1 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, Hacker_Delphi, Вы писали:
H_D>Игра суперская была... жаль что тока была (извини — твое пока не принимаем за "есть"..
Ты просто не втянулся
РМ>>>7) При выходе виснет через раз, занимая по 90 процентов процессора. R>>Вот такого не наблюдал, странно. H_D>Бывает... надо переключиться в игру (мышой) и нажать Enter (кстати, Tasm Manager оно запустить не дает почему-то...)
Учтем. Ох, давно я туда не лазил... Код страшный
R>>Еще пожелания будут? H_D>На чем писал?
Watcom C++ 10.0, 11.0. Был такой клевый компилятор...
Здравствуйте, retalik, Вы писали:
R>Ты просто не втянулся
Да нет... я про то, что коммерческого тут ничего пока нет
R>Учтем. Ох, давно я туда не лазил... Код страшный
Пынятна... с графикой я попробую помочь — у меня иногда получается чего-нить нарисовать неплохо...
H_D>>На чем писал? R>Watcom C++ 10.0, 11.0. Был такой клевый компилятор...
слаышал.. даже написал чегой-то на ем... матерился страшно
понятно... проще будет сесть и переписать на C# — и на покет потом спортировать можно будет главное — не забыть при отрисовке оставить возможность транспонирования картинки
... << RSDN@Home 1.1 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, Hacker_Delphi, Вы писали:
H_D>Пынятна... с графикой я попробую помочь — у меня иногда получается чего-нить нарисовать неплохо...
Я, конечно, только "за", но...
Понимаешь, если ты решишь понарисовать мне там клевых картинок, то выиграю только я (кстати, если ты серьезно — можно обсудить перспективы приватом).
А вот если кто-нибудь поделится опытом организации, подскажет, как и с чем выходят на издателей — от этого выиграют все участники форума.
R>>Watcom C++ 10.0, 11.0. Был такой клевый компилятор... H_D>слаышал.. даже написал чегой-то на ем... матерился страшно
Да ты что?! Первый кросс-платформенный компилер! У меня одно время Planers компилировались и под DOS, и под Win32, пока я на это не забил.
Первый компилятор с поддержкой 32-бит под DOS! (Хотя, может, и вру, что первый). Но Doom был точно на нем сделан (экстендер DOS4GW)... Эх, старость не радость
H_D>понятно... проще будет сесть и переписать на C# — и на покет потом спортировать можно будет главное — не забыть при отрисовке оставить возможность транспонирования картинки
А вот здесь большой и жирный вопрос. Минусов от дотнета для маленькой игрушки просто куча! Через год-два, может быть, он войдет в обиход, а пока...
Кроме того, я слышал, .NET CF сильно скрипит и жрет кучу памяти на PDA-шках.
Мне проще плюсовый код под Windows CE портировать.
PS: что интересно, обсуждение все время уплывает в сторону покетов. Видимо, бум грядет...
Здравствуйте, retalik, Вы писали:
H_D>>Пынятна... с графикой я попробую помочь — у меня иногда получается чего-нить нарисовать неплохо... R>Я, конечно, только "за", но... R>Понимаешь, если ты решишь понарисовать мне там клевых картинок, то выиграю только я (кстати, если ты серьезно — можно обсудить перспективы приватом). R>А вот если кто-нибудь поделится опытом организации, подскажет, как и с чем выходят на издателей — от этого выиграют все участники форума.
Ну... во-первых — у меня есть знакомый издатель...
во-вторых — к нему надо приходить с готовой игрушкой... и если надо делать ей графику/музыку/звук — он может помочь с профессионалами, иногда он даже сам за это платит (когда видит предстоящий успех игры)... минус — 50% бабок (после вычета налогов) — ему...
R>>>Watcom C++ 10.0, 11.0. Был такой клевый компилятор... H_D>>слаышал.. даже написал чегой-то на ем... матерился страшно R>Да ты что?! Первый кросс-платформенный компилер! У меня одно время Planers компилировались и под DOS, и под Win32, пока я на это не забил. R>Первый компилятор с поддержкой 32-бит под DOS! (Хотя, может, и вру, что первый). Но Doom был точно на нем сделан (экстендер DOS4GW)... Эх, старость не радость
Угу... да и квака первая под ним же была...
H_D>>понятно... проще будет сесть и переписать на C# — и на покет потом спортировать можно будет главное — не забыть при отрисовке оставить возможность транспонирования картинки R>А вот здесь большой и жирный вопрос. Минусов от дотнета для маленькой игрушки просто куча! Через год-два, может быть, он войдет в обиход, а пока... R>Кроме того, я слышал, .NET CF сильно скрипит и жрет кучу памяти на PDA-шках.
врут... у меня есть PDA и я на его уже писалЪ мелкий проектец на CF — все пучком... R>PS: что интересно, обсуждение все время уплывает в сторону покетов. Видимо, бум грядет...
Уже грянул... причем — давно
... << RSDN@Home 1.1 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
R>Понимаешь, если ты решишь понарисовать мне там клевых картинок, то выиграю только я (кстати, если ты серьезно — можно обсудить перспективы приватом).
ICQ # 9304498
... << RSDN@Home 1.1 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, retalik, Вы писали:
РМ>>4) Если полететь налево вначале, то самиолета видно не будет, но полет будет продолжаться. R>А что бы ты предложил?
я бы предложил или закольцевать или бесконечный пустой ландашфт, или конечный пустой ландшафт, или плавненько развернуть самолет об стенку.
РМ>>5) Можно ли сесть на полосу? У меня не получилось. R>Увы, нет. Руки не дошли. Предполагал возможность дозаправки, как сам знаешь где.
РМ>>7) При выходе виснет через раз, занимая по 90 процентов процессора. R>Вот такого не наблюдал, странно.
Оказалось, достаточно нажать Enter, но с процессором-то оно что делает?
РМ>>Можно сделать коммерческим. Но нужно довести до нормального вида. R>Я тоже это подозреваю.
Чего-то мне кажется, что доведение до нормального вида есть написание заново. Но это же не должно быть сложно, тем более если уже написано старое.
РМ>>Можно добавить поддержку мультиплеера. R>У меня была DOS-версия с мультиплеером IPX. Могу рассказать общественности, как НЕ надо делать мультиплеер
Расскажи. Очень интересно и как надо, и как не надо, и вообще все про мультиплеер.
РМ>>Можно делать только для PC, а лучше, если исходник будет таким, что его можно будет откомпилировать для чего угодно, включая наладонники ( уж для WinCE-то это не сложно, но в принципе можно и для палма. ) Если сделаешь поддержку мультиплеера достаточно общо, а потом разберешься с голубыми зубами и красными глазами, и сможешь сделать так чтобы можно было на двух PDA-шках играть например в метро, то будет вообще супер, хотя не знаю насколько это реализуемо вообще. Кстати насколько? R>Идея очень даже ничего. Если серьезно займемся игрушками для PDA, надо будет попробовать.
Имхо все сводится к вопросу: можно ли устроить tcp или udp через голубые зубы, через irda и что там еще. Ну должно быть можно! Хотя у меня никакой PDA-шки нет, а насколько я общался со одним старым палмом там все сильно запущено. Но для WinCE-то все должно быть круто.
R>Подытожим: R>1. Нужна программа настроек. Конфиги никто править не будет.
Само собой. R>2. Графика устарела. Сейчас модны полупрозрачные взрывы и динамическое освещение.
С учетом разговоров про PDA лучше сделать так, чтобы можно было заменять графические движки мановением руки, вообще не рогая все остальное. R>3. Динамика игры нуждается в коррекции с учетом современных CPU.
Само собой. R>4. Кучу разномастного (натыренного, прямо скажем) звука надо заменить на нечто цельное.
Ну не знаю, звук как звук.
R>Еще пожелания будут?
Не должно быть кривизны. Интерфейс может быть построен на основе обычных диалогов, но он должен работать, не давать вводить плохие данные и вообще. В игре должен быть режим паузы, с возможностью переключения из полноэкранного режима.
Здравствуйте, retalik, Вы писали:
H_D>>понятно... проще будет сесть и переписать на C# — и на покет потом спортировать можно будет главное — не забыть при отрисовке оставить возможность транспонирования картинки R>А вот здесь большой и жирный вопрос. Минусов от дотнета для маленькой игрушки просто куча! Через год-два, может быть, он войдет в обиход, а пока...
Мое мнение, с дотнетом надо ждать. Иначе для писюков — это все работать просто не будет.
R>Мне проще плюсовый код под Windows CE портировать.
Да там и портировать особенно не надо, фактически один и тот же код компилится туда-сюда, если с юникодом все нормально сделано.
R>PS: что интересно, обсуждение все время уплывает в сторону покетов. Видимо, бум грядет...
Дык инрушка такая для писюков — это так забава, а для пдашек — нормальная игруля.
Здравствуйте, Рома Мик, Вы писали:
РМ>Здравствуйте, retalik, Вы писали:
H_D>>>понятно... проще будет сесть и переписать на C# — и на покет потом спортировать можно будет главное — не забыть при отрисовке оставить возможность транспонирования картинки R>>А вот здесь большой и жирный вопрос. Минусов от дотнета для маленькой игрушки просто куча! Через год-два, может быть, он войдет в обиход, а пока... РМ>Мое мнение, с дотнетом надо ждать. Иначе для писюков — это все работать просто не будет.
Вот тут ты не прав... дотнет имеет вполне нормальную скорость всего, что в нем есть R>>Мне проще плюсовый код под Windows CE портировать. РМ>Да там и портировать особенно не надо, фактически один и тот же код компилится туда-сюда, если с юникодом все нормально сделано.
R>>PS: что интересно, обсуждение все время уплывает в сторону покетов. Видимо, бум грядет... РМ>Дык инрушка такая для писюков — это так забава, а для пдашек — нормальная игруля.
Ну как сказать... если все нормально вылизать — продаваться будет
... << RSDN@Home 1.1 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, Hacker_Delphi, Вы писали:
H_D>Ну... во-первых — у меня есть знакомый издатель... H_D>во-вторых — к нему надо приходить с готовой игрушкой... и если надо делать ей графику/музыку/звук — он может помочь с профессионалами, иногда он даже сам за это платит (когда видит предстоящий успех игры)... минус — 50% бабок (после вычета налогов) — ему...
Хм... Это у всех издателей такие расценки? Что-то не очень прельщает. Дешевле, наверное, будет взять расходы по оформлению и распространению на себя. Единственный довод "за" — если у него мощные каналы по распространению (посещаемая сеть, рассылка сидюков или что-нибудь такое).
H_D>врут... у меня есть PDA и я на его уже писалЪ мелкий проектец на CF — все пучком...
А Саша Шаргин пока не в восторге. К тому же, CF, вроде, дополнительно грузить надо. А MFC в ROM зашита.
Здравствуйте, Рома Мик, Вы писали:
РМ>я бы предложил или закольцевать или бесконечный пустой ландашфт, или конечный пустой ландшафт, или плавненько развернуть самолет об стенку.
ОК
РМ>Оказалось, достаточно нажать Enter, но с процессором-то оно что делает?
А-а, вон ты про что
Ну там я Message Loop некорректно устроил. Что-то вроде PeekMessage в цикле в ожидании нажатий клавиш. Сейчас бы так не сделал, конечно.
РМ>Чего-то мне кажется, что доведение до нормального вида есть написание заново. Но это же не должно быть сложно, тем более если уже написано старое.
Самая главная проблема — движок. У нас (с приятелем, который очень помог с движком) была целая библиотека создана, причем портировалась (где-то версия под DOS была забавная, мультик там крутился между боями).
Но все это было Watcom-specific (с его хитрым ассемблером) и на VC переносить достаточно трудно.
Кроме того, если использовать эффекты типа полупрозрачности, то нужно что-то готовое. А какие графические движки есть у Покетов?
РМ>Расскажи. Очень интересно и как надо, и как не надо, и вообще все про мультиплеер. "Как не надо".
Фактически, на каждом компьютере запускалась самостоятельная игрушка. Игра начиналась по сообщению синхронизации. Дальше каждый игровой объект (от установки ПВО до последнего выпущенного снаряда) формировал сетевой пакет с указанием своего типа, координат, направления, скорости и т.д. Самое главное:
1) эти пакеты посылались в обе стороны для всех объектов! Как мы до такого додумались?!
2) они не содержали состояния объектов, только физические характеристики.
3) на каждом компьютере все события обсчитывадись самостоятельно. Поэтому был возможен такой сценарий:
На машине_1 выпущен снаряд. Он тут же добавлен в список объектов на машине_2.
Снаряд прошел на расстоянии в 1 пиксель от самолета по рассчетам на машине_1, но достиг самолета на машине_2
(скажем, частота обсчета была чуть иной).
С этого момента начинается дикая каша с рассогласованием: на одном экране самолет горит в воздухе не падая (потому что исправно получает координаты с другой машины), на другом — он бодро летает и стреляет.
"Как надо"
Да все очень просто: клиент-сервер.
Сервер начинает игру (как вариант: ждет подключения всех игроков).
Его основной цикл включает в себя:
— Расчет всех игровых событий, координат, параметров, вызов модуля AI и скриптовых заготовок по ситуации.
— Формирование сетевого пакета, содержащего перечень всех игровых объектов с их состоянием.
— Рассылку этого пакета всем участникам баталии.
— Прием от клиентов управляющих сетевых пакетов (выстрелов, воздействий на рычаги управления и т.д.)
— Учет этих управляющих событий.
Клиент подключается к серверу.
Его основной цикл:
— Получить сетевой пакет с описанием всех игровых объектов.
— Нарисовать полученную картинку.
— Обработать события от клавиатуры и мышки.
— Упаковать их в управляющий пакет и отправить его на сервер.
Можно добиться работы сервера и клиента "в одном флаконе". Иначе же получится чистый dedicated-server.
R>>2. Графика устарела. Сейчас модны полупрозрачные взрывы и динамическое освещение. РМ>С учетом разговоров про PDA лучше сделать так, чтобы можно было заменять графические движки мановением руки, вообще не рогая все остальное.
Только вот я ничего не знаю про грффику на PDA. DirectX там хотя бы есть?
R>>Еще пожелания будут? РМ>Не должно быть кривизны. Интерфейс может быть построен на основе обычных диалогов, но он должен работать, не давать вводить плохие данные и вообще. В игре должен быть режим паузы, с возможностью переключения из полноэкранного режима.
Пасиба!
Здравствуйте, retalik, Вы писали:
R>Кроме того, если использовать эффекты типа полупрозрачности, то нужно что-то готовое. А какие графические движки есть у Покетов?
Да вроде бы там был DirectX
... << RSDN@Home 1.1 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, retalik, Вы писали:
R>Здравствуйте, Hacker_Delphi, Вы писали:
H_D>>Ну... во-первых — у меня есть знакомый издатель... H_D>>во-вторых — к нему надо приходить с готовой игрушкой... и если надо делать ей графику/музыку/звук — он может помочь с профессионалами, иногда он даже сам за это платит (когда видит предстоящий успех игры)... минус — 50% бабок (после вычета налогов) — ему... R>Хм... Это у всех издателей такие расценки? Что-то не очень прельщает. Дешевле, наверное, будет взять расходы по оформлению и распространению на себя. Единственный довод "за" — если у него мощные каналы по распространению (посещаемая сеть, рассылка сидюков или что-нибудь такое).
Естественно есть
H_D>>врут... у меня есть PDA и я на его уже писалЪ мелкий проектец на CF — все пучком... R>А Саша Шаргин пока не в восторге. К тому же, CF, вроде, дополнительно грузить надо. А MFC в ROM зашита.
Гм... основной бум покетов начался именно сейчас, а на современных покетах стоит PocketPC 2003, в котором есть CF (в ROM).
... << RSDN@Home 1.1 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, Hacker_Delphi, Вы писали:
H_D>Вот тут ты не прав... дотнет имеет вполне нормальную скорость всего, что в нем есть
Я имел ввиду, что дотнета нигде пока нету.
Здравствуйте, Рома Мик, Вы писали:
РМ>Здравствуйте, Hacker_Delphi, Вы писали:
H_D>>Вот тут ты не прав... дотнет имеет вполне нормальную скорость всего, что в нем есть РМ>Я имел ввиду, что дотнета нигде пока нету.
Да ну? в PocketPC 2003 он по умолчанию стоит... а по нынешним оценкам минимум треть покетов — 2003..
а других сейчас не используется...
... << RSDN@Home 1.1 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, Hacker_Delphi, Вы писали:
H_D>Здравствуйте, Рома Мик, Вы писали:
РМ>>Здравствуйте, Hacker_Delphi, Вы писали:
H_D>>>Вот тут ты не прав... дотнет имеет вполне нормальную скорость всего, что в нем есть РМ>>Я имел ввиду, что дотнета нигде пока нету. H_D>Да ну? в PocketPC 2003 он по умолчанию стоит... а по нынешним оценкам минимум треть покетов — 2003.. H_D>а других сейчас не используется...
Речь шла про писюки.
Если говорить про покеты, то палмов не меньше покетов и про них забывать тоже не стоит, а вот для них дотнета н будет никогда. То есть на c++ куда портабельнее можно сделать.
Все это естественно только мое мнение.
Здравствуйте, Hacker_Delphi, Вы писали:
РМ>>Я имел ввиду, что дотнета нигде пока нету. H_D>Да ну? в PocketPC 2003 он по умолчанию стоит... а по нынешним оценкам минимум треть покетов — 2003.. H_D>а других сейчас не используется...
Вообще-то, еще Palm-ы есть. И они вполне конкурентно способные (Sony Clie, например). Если хочется покрыть больший рынок — .NET пролетает.
Здравствуйте, retalik, Вы писали:
R>"Как не надо". R>Фактически, на каждом компьютере запускалась самостоятельная игрушка...
Сетевая игра всегда является компромиссом. Между динамикой игровых объектов (быстродействием) и синхронизацией их действий во всех экземплярах игры, между загруженностью канала связи и временем реакции на событие, ... Можно долго перечислять эти компромисы, их состав и баланс будет зависеть от игры: её жанра, самого игрового процесса. Последним в списке будет компромис между желаниями и возможностями реализующего сетевую подсистему игры программиста.
Считается, что просчитывать и воспроизводить графику — святая обязанность игрового движка. Но вот про расчёт физики игрового мира тоже забывать не стоит, если игра динамичная, то эти действия будут занимать немалое время работы процессора. Удачный движок должен красиво всё рисовать, просчитывать физику взаимодействия игровых объектов и иметь запас времени на всякий случай: на обмен информацией по сети, обработку ввода игрока, действия операционной системы и др. всякие случайности.
Использованный в игре описанный метод не так уж и неудачен (порочен). Надо просто правильно подойти к физике игрового мира. Например, учёту и квантованию времени в условных единицах, достаточных для динамичности, но далёких от предельного разрешения таймеров. Например, учёту координат объектов в условных единицах, далёких от разрешения экрана. Скажем, применительно к обсуждаемой игре, известны начальное положение, направление, ускорение и скорость движения самолёта. Их не нужно передавать всем игровым клиентам, обеспечивая тем самым синхронизацию. Достаточно передать эти данные вначале, и далее каждый клиент сумеет правильно, с учётом физики, нарисовать положение самолёта на каждый момент времени. Но если игрок дёрнул за рычаг и изменил положение элеронов (или что там меняет направление полёта), добавил или убавил газ (изменил ускорение — скорость движения) или не дай бог нажал на гашетку (породил один или несколько новых игровых объектов), тогда по сети полетят пакеты модификации игрового мира. Должны полететь. И должны гарантированно успеть долететь до всех игровых клиентов за принятый в игре квант времени. Иначе новое положение будет воспроизведено клиентами некорректно. Это проблема всех динамичных игр — пропускная способность сети, модель распространения информации об изменениях (от одного всем, от каждого из оповещённых кому-то из неоповещённых, ...).
Чем меньше информации передаётся по сети, тем меньшая пропускная способность будет задействована, тем выше будет быстродействие коммуникаций, но большая доля работы ляжет на плечи конкретного экземпляра игры (конкретного компьютера, процессора, видеопроцессора и т.п.)
Всегда надо искать компромисс: увеличивать квант времени, увеличивать загрузку сети... Да и сеть — среда сама по себе непостоянная. То потухнет, то погаснет...
R>... на каждом компьютере все события обсчитывадись самостоятельно. Поэтому был возможен такой сценарий: R>
R>На машине_1 выпущен снаряд. Он тут же добавлен в список объектов на машине_2.
R>Снаряд прошел на расстоянии в 1 пиксель от самолета по рассчетам на машине_1, но достиг самолета на машине_2
R>(скажем, частота обсчета была чуть иной).
R>
Тут просто надо было перейти от зависимых от аппаратуры (разрешения экрана) единиц к независимым, например, от пикселей к метрам. И столкновения считать с точностью до метра, грубо говоря. Если обеспечивается присутствие в одинаковых координатах в определённый квант времени нескольких объектов — значит, они столкнулись. Нужна реалистичность — переходим к меньшим единицам — сантиметрам. Для вывода на экран пересчитываем их в пиксели. Коэффициент пересчёта может быть самым "непредсказуемым". Даже один к одному.
Если на каждом компьютере таймеры ну очень сильно расходятся и сбивают физику (из-за выбранного малого кванта игрового времени, чтобы соответствовать физике игрового мира) — придётся посылать синхроимпульсы "точного времени" (специальные пакеты, содержащие само время или просто признак его изменения) от одного "эталона" (рядового экземпляра игры) самому себе и другим игровым клиентам. Помните: "Начало шестого сигнала соответствует пятнадцати часам..." Всё давно уже придумано и валяется под ногами. Только глаза пошире успевай открывать...
R>"Как надо" R>Да все очень просто: клиент-сервер.
Просто, да не просто. Удобно для одних жанров — неудобно для других. Если ИИ настолько нелинеен, что его действия на каждом компьютере будут разными — значит его надо расчитывать в одном месте и оповещать остальных. Либо изменить его поведение так, чтобы он вёл себя одинаково при одних и тех же начальных условиях на разном оборудовании. Скажем, для стратегий клиент-сервер идеален, особенно пошаговых, т.к. нет жесткого квантования состояния игрового мира по времени. Хотя и здесь не помешало бы одинаковые для всех экземпляров игры действия не рассылать, а воспроизводить.
Другой аспект пошаговых стратегий заключается в том, что пока игрок думает, как походить, процессорные мощности простаивают, тратя ничтожную (или иногда чтожную, но не оправданную) мощность на ожидание и обслуживание ввода игрока. И только потом грянет гром, и ИИ зашевелится. А ведь за время хода (мыслительного процесса) живого человека ИИ вполне может расчитать свой ход. Иногда даже неоднократно. Реалтаймовые стратегии в этом плане более критичны. Они либо должны успевать за квант времени пересчитать все действия ИИ (поэтому и соперников мало, иначе они тупеют, и берут они человека не умением, а числом), либо иметь возможность за квант времени выбрать приоритеты, оценить критичность ситуации, и обработать критичную часть. А полный цикл просчёта действий ИИ провести за конечное число квантов времени.
Почти как человек, если его (человека) привлечёт какой-нибудь фрагмент игрового мира (карты, город, скопление юнитов, ...), то в другом месте хоть трава не расти. Это вроде как называется концентрацией внимания, и ИИ тоже может и должен уметь внимание концентрировать. И как и человеку, ИИ может не хватать кванотов времени на обсчёт всего и вся.
Ну а вернувшись к обсуждаемой игре могу сказать, что не всегда может хватить быстродействия на цепочку: ввод клиента — на сервер — обсчёт всех клиентов — возврат на клиента — новое положение — отрисовка — ввод клиента.
Для динамичных игр надо искать пути сокращения временных и пр. затрат на эту цепочку, а то и исключать те или иные звенья.
Всё высказано не в претензии на абсолютное знание, но обсуждения ради...
Я рад, что обсуждение пошло в плодотворном ключе. Можно и поспорить .
[Очевидности пропущены]
A>Но если игрок дёрнул за рычаг и изменил положение элеронов (или что там меняет направление полёта), добавил или убавил газ (изменил ускорение — скорость движения) или не дай бог нажал на гашетку (породил один или несколько новых игровых объектов), тогда по сети полетят пакеты модификации игрового мира. Должны полететь.
Мысль понятна, и этот принцип вполне можно использовать для распределения вычислительной нагрузки с сервера на всех клиентов. Главное только вслух сказать: "кванты синхронизации" должны доставляться всем участникам игрового процесса и в том случае, если они содержат принципиально новую информацию. Например, послан новый снаряд, где-то скрипт создал новый объект, кто-то из участников убит. Такие события нельзя отдавать на откуп самостоятельным вычислениям — они повлияют на все дальнейшие события.
Такое решение применяется и в оптимизированном для модемов коде в современном мультиплеере. Скажем, в Q3 игрок с высоким пингом "проскочит" на своем компьютере выстрел из рейлгана и свернет за угол, но сервер пришлет ему информацию, что он-таки убит. Расчеты расчетами, но здесь уже дело рисованием не ограничивается: надо фраги считать
A>Тут просто надо было перейти от зависимых от аппаратуры (разрешения экрана) единиц к независимым, например, от пикселей к метрам. И столкновения считать с точностью до метра, грубо говоря. Если обеспечивается присутствие в одинаковых координатах в определённый квант времени нескольких объектов — значит, они столкнулись.
Для меня очевидно, что при любой системе счета будет разница в результате, если вычислительная мощность или лаг сильно различаются. Обмен информацией о состоянии неизбежен!
Другой аргумент — читерство. Недобросовестный игрок может модифицировать код клиента и, например, "всегда стрелять первым". Если сервер не пресечет такое — налицо либо рассинхронизация, либо обман.
A>придётся посылать синхроимпульсы "точного времени" (специальные пакеты, содержащие само время или просто признак его изменения) от одного "эталона" (рядового экземпляра игры) самому себе и другим игровым клиентам.
Так зачем все-таки посылать синхроимпульсы времени, если есть "вехи"-события?
A>А ведь за время хода (мыслительного процесса) живого человека ИИ вполне может расчитать свой ход. Иногда даже неоднократно.
А вот это очень хорошая мысль. Опять таки, с оглядкой на синхронизацию. "Мысли" AI вполне можно отдать на откуп клиентам — пока этот AI не нажал на гашетку При этом мы разгружаем сервер, но не создаем рассогласований.
A>Ну а вернувшись к обсуждаемой игре могу сказать, что не всегда может хватить быстродействия на цепочку: ввод клиента — на сервер — обсчёт всех клиентов — возврат на клиента — новое положение — отрисовка — ввод клиента.
Ну обсчет всех клиентов — дело обязательно централизованное. Обратных примеров не знаю. Есть такие?
А все остальное, действительно, поддается распределению. Можно, например, оптимизировать трафик, посылая клиентам индивидуальные "выжимки" -только из видимых объектов, например. Хотя, опять же, это где у нас такой трафик дорогой?
A>Всё высказано не в претензии на абсолютное знание, но обсуждения ради...
Здравствуйте, retalik, Вы писали:
R>Я рад, что обсуждение пошло в плодотворном ключе. Можно и поспорить .
Спорить пока незачем, можно и просто пообщаться и поделиться знаниями.
Я лично специализируюсь на стратегиях и конкретно пошаговых стратегиях, но играю в разные игры. И иногда интересно бывает, как они устроены...
R>..."кванты синхронизации" должны доставляться всем участникам игрового процесса и в том случае, если они содержат принципиально новую информацию. Например, послан новый снаряд, где-то скрипт создал новый объект, кто-то из участников убит. Такие события нельзя отдавать на откуп самостоятельным вычислениям — они повлияют на все дальнейшие события.
Я это и имел ввиду. Что для реалтаймовых игр следует линейное неприрывное время отквантовать (разбить на кусочки, дискретизировать) таким образом, чтобы у играющих сохранился эффект непрерывности, но за выбранный шаг дискретизации каждый из участников игрового процесса гарантированно бы получал информацию о изменениях в игровом мире.
R>...в Q3 игрок с высоким пингом "проскочит" на своем компьютере выстрел из рейлгана и свернет за угол, но сервер пришлет ему информацию, что он-таки убит. Расчеты расчетами, но здесь уже дело рисованием не ограничивается: надо фраги считать
А с чего он проскочит, если мы дискретизируем время? Только сначала предположим, что всё в "стерильных" условиях, без модификации кода, чита и пр. Высокий пинг позволяет принять/передать пакет, а дальше игровой мир должен ждать прихода следующего кванта времени, чтобы изменить мир, прореагировать на ввод игрока и т.п. Быстрый компьютер справится с задачей отрисовки нового состояния игрового мира играющему, опросит ввод, сеть, возможно, просчитает ИИ, и даже может послать себе и другим пакеты изменения игрового мира, но должен ждать кванта, чтобы начать реагировать на изменения. Те же, кто пыхтеть будут из последних сил, чтобы в квант времени уложится со всеми действиями — и будут определять минимальные требования к игре, ниже которых играть уже нельзя.
Вопрос в том, как поступить — просто написать, что играть нельзя, или же потестировать возможности играть на конретной аппаратуре, и тоже оповестить, или же реализовать возможности пропуска квантов времени, что будет выражаться, например, в эффекте листания картинки на экране...
Есть ещё один интересный аспект — увеличение игровых объектов и их отсечение по области видимости для конкретного игрока. Тут будет правильнее не поддерживать полностью состояние такого игрового мира на всех клиентах, а наоборот переложить всё на сервер, а клиентам выдавать только то, что им видно и полезно для принятия решений живыми игроками. ИИ тоже может функционировать с учётом области видимости, и не обязательно только на сервере, где известно всё_обо_всём.
Такой пример. Халва, я и двое в комнате с одной дверью, за которой коридор, в коридоре пятеро, дверь закрыта. Я командую "посмотреть направо, посмотреть налево". Что оптимальнее — передать на сервер, который передаст мои действия всем, или пусть посчитает видимость и передаст только двоим, что рядом, или же я передам инфу тем, кто рядом напрямую, да и то если они лицом ко мне стоят. А вот кто кого видит — будет говорить сервер, ему я буду посылать координаты и вектор направления лица (и другие будут).
R>Для меня очевидно, что при любой системе счета будет разница в результате, если вычислительная мощность или лаг сильно различаются. Обмен информацией о состоянии неизбежен!
Вот и идея в том, что в квант времени должны укладываться все необходимые расчёты. В выборе этого кванта для конкретных требований к игре и её физике.
R>Другой аргумент — читерство. Недобросовестный игрок может модифицировать код клиента и, например, "всегда стрелять первым". Если сервер не пресечет такое — налицо либо рассинхронизация, либо обман.
Тут как обычно, три пути.
Один — скрывать информацию (данные) от простого изменения в памяти. Для динамических игр отсутствие отклика от играющего в течении кванта времени уже повод для прерывания игры, т.к. не соответствует минимальным требованиям. Нет мгновенных сканеров ОЗУ, которые ещё и позволяют мгновенно модифицировать ОЗУ нанужный лад. Остаётся только модификация кода.
И тут есть Второй путь. Вычислять контрольные суммы, версии кода, при начале игры их сверять и допускать в игру или не допускать.
Дополнительно можно согласовывать всякие коэффициенты (скорость пуль, торпед, движения игроков) однотипных игровых объектов на всех игровых клиентах по одному из клиентов, например, тому, кто создал игру. Тогда что бы ты не поменял в настроечках (если поменял), оно будет перезаписано. А если замешкаешься с реакцией на квант времени (захочется модифицировать обратно) — тебя кинут по несоответствию по минимальным требованиям по быстродействию.
R>Так зачем все-таки посылать синхроимпульсы времени, если есть "вехи"-события?
Музыкальные инструменты (правильнее сказать, играющие на них) используют метроном (тикающая такая штучка) для синхронизации мелодии. Если принять скрипки и балалайки за экземпляры игры, то это позволит им уменьшить кванты времени без начала рассогласования. Т.е. больший квант будет позволять лучше синхронизироваться, но при этом динамичность и игровая непрерывность будут уменьшаться. И когда-нибудь играющий заметит "рывки" в реалтайме. А это недопустимо. Синхроимпульсы погут просто содержать инкрементируемый счётчик, что позволит также оценить и пропадание пакетов.
В пошаговых стратегиях, имеющих ограничение на время хода, надо дать играющим необходимое количество локального времени, но также следует его ограничить, чтобы кто-то не перевёл текущие часы-будильник назад и не получил дополнительные 30 секунд. Но это я отклоняюсь...
A>>А ведь за время хода (мыслительного процесса) живого человека ИИ вполне может расчитать свой ход. Иногда даже неоднократно. R>А вот это очень хорошая мысль.
Мне тоже нравится, но на практике ею пренебрегают, говоря что на отрисовку нашей офигенной графики и fps нужна уйма времени. Врут, не врут — не знаю. Для стратегий пошаговых, по моему, очень подходит.
R>Ну обсчет всех клиентов — дело обязательно централизованное. Обратных примеров не знаю. Есть такие?
У меня тоже нет живых примеров. Чтобы пальцем показать — вот мол, так и сделано. Но почему нет? Почему только по шаблону клиент-сервера идти, почему нельзя распределить расчёт действий ИИ...
Например, есть два живых игрока (два компьютера) и два игрока компьютерных. Пусть они все противники. Клиент-сервер попросит собрать действия первого живого, второго живого, потом расчитать действия двух ИИ, наложить их действия и раздать новое состояние живым для раздумий. А можно один ИИ привязать к одному живому, второго — ко второму, таким образом распараллелив вычислительную нагрузку по принятию решения, а по наложению действий и раздачи нового состояния делегировать выделенному (или невыделенному) игровому серверу. А теперь захочется пойти дальше, уложить эти все расчёты в квант времени, тогда кто быстрее справится — подождёт другого.
R>Хотя, опять же, это где у нас такой трафик дорогой?
Если речь о деньгах, то это Онлайн игры в Интернет. Если речь о загруженности каналов связи, то разные ситуации бывают на разных предприятиях. Пока кто-то играет, кто-то может и работать, занимаясь как бы более приоритетным делом в плане коммуникаций. Или, что более к практике — хочу и файл тянуть, и в Халву гонять. Даже в ЛВС попробуем копирнуть чего по сети, пусть она хоть 100 МБит во лбу...
Здравствуйте, akasoft, Вы писали:
R>>Я рад, что обсуждение пошло в плодотворном ключе. Можно и поспорить . A>Спорить пока незачем, можно и просто пообщаться и поделиться знаниями.
А мне-то как вас читать интересно
A>Что для реалтаймовых игр следует линейное неприрывное время отквантовать (разбить на кусочки, дискретизировать) таким образом, чтобы у играющих сохранился эффект непрерывности, но за выбранный шаг дискретизации каждый из участников игрового процесса гарантированно бы получал информацию о изменениях в игровом мире.
Тут штука в том, что можно сделать этот квант можно весьма большим, до долей секунды. Но отрисовываться все должно тем не менее плавно. То есть для каждого объекта имеется текущее положение и положение в конце кванта, ну и известно время окончания кванта, и как там процессор успевает считать, столько промежуточных положений ( не обязательно связыть положения прямой линией, кстати ) и отрисовывать в течение кванта, на медленных машинах можно даже меньше единицы.
пакет от сервера:
Номер кванта, т.е. текущее время.
Положения интерсующих объектов к концу кванта.
пакет от клиента:
Номер кванта.
Управляющие воздействия за время кванта.
Сервер получает действия за N-ный квант. Рассчитывает с их учетом новые положения объектов к концу (N+2)-ого, и отправляет.
Клиент к началу N-ного кванта знает положение объекта в начале и в конце кванта, этого достаточно, чтобы в течение кванта плавно отображать движение.
Здесь нажатия кнопок за N-ный квант будут действовать во время (N+2)-ого кванта. Зато все в равных условиях и ясно, как отслеживать недостаточную скорость сети.
ИМХО размер кванта здесь может быть чуть не до 1/4 секунды, тогда за полсекунды мы получим результат на экране, что вполне достаточно.
A>Есть ещё один интересный аспект — увеличение игровых объектов и их отсечение по области видимости для конкретного игрока. Тут будет правильнее не поддерживать полностью состояние такого игрового мира на всех клиентах, а наоборот переложить всё на сервер, а клиентам выдавать только то, что им видно и полезно для принятия решений живыми игроками.
Это имеет смысл только для больших миров.
A>ИИ тоже может функционировать с учётом области видимости, и не обязательно только на сервере, где известно всё_обо_всём.
А ИИ имеет смысл реализовать через тот же интерфейс, что имеют удаленные игроки. Впрочем локального игрока тоже имеет смысл делать через тот же интерфейс — это позволит легко реализовать режим "двое за одной машиной".
R>>...в Q3 игрок с высоким пингом "проскочит" на своем компьютере выстрел из рейлгана и свернет за угол, но сервер пришлет ему информацию, что он-таки убит. Расчеты расчетами, но здесь уже дело рисованием не ограничивается: надо фраги считать
A>А с чего он проскочит, если мы дискретизируем время?
А там предсказание есть. Т.е клиент пытается предсказать движения объектов. Порой это доходит до того, что ты спокойно заруливаешь в коридор, проходишь пару метров, а тут тебе прилетает пакет с реальным твоим расположением — упертым в стенку рядом с входом в коридор . Без предсказания играть в такие игры, как CS, TF с плохим пингом (от 200) было бы практически невозможно — постоянные рывки.
Дошел тут до 37 уровня.
Кроме всего прочего эта игрушка субъективно увеличивает скорость работы ПК. Ощущение, что все просто летает. Даже мышка быстрее ездит.
Здравствуйте, WFrag, Вы писали:
WF>А там предсказание есть.
Слово-то какое. На ум приходит всякий спиритизм, гадание и шаманы. Мне же кажется, что должно быть чистое знание, того что должно быть. По-другому, математика, т.е. расчёт на основе имеющейся информации.
Хотя теперь мне слово "предсказание" не кажется таким неуместным... Оно даже оригинальное.
WF> Т.е клиент пытается предсказать движения объектов. Порой это доходит до того, что ты спокойно заруливаешь в коридор, проходишь пару метров, а тут тебе прилетает пакет с реальным твоим расположением — упертым в стенку рядом с входом в коридор .
Это уже будет некорректное предсказание. Тот же рывок, только с видимостью плавности. "Плавный рывок". А всё из-за того, что сеть штука медленная по отношению к цепочке процессор-память и даже П-П-видеосистема-глаз.
Здравствуйте, Рома Мик, Вы писали:
РМ>ИМХО размер кванта здесь может быть чуть не до 1/4 секунды, тогда за полсекунды мы получим результат на экране, что вполне достаточно.
Достаточно или нет, сказать не могу, т.к. опыта нет. Но по моему обмен по сети будет занимать больше времени, нежели расчёт сцены и показ её играющему.
A>>Есть ещё один интересный аспект — увеличение игровых объектов и их отсечение по области видимости для конкретного игрока. Тут будет правильнее не поддерживать полностью состояние такого игрового мира на всех клиентах, а наоборот переложить всё на сервер, а клиентам выдавать только то, что им видно и полезно для принятия решений живыми игроками.
РМ>Это имеет смысл только для больших миров.
Ну почему-же. Узкое место сетевой игры сама сеть. Т.е. цепочка клиент1-сеть-другой клиент или сервер-сеть-клиент1. Поэтому надо стремиться передавать по сети меньше и только то, что нужно. Без чего никак играть нельзя. И если два игрока друг друга не видят, то им незачем передавать те же координаты друг друга.
Пусть такой пример. Две комнаты, без окон, только по закрытой двери в каждой, каждая дверь выходит в корридор. Игрок1 давит кнопки движения, водит мышью, и камера любезно рисует ему интерьер нашей комнаты, текстурки там красивые (или некрасивые). Игрок может посмотреть в любую сторону, рассмотреть стену поближе, к двери подойти. То же самое может делать и второй игрок. И ещё любое их количество, заточённые в одиночные камеры, выходящие в коридор нашей Бастилии. Но! Передавать по сети ничего не надо. Ни серверу, ни каждому из клиентов. Сеть спит, не задействована.
А теперь пусть игрок1 откроет дверь в коридор. Теперь надо узнать, есть ли кто в коридоре. И если нет — то снова штиль в сети. Узнавать будем у сервера. И сервер же оповещать, что мы открываем дверь в коридор.
Теперь пусть игрок1 изучает коридор, а игрок2 тоже откроет дверь. Что будет? Игрок2 сообщит серверу об открытии двери, сервер должен будет сказать, что коридор не пуст, должен будет дать инфу о изменении видимости игроку1 (тот услышит звук открываемой двери) и игроку2 тоже. И теперь возможны варианты. Либо игроки 1 и 2 будут общаться через сервер, что накладно по времени, но зато не нужен прямой канал между игроками; либо же сервер выдаст коммуникационную информацию обеим игрокам, и они будут передавать свои координаты и вектор камеры напрямую друг другу, что будет быстрее, но требует прямого канала связи между всеми игроками.
Видно, что за областью видимости следит сервер. Переходы между областями видимости вполне конкретны: смена помещения, открытие двери. Дополнительно можно учитывать и вектор направления камеры (лица, взгляда играющего), и наличие тумана, и горизонт, и просто определить, что дальше 5-ти метров игроки нифига не видят, аки близорукие.
Вот такой простой например.
РМ>А ИИ имеет смысл реализовать через тот же интерфейс, что имеют удаленные игроки. Впрочем локального игрока тоже имеет смысл делать через тот же интерфейс — это позволит легко реализовать режим "двое за одной машиной".
Особенно это хорошо для пошаговых стратегий. Все подумали, и отдали свои приказы. Причём ИИ может думать независимо от действия живых игроков, и параллельно их раздумьям. А потом сервер собирает приказы, проверяет их корректность, расчитывает и выдаёт новое состояние игрового мира...
Здравствуйте, akasoft, Вы писали:
A>Особенно это хорошо для пошаговых стратегий.
Так все игры почти пошаговые, только некоторые с автоматическим концом хода.
Здравствуйте, akasoft, Вы писали:
A>Слово-то какое. На ум приходит всякий спиритизм, гадание и шаманы. Мне же кажется, что должно быть чистое знание, того что должно быть. По-другому, математика, т.е. расчёт на основе имеющейся информации.
prediction
A>Хотя теперь мне слово "предсказание" не кажется таким неуместным... Оно даже оригинальное.
WF>> Т.е клиент пытается предсказать движения объектов. Порой это доходит до того, что ты спокойно заруливаешь в коридор, проходишь пару метров, а тут тебе прилетает пакет с реальным твоим расположением — упертым в стенку рядом с входом в коридор .
A>Это уже будет некорректное предсказание. Тот же рывок, только с видимостью плавности. "Плавный рывок". А всё из-за того, что сеть штука медленная по отношению к цепочке процессор-память и даже П-П-видеосистема-глаз.
Корректное. Фича в том, что клиент как бы играет только на своем компе — все объекты обсчитываются у него. А с сервера время от времени приходят эталонные даные, по которым клиент синхронизуется. Если сервер/клиент исполняют одинаковый код, то клиент более-менее правильно экстраполирует положения объектов. Без этого, если происходит потеря пакетов в течении полусекунды, например, клиент бы просто висел. А так хоть видимость действий. Более подробно можно на gamedev.net почитать, там вроде было.
Здравствуйте, akasoft, Вы писали:
A>Разве что о пошаговых стратегиях.
Думаю былобы интересно. A>В других жанрах опыта разработчика нет, только догадки, умозаключения, наблюдения и пожелания...
Но судя по этому топику ты еще можешь не плохо написать "Домыслы и умозаключения об организации сетевых игр." ну и "догадки, умозаключения, наблюдения и пожелания об организации игр" тоже может быть неплохо.
ЗЫ Думайте сами решайте сами...(С)Непомню.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Я тут игрушку выложил...
От:
Аноним
Дата:
25.12.03 13:20
Оценка:
Здравствуйте, retalik, Вы писали:
R>Подробности здесь
Здравствуйте, Виталий,
прочитал всю нить, попробовал игрушку и мне стало интересно чем же закончилась история
Удалось ли довести игру до ума и продать ее?
Если да, поделитесь пожалуйста впечатлениями.
Здравствуйте, Аноним, Вы писали:
А>прочитал всю нить, попробовал игрушку и мне стало интересно чем же закончилась история А>Удалось ли довести игру до ума и продать ее? А>Если да, поделитесь пожалуйста впечатлениями.
Да пока ничем. Слишком много проектов висит, а это — "для души", тут суетиться не хочется.
Потихонечку переношу исходники под VC++ (они на древнем WATCOM), собираюсь улучшить графику (скорее всего, перенести движок на DirectX).
Игрушка-то хоть захватила? Мне интересны мнения других людей.
Здравствуйте, retalik, Вы писали:
R>Здравствуйте, Аноним, Вы писали:
А>>прочитал всю нить, попробовал игрушку и мне стало интересно чем же закончилась история А>>Удалось ли довести игру до ума и продать ее? А>>Если да, поделитесь пожалуйста впечатлениями.
R>Да пока ничем. Слишком много проектов висит, а это — "для души", тут суетиться не хочется.
да...дело такое...а проекты денежные?...ладно, я сам лентяй R>Потихонечку переношу исходники под VC++ (они на древнем WATCOM), собираюсь улучшить графику (скорее всего, перенести движок на DirectX).
R>Игрушка-то хоть захватила? Мне интересны мнения других людей.
Игрушка понравилась, но до "захватила" ей еще далеко. Как насчет того что бы сделать под нее сайт, а?
Тогда появится заинтересованная аудитория, отзывы, пожелания....можно даже исходники выложить кто знает что из этого выйдет....вот только после этого на ней не заработаешь...
Вот такие вот размышления.
.
R>Интересует ваше мнение по заданным вопросам.
REtalik я давно скачал твою игру.
Какие в ней глюки тебе уже выложили выше в полной мере.
Я ту дашел до 136 уравня очков около 2млн. жизней 150. потом я забался. а все потому, что как только я появлялся ВСЕ сразу взрывалось.
А вообще мне понравилось. Задумка прикольная.
Прикольно былобы туда еще человечиков впаять с калашами. А танки ездить заставить. А воздух украсить верталетами. Ну в общем творческих успехов.
Жду твоих обновлений.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Рома Мик, Вы писали:
РМ>>Здравствуйте, retalik, РМ>>116 уровень! ~1800000 очков. Слабо?!
A>Тоже поломал?
Да не, зачем? Последние 40 уровней все само взрывалось и я переходил на следующий. Но вот под конец какая-то шилка не взорвалась и стояла так, что я на такой скорости в нее никак не мог попасть, я даже развернуться не мог.
Здравствуйте, Рома Мик, Вы писали:
РМ>Здравствуйте, retalik, РМ>116 уровень! ~1800000 очков. Слабо?!
Крут
Если склероз не изменяет, я за сотню тоже переваливал. Там действительно главное — до противоположного конца экрана долететь, scorched earth
).
