Комментарии 15
document.getElementById(«spnCoppersValue»)
1. Зачем вы каждый раз дёргаете document.getElementById? Логичнее было бы вынести все DOM-элементы в константы.
2. Зачем вы используете innerHTML если вставляете строки? Для этого есть более легкий путь — textContent.
document.getElementById(«btnUpgSilverMine»).innerHTML = «Улучшить серебряную шахту, »;
document.getElementById(«btnUpgSilverMine»).innerHTML += silversUpgCost().toString();
document.getElementById(«btnUpgSilverMine»).innerHTML += " серебряных монет";
Зачем вы три раза дёргаете элемент? Это дорогое удовольствие. Логичнее сформировать строку и добавить её готовой:
const btnUpgSilverMine = document.getElementById("btnUpgSilverMine");
// code
btnUpgSilverMine.textContent = `Улучшить серебряную шахту, ${silversUpgCost().toString()} серебряных монет`;
let importString = prompt('Введите длинную строку экспорта');
gameTemp = JSON.parse(atob(importString));
for (var propertyName in gameTemp) { game[propertyName] = gameTemp[propertyName]; }
Зачем тут нужен let, если переменная importString не меняется? Откуда var в цикле? Если уж вы перешли на const-let, о var надо забыть.
onclick в атрибутах выглядит архаично. Я бы заменил на addEventListener.
Замечания по делу, спасибо.
Да, наверное положить объекты в константу и дергать константу лучше было бы.
Второе тоже правильно, обычно я так собираю текстовую переменную из нескольких частей и потом уже собранную переменную присваиваем свойству объекта. Видимо, поторопился и решил пропустить шаг сбора переменной.
var перекочевал из старого проекта, просмотрел.
Да, наверное положить объекты в константу и дергать константу лучше было бы.
Второе тоже правильно, обычно я так собираю текстовую переменную из нескольких частей и потом уже собранную переменную присваиваем свойству объекта. Видимо, поторопился и решил пропустить шаг сбора переменной.
var перекочевал из старого проекта, просмотрел.
А зачем забывать про var?
Что плохого в её применении?
Могу ошибаться, но в данном случае она позволяет не создавать 100500 областей видимости (или не выносить обьявление сётчика на уровень выше).
Или таки есть какой-то вред от неё?
Что плохого в её применении?
Могу ошибаться, но в данном случае она позволяет не создавать 100500 областей видимости (или не выносить обьявление сётчика на уровень выше).
Или таки есть какой-то вред от неё?
Это, конечно, скорее субъективный выбор, но попробую обосновать следующим образом. У var есть свои свойства, например:
- поддержка хойстинга
- scope на уровне функций
У let/const:
- блоковая видимость
- нет хойстинга (но есть TDZ)
Чаще более "предиктивно" работать как раз с правилами чем проще — тем лучше: то есть без хойстинга + чтобы разделение переменных было более простым (например, в цикле свои переменные, в общем потоке свои). Из-за этого иногда удобнее (или даже, возможно, правильнее, чем удобнее) использовать let/const.
Получается, что у вас в коде будут и let и const и var. Поэтому люди предпочитают исключать var для консистентности кода. Есть даже более жесткие eslint-конфиги, где не только var запрещен, но и let.
Использование var — это легаси. Ни один линтер такое не пропустит. А отказаться от него решили, видимо, как раз, чтобы не засорять окружение переменными-счетчиками.
Если вы новичок в js, я бы не советовал рассматривать код из статьи как хороший пример.
Может я неправильно понял, но у вас неправильная формула расчёта: рост доходов одного порядка с ростом расходов. Обычно в таких играх рост доходов является линейным, а расходов — экспоненциальным.
Обычно да, но я решил здесь этот момент упростить.
Рост доходов тоже может быть экспоненциальным, главное, чтобы он был медленнее роста расходов.
Рост доходов тоже может быть экспоненциальным, главное, чтобы он был медленнее роста расходов.
В качестве базы, которую возводят в степень уровня апгрейда, многие игры используют число 1,07.
Таким образом цена улучшения шахты до второго уровня будет примерно следующей:
10*(1,07)^2
Таким образом цена улучшения шахты до второго уровня будет примерно следующей:
10*(1,07)^2
Почему-то считал что Idle игры обязательно должны быть завязаны на реальном времени. Что игру можно забросить на день, потом вечерком выбрать апгрейдов и опять оставить на сутки. А setInterval это как-то слишком жёстко для жанра на мой взгляд — держать вкладку активной!?
Сейчас (примерно с октября-ноября 19г) с этой технологией активно борется Хром, но раньше никаких проблем не было. Эту статью я писал на чужом компьютере с установленными Яндекс браузером и Оперой, никаких проблем не было.
Именно так: утром открывалась вкладка, в остальных вкладках шла работа, ресурсы потихоньку копились в первой вкладке, раз в день тратили ресурсы, сохранялся прогресс и компьютер выключался перед окончанием дня. На следующий день цикл повторялся.
Учитывая, что в мобильных браузерах по понятной причине с подобным бороться начали сильно раньше, то для мобильных веб и нативных игр идет расчёт основанный на разнице между двумя таймстампами.
Именно так: утром открывалась вкладка, в остальных вкладках шла работа, ресурсы потихоньку копились в первой вкладке, раз в день тратили ресурсы, сохранялся прогресс и компьютер выключался перед окончанием дня. На следующий день цикл повторялся.
Учитывая, что в мобильных браузерах по понятной причине с подобным бороться начали сильно раньше, то для мобильных веб и нативных игр идет расчёт основанный на разнице между двумя таймстампами.
НЛО прилетело и опубликовало эту надпись здесь
Если вкладка закрыта
Наверное хотели сказать не активна, однако в моём представлении Idle игра должна «продолжаться» даже когда компьютер вообще выключен.
В самом простом случае это просто сохранённое время, например в localStorage. При загрузке игры она мгновенно «проматывается» исходя из разницы во времени, а для этого endOfTurnCalc нужно переписать с учётом что пройдёт намного больше одного «хода».
Сохранение игры тоже можно сделать автоматическое, на каком-нибудь window.onbeforeunload
P.S. Я не против авторского подхода, тем более что ни одной Idle игры я не выпустил, просто принцип работы представлял несколько иначе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
[Туториал] Как создать вашу первую инкрементальную IDLE игру на JavaScript