Войти
ФлеймФорумПроЭкты

Царство небесного камня (sim online game) (13 стр)

Страницы: 110 11 12 13 14 15 Следующая »
#180
22:14, 20 янв. 2018

// ---
Надо осторожней с дропом аля кровь или мясо.

Как-минимум, не надо внедрять в игру навыков аля _шкуродел и подобное.

Некий дроп мяса, связан с квэстом _мясо_для_поварихи.

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

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

Так мы слегка избавляемся от образа дикости, подразумевая, что игрок таскает
мясо в упаковке ... Не исключаю, что новый стак мяса получает метку времени,
и через сутки (или двое) само-исчезнет из рюкзака.

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

Если не иметь квэста на сбор мяса, но иметь стекло-банки - будет-ли дроп мяса ?
Вероятно, мясо не будет выпадать ...
? Маразматично ?
Пофигу.

Если тебе какой-то алхим рецепт требует мясо ...
Надо как-то избегать придумывания таких рецептов - пусть квэст поварихи дарит
игроку разные мясные расходники, аля котлеты, а сам игрок не умеит готовить такое.

Тоесть, чтобы траво-ядные игроки не попадали под явное давление, мол
здесь заставляют _бить мясо, чтобы готовить мясо, чтобы жрать мясо ...
Достаточно того, что можно купить для героя мясную жратву у некоторых купцов,
либо получить мясные блюда за квэст поварихи.


#181
22:38, 21 янв. 2018

// как я понимаю _игру и _деньги..

Игра - это эмоция, результат (числа),
или развлечение (отвлекаемся от дел).

Многие игроки строят ложное трактование слова _игра, подпитывая
такими баснями своё нытьё (давление на админов).
// Теоритическое взаимо-действо всех игроков на сервере - это одна
// из популярных уловок в устах журналистов, для критики онлайн-игр.

Онлайн-игра не позволяет игроку легко сломать правила игры.
Поэтому форумное нытьё напоминает реконструкцию поведения детей
и родителей, когда малышня перебирает слабые места родителей,
пытаясь выйти на удобный шантаж. Ну а некоторые игроки, пробуют
обхитрить некоторые стандартные слабости _оптимизации_игр.

Свой (или изученый чужой) автономный сервер, трудно подломать.
// Важно, чтобы сервер не позволял-бы дублировать игровые предметы.

Наплодить бесплатные учётные записи игрока (акаунт-кабинет), чтобы
автоматизировать получение каждо-дневных подарков, и хитро фокусировать
выгоду на одном акаунт-кабинете, в обход _привязаных подарков ...
Это пример того, что доброта админов, как язва для их игры.
// Дай игроку проявить себя внутри-игры, а не в около-игровой мухлятине.

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

Оплата, в форме _подписка, подразумевает _платный_доступ в мир игры,
и у админов игры нет обязательств по развитию игры. Некоторые игроки
ложно воспринимают свой платный доступ к игре, как статус вкладчика.
// Меня всегда удивляло, почему любители подписки не верят, что админы
// любой игры могут продавать виртуальное золото, через чёрный рынок.

Любой игровой донат (жертвование деньгами в пользу админов игры),
говорит лиш о том, что игрок захотел оставить админам _позитивный_отклик
на то, как игра, в том виде, какой был на момент доната,
смогла исполнить своё влияние на игрока (дать ему эмоцию,
или результат, или развлечение), тесно связаное с благодарностью.

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

Конечно, среди игроков могут быть _шпионы из фирм-конкурентов,
чтобы их острое нытьё правильно влияло на некоторых игроков, ради
выбивания этих игроков в сферу поиска нового проекта.
Хотя, сговор админов всегда выгодней, чем подсирание друг-другу.

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

#182
23:31, 29 янв. 2018

// мнимый интелект

Получить ресурсы == удовольствие., потратить ресурсы == удовольствие.

агент_разумности
{
1. владение узловой системой виртуализации на основе игровой механики.
2. часто - опознование-опрос своего состава, и грани _внешнего_себя.
3. редко - познование _внешнего_себя в пирамиде власти (других себяев).
4. интервал свободный - получение ресурсов (включая внутри себя).
5. интервал свободный - охрана-трата ресурсов (включая внутри себя).
}
// знания == ресурс.

Игровая механика, чтобы имитировать агента_разумности.
ИЛИ
Игровая механика, чтобы просить денег у игроков. // разработчики выбирают лиш этот вариант

Понятно, что механический интелект никогда не будет создан.
Суть всегда в моменте перетекания _изначального_интелекта из одного состояния в другое.

Ну и какая-то романтика про то, что пирамида власти обязательна для _разума
(и его биологических визуализаторов).
Тоесть, либо монополия (и разум), либо ничто (и космос).

На этих вымыслах можно базировать внутри-игровой драматизм и литературу ...

#183
23:55, 5 мар. 2018

Как достигнуть качества без затрат ?
Отдать игрокам _строить мир игры ?
Усвоить какие-то хитрые приёмы ?

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

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

// Игра по приборам ...
Почти все современые онлайн-эрпэгэшки. гы-гы.
Тоесть, тамошнии красивые картинки _оторваны от чисел,
которые тотально влияют на результаты действий.
Но без картинок, люди не хотят играть в числа.
Такие пироги.

// Клоны и привычные модельки - игрок их уже насмотрелся ...
Я считаю, что это грубое мышление без разумного выхлопа.
Если автор игры заявляет нечто в таком духе, то он сам себя не видит,
либо лукавит, чтобы устроить спорную ситуацию.
Хотя, это можт быть правильный само-гипноз художника, мол моя рука
будет узнаваема, и кто-нибудь мне подаст в неё _вектор_денег.
Возможно, это некая борьба с мыслью о том, что ты _обычный.
Заглушать свою проблему не-уловимыми образами, вместо творчества.

#184
15:52, 6 мар. 2018

slatazan
> агент_разумности
> :)
> 1. владение узловой системой виртуализации на основе игровой механики.
мог бы уже сам какую-нибудь виртуальную систему смастерить
чтобы там в числах и в тексте как в матрице показывало на сканерном экране
допустим перс и состав его связей : непосредственной групыы участников компании
и его связи вроде Лога с торгашами крафтерами и прочими дабы вкурить во все это
.. вводишь запрос и выскакивает лист таблица по персам пишешь имя перса и его связи
типа языка терминального ввода : вводишь список терминов которые по запросу хелп ищуться
и весь список можно пролистить

slatazan
> Отдать игрокам _строить мир игры ?
> Усвоить какие-то хитрые приёмы ?
> // Пустые стены коридоров ...
вот именно что в Героях 3 и далее Карт было напилено орда их толпу , блт
и где это все - нихт где все закончилось на WOG Heroes тотже продвинутый Heroes 3
зачем какие пустые стены пойми откуда взявшихся  корридоров когда карта уже с реками и замками горами

slatazan
и каждая последующая выпущенная версия представляла из себя
вовсе не предыдущую игру , а новый полу-трешак в смысле
что эти икс-боты из потустороннего мира лепили это все по единой концепции
но без того чтобы изучить предыдущие версии : по-сути должен был быть апгрейд
но итогово даже предыдущая прогрессия слилась и не проявилась в последующих версиях
то есть все как начальная заготовка и все каждый раз заново :
каждая версия next gen ничего не знала о предыдущей и лепила , и лепила гробатого далее
(какие где новые игры в инете - бред в реале - все даже хуже старого , ржа)

slatazan
> Тоесть, коридоры оживают рядом с игроком, и в голове игрока.
> Что-то проявлено _под_игроком (шантаж-ловушка), что-то сгенерено на пути.
есть жанр квест-текстовых игр
и там вот твое описание : осмотреться -> вы видете пару выходов на севере и на западе
оглядеться -> вот какой-то ключ валяется возле камня -> подойти к камню -> поднять ключ
внимательно осмотреть ключ -> ваше чутье говорит что оно явно от chest -а
подумать где chest -> интеллект героя подсказывает что где-то рядом в пещере
взглядом искать пещеру -> вы видите какой-то кусок шпиля горы за лесом
идти к лесу -> войти в лес -> приключения в лесу -> выход из леса -> подойти к горе
оглядеть гору -> в нашли вход в пещеру -> зайти в пещеру -> вот похоже лабиринт
приключения в лабиринте -> вы нашли chest -> о удача ключ подошел
заглянуть в сундук -> там меч кладенец -> забрать меч -> меч забран
повесить меч за спину -> меч у вас на спине -> выйти из лабиринта -> кажется вы заблудились
Epi End

slatazan
отпишу еще потом , ибо не все сразу ж (прочесть хоть что-то в теме нужно)

#185
19:07, 10 мар. 2018

Morphia
Возможно, я мутно выразился про искуственую разумность..

_узлы == ноды (принадлежность свойств)

_виртуализация == копия личности и куска мира для вычислений.

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

Игро-делы близко к теме построения стандартов виртуализации.

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

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

#186
19:24, 10 мар. 2018

Morphia
// само-дельные поля сражений
Сейчас, обороты казуальности в том, чтобы удобная само-дельность была частью автора.
Тоесть, сами авторы игры занимаются само-деятельностью, поверх асетов _пустых_стен.
// Тоесть, вытягивание само-дельности на уровень профи ... и проваливание профи к пустоте.
И это - нормальный ход эволюции - сэмплирование.
Если смотреть на развитие популярной музыки, то там _сэмплирование,
в какой-то момент, сожрало всех авторов.
Ди-джэй получил полное равенство с _авторами.

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

#187
(Правка: 13:57) 13:55, 11 мар. 2018

slatazan
> ход эволюции - сэмплирование.
> Если смотреть на развитие популярной музыки, то там _сэмплирование,
> в какой-то момент, сожрало всех авторов.
> Ди-джэй получил полное равенство с _авторами.
это правда только наполовину
потому как музон из сэмплов по-сути компилируется на ходу в ран-тайме
а для проекта уже такое не катит - здесь музон должен быть скомпилирован до того как
иначе нужны большие мощности и все равно это может быть с залипаниями и
вкупе с агрегативной структурой приаттаченой к проекту вроде муз_базы с проигрывателем
короче надстройка которую еще нужно настраивать все равно (кто это будет делать)

slatazan
> Morphia
> // само-дельные поля сражений
> Сейчас, обороты казуальности в том, чтобы удобная само-дельность была частью
> автора.
> Тоесть, сами авторы игры занимаются само-деятельностью, поверх асетов
> _пустых_стен.
> // Тоесть, вытягивание само-дельности на уровень профи ...
скорее необходимо создать правила по которым юзеры смогут клепать карты сами
уже в Редакторе Карт : но это потянет за собой содержание он-лайн БД Карт
и еще кучу вроде проверок на валидность карт их соответствия правилам для контр-багования

#188
18:43, 24 мар. 2018

// велосипедная пыль

В лог-файле mainserv.txt напечатано
sizeof t_vis_screen1_item: 85

В лог-файле subsrv01.txt напечатано
sizeof t_vis_screen1_item: 85

В лог-файле Визуализатора напечатано
sizeof t_vis_screen1_item: 96
Это понятно - упаковка свойств на усмотрение компилятора ...
Компиляция модуля _под_проект, вместо того, чтобы считать модуль
чем-то единым-внешним не-повторимым, одинаковым для всех.
Вероятно, так можно сделать, но у меня мало знаний.

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

Вероятно, с восприятием игр - похожая ситуация, и дизайнеры вынуждены
казуалить и затуплять свои представления про то, какой должна быть игра.

// --- целые и дробные числа
// x = ( float( 100 + 0) * 0.01f ) * 20; // 1 * 20
//
// dp.mana_full = FD100( 100 + dp.sunrise_perc) * dp.mana_raw; // result 19

// OR
// dp.mana_full = FD100( 100 + dp.sunrise_perc) * float( dp.mana_raw); // 20

// OR  запихнуть в процу  int imult( float i1, float i2){ return i1 * i2; }
dp.mana_full = imult( FD100( 100 + dp.sunrise_perc), dp.mana_raw); // 20
Ну кое-как приспособился.
Такой я нуб.


// ---
Сейчас тэстирую рынок - выставляю товар на продажу, и ...
центральный сервер падает - кто-бы сомневался. Но не буду унывать.

#189
20:08, 1 апр. 2018

// --- убойный отчёт о завершэнии работы по теме рынка в игре.
Механизм рынка был придуман, исполнен, и ... захромал.
Были найдены-исправлены несколько ошыбок.
// Среди них, старая больная тема _номерки_против_офсетов.
// Если язык програмирования позволяет _юзать_офсеты, то
// это язык НЕ высокого уровня, а лиш версия асемблера, или типа того.


// ---
Рынок (техническая проводка) (этот текст помогал искать ошыбки).

Чтобы началась торговля, некий игрок должн выставить товар.
Для этого надо.. включить окно фамильного склада,
отметить товар без привязки, как избраный,
и кликнуть на свободном слоте витрины = Визуализатор::RTK_SkyVitrajSlot.
Будет послан сигнал.. sig_buf_add( sig_vitraj_torg, номер_1_6,  0.f, 0.f, 0.f);

// Сделал Ветку и Гриб, чтобы их можно было выставлять на рынок.

Саб-сервер принимает sig_vitraj_torg в процу t_unit::try_kmd_with
и переводит стрелку на процу sig_vitraj_kno__proc,
Внутри сделают перевод номера витрины в офсет.
Откат клика i148_tool_market прерывает процу - печатаем это в лог-файл.

При нормальном ходе, вызываем решаюший этап обработки сигнала от игрока..
sig_vitraj_kno__proc_priv
else if( z  as  sig_vitraj_torg ) // вот наш кейс
И если p_item_sel можно выставить на рынок, то находим пустой слот склада,
и переносим предмет в тот слот. Нагло меняем у предмета rec.sh_nom_base,
а оригинальный номерок сохраним в свойстве витрины.
// _сломаный_предмет, чтобы избежать дублирования предметов.
p_vitr->oper_for_slot = -sig_vitraj_torg; // минус, как зацепка отложэного действа.
На этот момент, испортили предмет, и ждём события сохранения героя на центр-сервер.
Если придёт _отмена постановки на продажу, то вернём оригинальный rec.sh_nom_base,
и занолим ячейку витрины (но пока не исключено, что при отмене могут быть ошыбки).

// --- наконец, приходит время сохранить героя..
t_user::save_hero_task
// sig_vitraj_torg_vagon // литературная метка // отложэное действие.
save_hero_task__vitraj_priv // вызываем из-за наличия бита минуса в oper_for_slot
Пополняем буфер задачи сохранки инфой _вагончика о предмете, который выделен
из обшей кучи склада, чтобы он отдельно попадал под сканирование по теме рынка.
Части вагончика..
1. Визуальная инфа правильного предмета (починили на момент считки свойств).
2. Средняя инфа про вагончик (включив Цену, которую надо иметь покупателю).
3. Динамическая часть свойств предмета (с правильным sh_nom_base).
Буфер задачи само-отправлен на центральный сервер ...


// --- приём сохранки героя..
mainserv1:: task_upd__user_save_all
for( int i = 0; i < slots_in_vitraj__max; i++)
Считываем из буфера, делаем правильное имя файла, и сохраняем вагон, как файл.
Далее, подобные вагоны сканирует проца (примерно раз в 5 секунд)
an_update__market_list,
чтобы составить список товаров, которые доступны покупателям.
Вносит маленькую путаницу проца
an_update__market_done,
которая подразумевает фазированое продвижэние конвеира товаров, которые _готовы.
// Тоесть, за несколько вызовов, некий товар проходит стадии готовности,
// чтобы вагончик (товар или заказ на товар) вернулся в _сохранку_героя.

Важно, что лиш вагончики с товаром играют опорную роль на рынке.
Вагончики заказов на товар, как вторичные элементы, которых будут искать,
когда товар снимет с себя длительное карантин-ожыдание, которое придумано для
избавления от ботов, которые сканируют рынок и мигом скупают товары от
новых игроков, которые не привыкли к ценам, и выставляют самую низкую цену ...
Вобшем, товар обязан лежать на рынке около суток - этот товар внедряют в список,
и этот список посылают всем саб-серверам, если есть хоть один товар на продажу,
// net1_step__send_market__try
чтобы каждый саб-сервер отправлял копию списка тем игрокам,
которые начали разговор с рыночным купцом в столичной локации
(либо с Агентом 111, для тэстирования).

// --- subserv1
В диалоге купца, была кнопка-тулса i148_tool_market
и мы кликнули её --> subserv1:: try_kmd__vendor_klik
subserv1:: hero_tool_market_list


// --- визуализатор
resolve_market_list // проца приёмки списка.
mrkt_shcut_mas[] // заполняем масив визуал-ярлыков, чтобы видеть свойства товаров.
// t_mrkt_reader  помогает держать строй, если надо добавить свойства.
RTD_SkyMarketLot // рисуем товары.
RTK_SkyMarketLot // попытка обработать клик, который выбирает товар для покупки.
Из номера строки, получаем _номер_продавца, и офсет витрины продавца, где товар.
Эти два числа пересылаем на саб-сервер с меткой sig_vitraj_kupi (заказ товара).
Здесь можт быть ошыбка, если список товаров обновился, в момент клика.
Но заказ на покупку можно отменить, когда увидим, что товар не тот.
// В конце концов, это игра, и уместны всякие нежданчики.


// --- subserv1
Саб-сервер принимает сигнал о жэлании покупки товара
t_unit::try_kmd_with, sig_vitraj_kno__proc, sig_vitraj_kno__proc_priv
else if( z  as  sig_vitraj_kupi ) // вот наш кейс
Нарушаем изначальное пред-назначение свойств ячейки витрины,
и вносим туда два числа, чтобы отложыть действие до момента _сохранки.

t_user::save_hero_task, save_hero_task__vitraj_priv
else if( vitraj.oper_for_slot  as  -sig_vitraj_kupi__pre_vagon ) // вот наш кейс
Читаем список товаров. Найдя нужное сходство, получаем t_vis_screen1_item,
который нам нужэн, чтобы дополнить полноту файла-вагончика.
Буфер наполняем инфой о вагончиках, а потом и о других свойствах героя,
и отправляем на центральный сервер.

// --- приём сохранки героя..
mainserv1:: task_upd__user_save_all
for( int i = 0; i < slots_in_vitraj__max; i++)
Считываем из буфера, делаем правильное имя файла, и сохраняем вагон, как файл.
Далее, эти вагончики заказов принимают участие в поисках связей с готовыми лотами
an_update__market_done
Вдобавок, есть метка для поиска _lot_done_tail.

// Тэст.. Надо остановить сервер, прибавить сутки в конфиг, и запустить снова.
Обший смысл таков - помимо определения списка товаров, просмотр всех кабинетов
даёт шаговую продвижку товара, который надо кому-то отдать, когда спадёт карантин.
Поэтому крутим все такие товары из накопителя, и проводим операцию, которая нужна
товару, под фазу готовности товара. Важны три стадии, которые финалят товар..
= lot_stad__fin_back // возврат
= lot_stad__fin_one // один покупатель
= lot_stad__fin_rand // рулетка-розыгрыш, среди покупателей

В любом случии, вагончикам заменят имена, добавив букву, чтобы отличать-зацепить,
когда игрок загрузит героя (например, сменит героя или войдёт в игру _снова).

Можно придумать, чтобы сработало в момент получения сохранки от саб-сервера,
но пока надёжней заново загрузить героя..
try_load_prop
if(1) // вагончики
Проходим по всем ячейкам витрины и создаём имена _вагончиков_возврата,
чтобы учесть _товары и _заказы (и можт быть ешё какой-то тип вагончиков будет).
И если удалось прочитать файл, то его считываем в спец-переменки, а потом,
попытка использовать эти переменки, чтобы залить поверх загружэной инфы
в нужный слот фамильного склада, и поправить ячейку витрины, мол витрина недавно
сработала - можно брать результат (или возврат денег, или возрат товара).

Тоесть, важно оставить _отметину события, чтобы игрок понял что произошло.
А ячейка фамильного склада будет содержать товар (вернули, или купили)
или спец-предмет i300 с запасным свойством (деньги, которые пойдут в счётчик).
// Имея ограничитель денег и _статистику, нужно делать возврат денег в счётчик
// от клика игрока, с пред-остережэнием о проблемах ограничителя - можно оставить
// спец-предмет в слоте склада, и взять его деньги после каких-то трат денег.
mb.vagon_vitraj

Важно, что мы делаем сохранку mix_box_save, и стираем прочитаные отдельные файлы.
На саб-сервер, летит такая сохранка, которая приняла в себя все перемены.
Игроку осталось кликнуть по ячейке витрины - ему проявят мини-окно,
(поверх витрины, чтобы слоты склада были видны) где будет инфа о событии,
и будет проведена стрелка до слота склада, который до сих пор связан с витриной.
// Пока без этих стрелок обойдёмся ...
Жмём в окне _ладно, и ячейку витрины заноляют - она стала пустой.
// Товар оставят.
// Предмет с деньгами удалят, а деньги добавят в статистику _рынок.


// ---
Тэстовая торговля удалась. Но есть обломчик, который не влияет, вроде-бы..

Центр-сервер выдал..
MoveFile: /server/real/players/11/2t --> /server/real/players/12/0tv
MoveFile: /server/real/players/12/0z --> /server/real/players/11/2zv

Err lot-file (on lot_stad__fin_back):
D:/king-sky-stone2/server/real/players/11/2t

Err lot-file (on lot_stad__fin_back):
D:/king-sky-stone2/server/real/players/11/2t

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

#190
18:14, 7 апр. 2018

Я давно хотел сделать графон _без_текстур (возможно печатал где-нить).
Но у меня никогда не ладилось с графикой (а может и со всем остальным тоже).

Смысл таков..
Модельки нужно делать из заготовок (кубиков и прочих примитивов),
у которых легко авто-генерировать равно-мерные текстурные координаты,
чтобы эти заготовки принимали на себя Материал (закольцованая текстура).

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

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

Вобшем, мутная идейка, и требует сделать мини-редактор.

И вдобавок, висит проблема текстурирования гипотенузы.
Тоесть, максимальное искажение-растяжение материала на срезе кубика.

#191
0:25, 21 апр. 2018

Создал процу генерации кубика, который нужен для редактора по созданию кубичных моделек.

// 6 граней - 6 мешков - 6 пресетов направления вытяжки новых кубиков
//
t_Node  geogen_box6( int mater, t_Node par, int ext_id)
{
  t_ModelGen* g = &ModelGen; // учитывая, что нет паралельных вызовов

  g->BeginModel( par);

  float l = 1.0f;
  float o = 0.0f;
  float h = 0.5f; // сдвиг от пивота

  // --- грань
  int Zp_1, Zp_2, Zp_3, Zp_4;
  g->new_vert( Zp_1, h, h, h,   l, l); // i, x, y, z, u, v
  g->new_vert( Zp_2, h, -h, h,  l, o);
  g->new_vert( Zp_3, -h, -h, h, o, o);
  g->new_vert( Zp_4, -h, h, h,  o, l);

  g->make_face( Zp_4, Zp_3, Zp_1); // триуг
  g->make_face( Zp_1, Zp_3, Zp_2);
  g->RegMesh( mater, "B6_Zp", 1); // зарегить меш // зэд-позитив
  g->AfterRegMesh( o, o, o);

  // --- грань
  int Zn_1, Zn_2, Zn_3, Zn_4;
  g->new_vert( Zn_1, -h, h, -h, l, l);
  g->new_vert( Zn_2, -h, -h, -h, l, o);
  g->new_vert( Zn_3, h, -h, -h, o, o);
  g->new_vert( Zn_4, h, h, -h, o, l);

  g->make_face( Zn_4, Zn_3, Zn_1);
  g->make_face( Zn_1, Zn_3, Zn_2);
  g->RegMesh( mater, "B6_Zn", 1); // зэд-негатив
  g->AfterRegMesh( o, o, o);



  // --- грань
  int Xp_1, Xp_2, Xp_3, Xp_4;
  g->new_vert( Xp_1, h, h, -h, l, l);
  g->new_vert( Xp_2, h, -h, -h, l, o);
  g->new_vert( Xp_3, h, -h, h, o, o);
  g->new_vert( Xp_4, h, h, h, o, l);

  g->make_face( Xp_4, Xp_3, Xp_1);
  g->make_face( Xp_1, Xp_3, Xp_2);
  g->RegMesh( mater, "B6_Xp", 1); // хикс-позитив
  g->AfterRegMesh( o, o, o);

  // --- грань
  int Xn_1, Xn_2, Xn_3, Xn_4;
  g->new_vert( Xn_1, -h, h, h, l, l);
  g->new_vert( Xn_2, -h, -h, h, l, o);
  g->new_vert( Xn_3, -h, -h, -h, o, o);
  g->new_vert( Xn_4, -h, h, -h, o, l);

  g->make_face( Xn_4, Xn_3, Xn_1);
  g->make_face( Xn_1, Xn_3, Xn_2);
  g->RegMesh( mater, "B6_Xn", 1); // хикс-негатив
  g->AfterRegMesh( o, o, o);



  // --- грань наверху
  int Yp_1, Yp_2, Yp_3, Yp_4;
  g->new_vert( Yp_1, h, h, -h, l, l);
  g->new_vert( Yp_2, h, h, h, l, o);
  g->new_vert( Yp_3, -h, h, h, o, o);
  g->new_vert( Yp_4, -h, h, -h, o, l);

  g->make_face( Yp_4, Yp_3, Yp_1);
  g->make_face( Yp_1, Yp_3, Yp_2);
  g->RegMesh( mater, "B6_Yp", 1); // угрик-позитив
  g->AfterRegMesh( o, o, o);

  // --- грань снизу
  int Yn_1, Yn_2, Yn_3, Yn_4;
  g->new_vert( Yn_1, h, -h, h, l, l);
  g->new_vert( Yn_2, h, -h, -h, l, o);
  g->new_vert( Yn_3, -h, -h, -h, o, o);
  g->new_vert( Yn_4, -h, -h, h, o, l);

  g->make_face( Yn_4, Yn_3, Yn_1);
  g->make_face( Yn_1, Yn_3, Yn_2);
  g->RegMesh( mater, "B6_Yn", 1); // угрик-негатив
  g->AfterRegMesh( o, o, o);


return g->EndModel( "TestBox6", "TestBox6Geo", ext_id);
}
#192
23:11, 5 мая 2018

Абилки (приёмы обшие).
Умелки (приёмы типажа героя).

Можно оформить парные комбо-варианты (а + б = в).
Это позволит сократить колво прожымаемых ярлыков-кнопок,
что снимет _загромождение экрана, и сделает игру чуть глубжэ.

Дву-комбы, которые близки к типажам героев, склеить с умелками..

Выставляем использование любой _абилки в карман (номер в спец-переменку).
А если идёт использование _умелки, то поиск сочетания абилки из кармана
с этой умелкой - если такой кейс находим, то умелку не исполняем - вызов
некой спец-абилки, которую нельзя вызвать _напрямую, одним кликом.
// Использование умелки, и выход из состояния боя = занулить карман абилки.

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

// Оплата комбо-абилки - её не должно быть, но умелка должна тратить своё.
// Вероятно, надо делать костыль - проверка использования умелки должна
// проходить - ману потратим, но подменим указку на процу исполнения умелки.
// Поэтому, все эти технические комбы обязаны быть вне-зависимостей,
// и не требовать уникальных параметров.

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

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

Гром-телепорт..
Главное - оборонительный смысл. После использования, можно разорвать дистанцию,
чтобы монстры исчезли - например, начался не удобный бой.
Если монстр был один, и если он возник, как сюрпризный, то ... смены места
не должно происходить - монстр тупо исчезает, и не нужно искать _громо_отводы.

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

Добавочное - для заскучавших игроков - в какую сторону меня направит случий.

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

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

#193
1:02, 6 мая 2018

slatazan
> // угрик-позитив

это прекрасно

#194
1:13, 26 мая 2018

Кое-как осилил сделать редактор лепки кубиков со срезом
(4 нижних среза = 12 15 18 21 = шифровка на циферблат часов)
(4 боковых = 14 16 20 22)
(4 верхних = 24 30 36 42 = удвоеный нижний вариант)
(11 = полный нормальный кубик).

Текстовой (воксель) формат промежуточного сохранения.
Пример псевдо-шарика 3х3..

Ku_Model_Name

// мэпинг 9 материалов (местный индекс = глобальный индекс материала)..
1 1
2 3
3 2
4 4
5 5
6 0
7 0
8 0
9 0


3 3 // хикс слева-направо // зэд сверху-вниз
3 // et_klv

2 2 // x z
2 // y // номер-место центр-кубика

0.10 // масштаб-умножытель, учитывая тайл в 10 метров.



ETAJ:
3 // номер этажа
00 0   24 5   00 0   // fprintf( f, "%02d %d \t", preset, m);
42 5   11 3   30 5   
00 0   36 5   00 0   


ETAJ:
2 // номер этажа
22 4   11 3   14 4   
11 3   11 1   11 3   
20 4   11 3   16 4   


ETAJ:
1 // номер этажа
00 0   12 2   00 0   
21 2   11 3   15 2   
00 0   18 2   00 0   

Если вникнуть в числа шифровки, то можно лепить простые кубики в блокноте.

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

Тайл в 10 метров - это обманчиво, потому-что в такой размер уместим
размах плечей элитного монстра, либо два размаха плечей героя.
Поэтому 3 на 3 кубика - это примерный глаз героя (распухшая голова, к телу).

Наметил пробу _сапога от центрального профиля - прям фрегат какой-то. гы-гы.
(20 кубиков-этажэй, 15 кубиков длина лодки-подошвы).

Страницы: 110 11 12 13 14 15 Следующая »
ФлеймФорумПроЭкты