Среда, 29 Мая 2024, 10:21

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 1 из 1
  • 1
Способы реализации внутриигрового времени
SufirДата: Среда, 29 Сентября 2010, 19:06 | Сообщение # 1
частый гость
Сейчас нет на сайте
Приветсвую уважаемое сообщество!

Возник такой вопрос. Как реализовать внутриигровое время в браузерной игре (средствами PHP+MySQL)?

Нужно сделать в игре "собственное" время, скорость тесчения которого будет в 10-20 раз выше реальногого. Ну к примеру там "19:20 3-й Луномесяц 815-го года Эры дракона" для фэнтези или "23:01 23 февраля 3015г." для футуристического сеттинга. Нужна не чисто эстетическая возможность, а реальная функциональность, что бы использовать это время для всех расчётов вроде времени квеста. Есть пара мыслей, но они либо неуниверсальны и нефункциональны, либо громоздки и ресурсоёмки, что непозволительная роскошь.

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

Сообщение отредактировал Sufir - Среда, 29 Сентября 2010, 19:07
fenix4Дата: Среда, 29 Сентября 2010, 20:36 | Сообщение # 2
участник
Сейчас нет на сайте
Интересно сейчас что то придумаю

Добавлено (29.09.2010, 20:36)
---------------------------------------------
Так сегодня будет тебе скрипт 1 минута идет 10 секунд так нормально ?

gra4Дата: Среда, 29 Сентября 2010, 20:37 | Сообщение # 3
уже был
Сейчас нет на сайте
Code
<?
$created = 1285774875;
echo $created." - unix timestamp, constant of world creation<br>\n";
echo time()." - unix timestamp, current<br><br>\n";

$world_time = time()-$created;
echo $world_time."- seconds from world creation<br>\n";
echo ($world_time*10) ."- virt seconds from world creation<br>\n";
echo "Real time from creation - ".make_diff($world_time);
echo " Virt time from creation - ".make_diff($world_time*10);

function make_diff($stamp){

$seconds_in_a_year = 3600 * 24 * 365;
$years = floor($stamp / $seconds_in_a_year);
$rest = $stamp % $seconds_in_a_year;

$seconds_in_a_month = 3600 * 24 * 30;
$months = floor ($rest / $seconds_in_a_month);
$rest = $rest % $seconds_in_a_month;

$seconds_in_a_day = 3600 * 24;
$days = floor ($rest / $seconds_in_a_day);
$rest = $rest % $seconds_in_a_day;

$hours = floor ($rest / 3600);
$rest = $rest % 3600;

$minutes = floor ($rest / 60);
$rest = $rest % 60;

$seconds = $rest;

return "$years years, $months months, $days days, $hours hours, $minutes minutes and $seconds seconds<br>\n";

}
?>
fenix4Дата: Среда, 29 Сентября 2010, 20:51 | Сообщение # 4
участник
Сейчас нет на сайте
ну во не буду себе голову ломать тебе помогли !
anisimovДата: Среда, 29 Сентября 2010, 22:52 | Сообщение # 5
старожил
Сейчас нет на сайте
А обязательно считать время квеста из привязки к игровым суткам. Ведь сутки виртуальные масштабные, а единицы времени реальные, так что универсальное решение по сути одно для квестов на время. Запускаем таймер по некоему событию, например в SilkRoad есть такой момент, надо поймать определённого монстра, и на время привести его к Неписю Ведьма Заката. Ловить можно сколько угодно, а вот когда монстр пойман начинает тикать таймер. Ксати, а при чём MySQL Миска нужна для оперирования с базами данных, а для работы с квестовым таймером он не нужен. Таймер можно написать на клиентском языке типа Явы, ведь что такое Браузерная Игра "без деления по типам". Это по сути разновидность сайтов.

http://vkontakte.ru/id56359373
Строю Город, обустраиваю Остров. Присоединяйтесь.
SufirДата: Четверг, 30 Сентября 2010, 10:26 | Сообщение # 6
частый гость
Сейчас нет на сайте
gra4, большое спасибо. Это то что мне нужно. Я совершенно забыл про деление по модулю - горе программист, потому и получалось у меня громоздко... Есть свои минусы в данной системе - отсутсвие учёта високосных годов и разной длинны месяцев. И месяцы/дни он возвращает начиная с 0, поэтому нужно использовать не floor, а ceil для их округления. И длинну года нужно брать соответсвенно 360, а не 365, т.к. 365 на 30 не делится и у нас выползет в данном случае лишний 13-й месяц. Но для моих целей это именно то что нужно - беру.

anisimov, MySQL, тут в принципе не причём, однако время хранится в таблицах базы и не только для квестов, поэтому желателен формат удобный для использования в MySQL. Привязывать "к игровым суткам" конечно не обязательно, но в моём случае крайне желательно, у меня не только квесты но и ещё много чего будет на игровом времени заваязано.

Ну, и собственно я предлагаю не только и не столько помочь мне с решением, а делиться опытом и мнениями в данной теме. Мало ли, кому-то ещё понадобится решить подобную проблему.

Есть ещё такой вариант: умножить текущий timestamp на коэффициент ускорения и с полученным числом можно работать стандартными средствами PHP. Это удобно и просто, но имеет ограничения в годах.

Code
date( "H:i d M 19xx", time() * 10 )


Сообщение отредактировал Sufir - Четверг, 30 Сентября 2010, 18:42
lvovandДата: Четверг, 30 Сентября 2010, 11:31 | Сообщение # 7
старожил
Сейчас нет на сайте
набери echo date( 'H:i d M Y', time() * 10 ); результат удивит
макс время в unixtime 19 января 2038 года, так что с коэф. 10 ничего не выйдет


Разработка и продвижение сайтов. Дизайн
SufirДата: Четверг, 30 Сентября 2010, 12:09 | Сообщение # 8
частый гость
Сейчас нет на сайте
lvovand, не удивит, я в курсе - показал только принцип, потому и говорю что функциональность крайне ограниченная. Разжую по полочкам, набери:
Code
echo date( "H:i d M 19xx", mktime( date("H"), date("i"), date("s"), date("n"), date("j"), 1970 ) * 10 );

результат удивит. Но! Функциональность конечно же будет ограниченная из-за ограничений unixtime. Зато расчет максимально близкий к реальному с учётом високосных годов и разной длинны месяцев.


Сообщение отредактировал Sufir - Четверг, 30 Сентября 2010, 12:12
lvovandДата: Четверг, 30 Сентября 2010, 12:53 | Сообщение # 9
старожил
Сейчас нет на сайте
средствами MySQL можно играться, например, взять за основу отсчета виртального 3000 год, реального 2010 год, смотреть разницу в реальном времени, скажем прошел час, значит прибавить к виртуальному один день, DATE_ADD в mysql корректно будет работать с датой и после 2038 года, ну вот как то так

Разработка и продвижение сайтов. Дизайн
SufirДата: Четверг, 30 Сентября 2010, 13:42 | Сообщение # 10
частый гость
Сейчас нет на сайте
Cредствами MySQL несколько не рационально, лишние запросы к базе и их усложнение - лишняя нагрузка.

Сообщение отредактировал Sufir - Четверг, 30 Сентября 2010, 13:43
lvovandДата: Четверг, 30 Сентября 2010, 13:53 | Сообщение # 11
старожил
Сейчас нет на сайте
да какое уж особое усложнение, запрос, который не затрагивает даже таблицы и выполнится за тысячные или десятитысячные доли секунды? ну так средствами php тоже придется расчеты вести и тоже нагрузка и тоже время будет занимать

Разработка и продвижение сайтов. Дизайн
SufirДата: Четверг, 30 Сентября 2010, 14:50 | Сообщение # 12
частый гость
Сейчас нет на сайте
Усложнение я имею в виду тех запросов которые будут работать со временем. Например когда будем брать из базы информацию о квесте, мускулю придётся не только выдать время но ещё и расчитывать, пусть и не значительное усложнение. Да и не хочется дёргать мускул когда нужно просто вывести текущее виртуальное время, к пимеру. Ну, а в целом как вариант надо рассмотреть, просто как-то не думал о мускуле в таком ключе, хотя его либеральность в работе с датами даёт определённый простор.

Сообщение отредактировал Sufir - Четверг, 30 Сентября 2010, 16:12
lvovandДата: Четверг, 30 Сентября 2010, 15:24 | Сообщение # 13
старожил
Сейчас нет на сайте
текущее время мускулом и не нужно дергать, только расчеты с прибавлением/вычитанием виртуального времени, не было бы проблемы 2038 года все было бы проще ))) а так по-любому усложнение будет, либо мускулу, либо php, так как свои функции расчета времени писать придется

Разработка и продвижение сайтов. Дизайн
  • Страница 1 из 1
  • 1
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг