Способы реализации внутриигрового времени
| |
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, так как свои функции расчета времени писать придется
Разработка и продвижение сайтов. Дизайн
|
|
| |
|