forum.boolean.name - [TrueHorror] - разработка

forum.boolean.name (http://forum.boolean.name/index.php)

- Проекты C++ (http://forum.boolean.name/forumdisplay.php?f=56)

- - [TrueHorror] - разработка (http://forum.boolean.name/showthread.php?t=17293)

Ответ: [TrueHorror] - разработка

Кажется прошел, если концом считать вылетание из тоннеля в пустоту.

Ну явно не 60%, иначе итоговый вариант игры будет весьма убогим.

* Короче первым делом нужно обратить внимание на физику персонажа - перемещение очень неудобное, перс постоянно цепляется за камни, шпалы, крышу (нету приседания?) и другие предметы.
* Сенса странно высокая, с большим шагом, я выбирал между 5.0 и 7.5 и удобный вариант должен был быть где-то посередине.
* Настройки не сохраняются, причем из главного меню, если не начал новую игру, сенса тоже не сохраняется - нужно начать и потом настраивать.
* В целом по дизайну освещения видно что иногда использовался ниже описанный подход, но почему-то не всегда, например дорога до шахты - очень плохое место.

Цитата:

Сообщение от Samodelkin (Сообщение 266564)

Насчет дизайна карты: есть моменты когда настолько темно, особенно когда поворот или угол загораживает освещенную часть, что вообще не видно куда идти и поварачивать. Я думаю нужно сделать больше освещенных участков, и главное чтобы часть пола тоже освещалось. Как бы игрок всегда должен видеть впереди себя участок света куда ему надо идти через тьму. Также важно освещать повороты за которыми не видно освещенных участков. Вобщем одним словом на экране должно что то присутствовать по чему можно ориентироваться в пространстве, за что глаз может зацепиться, иначе просто неприятно управлять становится. Для примера хотябы тот же doom3 взять - там всегда есть огоньки и лампочки вокруг - они не дают реального света но достаточно иноформации о положении игрока в пространстве. К тому же можно подсветить фонарем если что.

(тут имхо еще стоит пояснить что конус фонаря двигается вместе с камерой и таким образом даже ярки фонарь даёт меньше представления о пространственном положении камеры чем совсем неяркие источники света, огоньки, лампочки, но расположенные стационарно, как часть окружения).
* Включение питания перед лифтом сделано криво, надо как-то странно повернуться чтобы его включить.
* Так-же перед лифтом самопроизвольно отключается фонарь.
* Вообще над светом (даже больше над его дизайнерской составляющей) нужно поработать - сделать мягче переход полутени конуса фонаря, сделать блумы от ярких источников (уж hdr необязательно, ладно), может добавить какие-то эффекты линзы, в общем любыми средствами добиваться ощущения того что свет яркий, а шахта тёмная, в общем контраста.

Ответ: [TrueHorror] - разработка

60 процентов я конечно загнул, здесь от силы жалкие 40. Нужно очень много мелких деталей добавить для более цельной картинки. К тому же никак не используется инвентарь.

Вообще я выбрал очень сложный путь - и движок пишу и игру. Причем движок без игры писать не получается - не понятно что вообще нужно будет в движке, поэтому они развиваются параллельно - из-за этого так медленно разработка идет. К тому же я "и швец, и жнец и на дуде игрец" - модели, карты, сюжет, текстурки, движок и прочее прочее лежит на мне. Таким образом я плетусь как черепаха. В принципе, если бы я взял юнити в качестве движка, то 60 процентов было бы уже готово.

Насчет света я согласен, но в то же время встречный вопрос: ты бывал ночью в лесу? Где нибудь в сентябре-октябре, когда охуенно темные ночи. Так вот это пздц, вообще нереально понять куда идешь даже с фонарем.

Цитата:

Так-же перед лифтом самопроизвольно отключается фонарь.

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

Странные баги с физикой постараюсь убрать. Я сам не понял после чего появились эти залипания - буду искать причину.

Управление сделаю поудобнее. И настраиваемое - ну там переназначение кнопок и все такое.

Про HDR. Тут такая же ситуевина как и с деферредом, думал что сложно сделать а в реальности сделал за один вечер( без оптимизаций ). Надо только начать. + сасао надо начать делать.

Напрягает еще и то, что форумчане не тестируют игрушку и не высказывают предложений по её улучшению, ну кроме тебя и еще нескольких ребят( Wegox, Arton ). Возможно я не умею завлекать людей, не выкладываю скриншоты( просто не понимаю за чем? ведь это игра а не кинцо ) или жанр такой, что не каждый хочет мотать себе нервы. В общем не знаю. Из-за этого пропадает желание что-либо делать.

Ответ: [TrueHorror] - разработка

Цитата:

Сообщение от mr.DIMAS (Сообщение 286209)

К тому же никак не используется инвентарь.

Нужно добавить головоломки->появятся предметы для решения этих головоломок->их нужно будет собирать и применять->будет толк от инвентаря.

Цитата:

Сообщение от mr.DIMAS (Сообщение 286209)

Вообще я выбрал очень сложный путь - и движок пишу и игру. Причем движок без игры писать не получается - не понятно что вообще нужно будет в движке, поэтому они развиваются параллельно - из-за этого так медленно разработка идет. К тому же я "и швец, и жнец и на дуде игрец" - модели, карты, сюжет, текстурки, движок и прочее прочее лежит на мне. Таким образом я плетусь как черепаха. В принципе, если бы я взял юнити в качестве движка, то 60 процентов было бы уже готово.

Я тоже так делаю - ты еще забыл написать про тулзы и редакторы всякие. Зато я придерживаюсь точки мнения что движок должен разрабатываться для конкретной игры или заранее планируемый серии игр, он будет проще, понятней, легче и быстрей чем универсальные движки. К тому же очень большой вопрос что этот путь трудней - те кто делает движки и middleware умеет преподнести свою продукцию как простую в использовании, на деле же когда доходит до бетатестирования и разработчикам приходят репорты об ошибках с техническими подробностями движка они ничего не могут толком сделать, либо по причине закрытости, либо просто потому что движок для них так и остался чёрным ящиком. Большие же компании используют движки для быстрого создания прототипа и возможности одновременно приступить к работе программистам и тем кто делает медию, это экономит бюджет. Затем же они либо сами разбирают сурцы движка, либо приглашают людей из конторы разрабатывающей этот движок (ну или используют какую либо другую форму поддержки). В случае же небольших команд, особенно если каждый может и кодить и моделить, вполне нормально сделать свой движок, с возможностями нужными только для целевой игры.

Цитата:

Сообщение от mr.DIMAS (Сообщение 286209)

Насчет света я согласен, но в то же время встречный вопрос: ты бывал ночью в лесу? Где нибудь в сентябре-октябре, когда охуенно темные ночи. Так вот это пздц, вообще нереально понять куда идешь даже с фонарем.

Ну тогда преподнеси это как мини-игру, а не как дизайнерскую недоработку. Или отвлеки внимание - сделай охуенно красивое звездное небо, так чтоб игрок даже не посмел ничего критиковать, или натрави тучи комаров чтобы игрок уже не в состоянии был что-либо критиковать :-)

Цитата:

Сообщение от mr.DIMAS (Сообщение 286209)

Странные баги с физикой постараюсь убрать. Я сам не понял после чего появились эти залипания - буду искать причину.

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

Цитата:

Сообщение от mr.DIMAS (Сообщение 286209)

Про HDR. Тут такая же ситуевина как и с деферредом, думал что сложно сделать а в реальности сделал за один вечер( без оптимизаций ). Надо только начать. + сасао надо начать делать.

ssao вроде не сложно, а вот hdr то очень разный бывает, сделать качественный - не просто, иногда требует переработки большей части рендера. Ну там видно будет когда сделаешь (особо стараться то тоже не надо - главное целостность игры).

Цитата:

Сообщение от mr.DIMAS (Сообщение 286209)

Из-за этого пропадает желание что-либо делать.

Ну тут психология всякая, надо как то мотивировать себя, даже если нет поддержки из вне. Может музон послушать :) или поразмышлять о том какая крутая игра выйдет. С другой стороны нужно понимать что если будешь выкладывать каждый день скрины и демки, то игра будет не интересна никому уже до её выхода.
Вот смотри чел уже несколько лет делает игрулю и вроде выкладывает всякие завлекалки или где-то технические особенности движка описывает, но толком об игре до сих пор не ясно, тем более никаких головоломок и их прохождения не выкладывается.

Ответ: [TrueHorror] - разработка

Сделал сасао. Лепил по статье Борескова. Взял предпоследний шейдер и перевел на HLSL.

Код:

     texture depthTexture;



  sampler depthSampler : register(s0) = sampler_state

  {

     texture = <depthTexture>;

  };



  texture rotateTexture;



  sampler rotateSampler : register(s1) = sampler_state

  {

     texture = <rotateTexture>;

  };



  float4x4 invViewProj;



  float screenWidth;

  float screenHeight;



  float rotateMapWidth;

  float rotateMapHeight;



  float radius;

  float distScale;

  float bias;



  float4 main( float2 texCoord : TEXCOORD0 ) : COLOR0 

  {



     float4    rndTable[8];



     rndTable[0] = float4 ( -0.5, -0.5, -0.5, 0.0 );

     rndTable[1] = float4 (  0.5, -0.5, -0.5, 0.0 );

     rndTable[2] = float4 ( -0.5,  0.5, -0.5, 0.0 );

     rndTable[3] = float4 (  0.5,  0.5, -0.5, 0.0 );

     rndTable[4] = float4 ( -0.5, -0.5,  0.5, 0.0 );

     rndTable[5] = float4 (  0.5, -0.5,  0.5, 0.0 );

     rndTable[6] = float4 ( -0.5,  0.5,  0.5, 0.0 );

     rndTable[7] = float4 (  0.5,  0.5,  0.5, 0.0 );



     float depth = tex2D( depthSampler, texCoord ).r;



     float4 screenPosition;

     screenPosition.x =    texCoord.x * 2.0f - 1.0f ;

     screenPosition.y = -( texCoord.y * 2.0f - 1.0f);

     screenPosition.z = depth;

     screenPosition.w = 1.0f;



     float4 position = mul( screenPosition, invViewProj );

     position /= position.w;   



     float2 rotateMapCoord = float2( texCoord.x * screenWidth / rotateMapWidth, texCoord.y * screenHeight / rotateMapHeight );

     float3 plane = tex2D( rotateSampler, rotateMapCoord ).xyz;



     float attenuation = 0.0;



     for( int i = 0; i < 8; i++ )

     {

       float3 sample = reflect( rndTable[ i ].xyz, plane );



       float2 zSampleTexCoord = texCoord + ( radius * sample.xy ) / position.z;

       float    zSample = tex2D( depthSampler, zSampleTexCoord ).r;



       screenPosition.x =    zSampleTexCoord.x * 2.0f - 1.0f ;

       screenPosition.y = -( zSampleTexCoord.y * 2.0f - 1.0f);

       screenPosition.z = zSample;

       screenPosition.w = 1.0f;



       float4 iPosition = mul( screenPosition, invViewProj );

       iPosition /= iPosition.w; 



       float    dist = max ( iPosition.z - position.z, 0.0 ) / distScale;    

       float    occl = 15 * max ( dist * (2.0 - dist), 0.0 );



       attenuation += 1.0 / ( 1.0 + occl*occl );

     }



     attenuation = clamp ( attenuation / 8.0 + bias, 0.0, 1.0 );



     return float4( attenuation, attenuation, attenuation, 1.0f );

  };

Было несколько непонятных магических чисел, но порыскав по сурсам я понял что откуда идет.

Но результат как-то не очень ( картинка в аттаче результат AO ).

Киньте шейдер AO, который можно перевести ( или уже на HLSL ) без плясок с бубном.

Ответ: [TrueHorror] - разработка

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

Ответ: [TrueHorror] - разработка

Ну хз. Подправил шейдер. В аттаче результат.

Вообще меня как-то не впечатляет графоний вместе с сасао. Жрет много( при 2560х1440 ( на скрине фпс с этим разрешением ) ) а толку как то совсем немного.

Ответ: [TrueHorror] - разработка

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

Ответ: [TrueHorror] - разработка

Цитата:

gl_FragColor

? ну сюда ты обычно цвет и альфу пишешь

Ответ: [TrueHorror] - разработка

вот gl_FragColor = vec4 ( val, 1, 1, val );
когда я беру в следующем проходе из фраментного texture2D().x - будет одно значение, а texture2D().w уже другое.

Ответ: [TrueHorror] - разработка

ну тут я только одну причину знаю - это если у тебя включена sRGB гамма коррекция при записи цвета.
тогда да, цвет будет аппаратно проходить через быстрый pow(rgb, 0.45), а альфа не будет меняться.

Ответ: [TrueHorror] - разработка

А где она может быть включена? Я ничего не писал - открыл пустой шейдер и начал кодить ( в RenderMonkey)

Ответ: [TrueHorror] - разработка

хз, могу только по d3d сказать

Ответ: [TrueHorror] - разработка

переписал на d3d9 - там точно также =)
ты точно уверен что там w записывается не как-нибудь 1/w или 1-(1/w)? =)
я вообще A16B16G16R16F использую, на неё распространяется гамма коррекция?
----
upd:
всё я разобрался - надо было фон в белый цвет очищать просто :-)