я не знаю, что посоветовать, поэтому просто расскажу — западная (и не моя!) компания Choice Games много лет монетизирует текстовые квесты (многие даже с минимумом оформления). Кроме мобилок, они выпускают еще платные игры в Steam (гуглится по Choice Games внутри этой платформы)
На мобилках они часто делают бесплатную демку на три главы или сколько-то там — в конце стоит предложение купить полную.
Вообще на мобилках очень много текстовых квестов с тысячами установок (и монетизацией).
Пробуйте еще, если позволяют ресурсы.
есть два пути
1. придумать архитектуру, действительно сохраняющую смысл и осознающую отношения между сущностями
2. добавить еще миллиард параметров, надеясь, что система найдет сама все нужное
Тетя Вика говорит, что «Информационная безопасность» — это еще и практика предотвращения несанкционированного «искажения, изменения, исследования, записи или уничтожения» информации
так что независимо от того, хороши источники в данной статье или нет — формально подходит лучше, чем блохи к рыбе (отсылка к комменту ниже ))
Если источники в статье заслуживают доверия — перед нами сокрытие информации.
Если источники в статье не заслуживают доверия, а это первый вопрос, который должен стоять перед каждым читателем в интернете — перед нами искажение информации.
PS: я считаю, но не предлагаю всем так считать, что любая статья в Интернете должна восприниматься как гипотеза, которую можно применять только для собственного предостережения и лишней подстраховки (к примеру, с опаской кататься в район), но никогда — для обвинения и тем более для заочного вынесения приговора в отношении каких-бы то ни было людей.
по поводу Circle — я выбрал не очень удачный пример. Смена геометрии вычислений в обычных приложения нужна очень редко )
более хорошим и естественным примером дата-класса, который просто несет в себе информацию, это
class Point{
x: number;
y: number;
}
В таком примере очевидно, что для такого класса геттеры-сеттеры избыточны, так как модель точки в пространстве не подразумевает взаимосвязи координат (но такая взаимосвязь возникает, если мы начинаем думать о функциях типа y =f(x).) Все зависит от выбранной модели. В данном кейсе Point — это просто коллекция x и y.
я вас не критикую. Вы можете писать как угодно.
Обилие строковых литералов в коде на мой взгляд неудобно.
В последнем комментарии я имел в виду читабельность кода. Мы смотрим на коммит, там изменилась одна строчка. По выбранному enum мы видим и понимаем смысл кода быстрее, чем просто по строковому литералу.
Если вы читаете мало коммитов, для вас это может быть не актуально.
Геттеры и сеттеры — вопрос сложный и таким кратким текстом его не объяснить.
Да, в Java с начала нулевых сложилась адовая практика добавлять на каждое поле класса геттеры и сеттеры. Это приводит к тому, что код дико разбухает, а заявленная гибкость требуется только для ничтожного проекта случаев. А 95 процентов геттеров и сеттеров — это просто мертвый лишний код.
Практика показала, что геттеры и сеттеры в таком примитивном виде — не удобное решение. Гораздо делать отдельно чистые дата-классы и чистые объекты.
Что такое чистый дата-класс? Это класс без логики, без методов, просто набор типизированных полей.
class Circle {
radius: number;
perimeter: numer;
surface: number;
}
Эти классы используются для передачи и хранения данных. Модификацию полей в них — и всю логику вычисления — производят специальные классы, только у которых есть доступ. Формулы вычислений содержит, скажем, специальный GeometryTransformer.
Это даёт настоящую гибкость, так как геометрию можно теперь спокойно менять на лету, подставив просто нужный объект GeometryTransformer — хоть евклидовый, хоть Лобачевского. При этом все остальное не переписывается и даже не пересоздаётся — чистый hot swap, великолепная возможность кардинально изменить правила игры и любых расчетов на лету.
Кроме дата-классов, можно использовать классы, в которых могут быть методы, очень похожие по смыслу на геттеры и сеттеры, к примеру,
class Shop {
getGoodList(): Array<Good>
}
При размышлении и написании таких классов, особенно при разработке прототипа, может показаться, что перед нами типичный геттер. Более того, в прототипе для теста такой класс действительно может содержать приватное поле со списком товаров goodList.
Но есть нюанс — об этом не надо думать, как о геттере, то есть об обертке над полем класса. Это метод, контракт для других классов, которые будут работать с Shop. А откуда магазин берет список товаров — это его личное дело. Там может быть поле. А может быть и обращение к другому классу.
Краткие итоги:
1. Не думайте «геттеры» и «сеттеры» — думайте о сокрытии реализации
2. Для хранения данных используйте data-классы как хранилища полей, без методов
3. Логика связи полей у дата-класса, вынесенная во внешний «трансформер-вычислитель» — сразу закладывает в вашу архитектуру не только гибкость, но и возможность менять формулы и поведение на лету, с теми же коллекциями объектов, на том же экране!
Поддерживаю.
пп. 1 и 2 — бесценны.
Абсолютно непонятно, почему автор оригинального текста решил предпочесть числовые enum. Потом ему кто-то (или даже он сам) добавляет новый элемент в начало enum — и привет, все enum-проверки сломались.
1. реклама
2. аналитика
3. видео с ютуба
4. игры
// пишут бесконечные статьи, не советуя им пользоваться
открываем главную страницу Яндекса, открываем отладчик, смотрим тег iframe, хммм
открываем страницу Google, даже минималистичную, открываем отладчик, хммм
Ну, похоже, авторы этих статей не работают ни в Яндексе, ни в Гугле )
Я только что читал статью про историю с ними — как в 2016 на лампочках Philips Hue сделали ботнет с мощностью атаки 1 Тб/с — habr.com/ru/post/372839
На мобилках они часто делают бесплатную демку на три главы или сколько-то там — в конце стоит предложение купить полную.
Вообще на мобилках очень много текстовых квестов с тысячами установок (и монетизацией).
Пробуйте еще, если позволяют ресурсы.
1. придумать архитектуру, действительно сохраняющую смысл и осознающую отношения между сущностями
2. добавить еще миллиард параметров, надеясь, что система найдет сама все нужное
может быть, второй путь однажды и сработает
так что независимо от того, хороши источники в данной статье или нет — формально подходит лучше, чем блохи к рыбе (отсылка к комменту ниже ))
Если источники в статье заслуживают доверия — перед нами сокрытие информации.
Если источники в статье не заслуживают доверия, а это первый вопрос, который должен стоять перед каждым читателем в интернете — перед нами искажение информации.
PS: я считаю, но не предлагаю всем так считать, что любая статья в Интернете должна восприниматься как гипотеза, которую можно применять только для собственного предостережения и лишней подстраховки (к примеру, с опаской кататься в район), но никогда — для обвинения и тем более для заочного вынесения приговора в отношении каких-бы то ни было людей.
А если игра постоянно требует платные ресурсы (хотя бы в виде хостинга) — рано или поздно её разработчику в ГуглПлее становится грустно.
Удачи вам, похоже, у вас есть талант.
Он исчезнет, а его используемые значения заинлайнятся
1. пример (не уверен, что сохранится)
2. документация
более хорошим и естественным примером дата-класса, который просто несет в себе информацию, это
В таком примере очевидно, что для такого класса геттеры-сеттеры избыточны, так как модель точки в пространстве не подразумевает взаимосвязи координат (но такая взаимосвязь возникает, если мы начинаем думать о функциях типа y =f(x).) Все зависит от выбранной модели. В данном кейсе Point — это просто коллекция x и y.
Обилие строковых литералов в коде на мой взгляд неудобно.
В последнем комментарии я имел в виду читабельность кода. Мы смотрим на коммит, там изменилась одна строчка. По выбранному enum мы видим и понимаем смысл кода быстрее, чем просто по строковому литералу.
Если вы читаете мало коммитов, для вас это может быть не актуально.
только при отладке придется смотреть на этот список или заучить его наизусть )
дает более полное представление о контексте применения кода, чем
Хотя бы потому, что романтическим может быть что угодно — от девушек до самолётов.
Но такая композиция часто выручает в разработке игр, особенно когда могут меняться правила.
Да, в Java с начала нулевых сложилась адовая практика добавлять на каждое поле класса геттеры и сеттеры. Это приводит к тому, что код дико разбухает, а заявленная гибкость требуется только для ничтожного проекта случаев. А 95 процентов геттеров и сеттеров — это просто мертвый лишний код.
Практика показала, что геттеры и сеттеры в таком примитивном виде — не удобное решение. Гораздо делать отдельно чистые дата-классы и чистые объекты.
Что такое чистый дата-класс? Это класс без логики, без методов, просто набор типизированных полей.
Эти классы используются для передачи и хранения данных. Модификацию полей в них — и всю логику вычисления — производят специальные классы, только у которых есть доступ. Формулы вычислений содержит, скажем, специальный GeometryTransformer.
Это даёт настоящую гибкость, так как геометрию можно теперь спокойно менять на лету, подставив просто нужный объект GeometryTransformer — хоть евклидовый, хоть Лобачевского. При этом все остальное не переписывается и даже не пересоздаётся — чистый hot swap, великолепная возможность кардинально изменить правила игры и любых расчетов на лету.
Кроме дата-классов, можно использовать классы, в которых могут быть методы, очень похожие по смыслу на геттеры и сеттеры, к примеру,
При размышлении и написании таких классов, особенно при разработке прототипа, может показаться, что перед нами типичный геттер. Более того, в прототипе для теста такой класс действительно может содержать приватное поле со списком товаров goodList.
Но есть нюанс — об этом не надо думать, как о геттере, то есть об обертке над полем класса. Это метод, контракт для других классов, которые будут работать с Shop. А откуда магазин берет список товаров — это его личное дело. Там может быть поле. А может быть и обращение к другому классу.
Краткие итоги:
1. Не думайте «геттеры» и «сеттеры» — думайте о сокрытии реализации
2. Для хранения данных используйте data-классы как хранилища полей, без методов
3. Логика связи полей у дата-класса, вынесенная во внешний «трансформер-вычислитель» — сразу закладывает в вашу архитектуру не только гибкость, но и возможность менять формулы и поведение на лету, с теми же коллекциями объектов, на том же экране!
пп. 1 и 2 — бесценны.
Абсолютно непонятно, почему автор оригинального текста решил предпочесть числовые enum. Потом ему кто-то (или даже он сам) добавляет новый элемент в начало enum — и привет, все enum-проверки сломались.
что касается «верить на слово» — то это уловка 22. Если человек уже подсел, его слово носит ветер.