Февраль 2018

Прошлый тут

По деньгам только 2500. Игра про рыцаря вместо того, чтобы дать рост доходов в лучшем случае задерживает падение.

Продуктивность

В середине месяца я действительно очень мало сидел за компом но не то, чтобы совсем ноль. Думаю часть времени трекер просто по какой-то причине был выключен, но даже если накинуть к общему времени 20-25% то все равно получится один из самых маленьких месяцев. Я реально проводил много времени в дали от компа, но об этом чуть позже.

По работе все очень вяло.
Метался между
1) идеей расширения инструментария в сторону стратегических игр,
2) написания приложения, которое позволило бы мне работать со смартфона/планшета,
3) и просто стартом новой игры.

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

Поэтому некоторое время я потратил на ресерч, и в итоге я не так уж и много понял.
Все популярные решения, а именно: встроенный мультиплеер юнити, photon и Player.io заточены на матчмэйкинг, вплоть до того, что кроме матчей не дадут сделать вообще ничего. Одна их особенностей матчмэйкинга это «комнаты» игроки подключаются к какой-либо комнате и могут взаимодействовать только в рамках этой комнаты. Комнаты обычно не превышают 100 человек.

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

Я рассматривал возможность использовать photon server или player.io и чтобы внутри оно работало с общей базой, и через эту базу получается обеспечить взаимодействие тысяч игроков.
Плюсы полноценного сервера на photon server или player.io:
1) Это как бы «настоящий сервер», чтобы в эту фразу не входило.
2) TCP/UDP соединение позволяющее серверу с клиентом удобно меняться информацией.
3) Серверная логика на том же языке, что и игра. Прием и пересылка данных между сервером и клиентом сделаны очень удобно и просто.
4) player.io еще и хостить это сам будет.
Минусы:
1) Оба решения заточены на матчмэйкинг.
2) За все надо платить.
3) Photon server еще и разворачивать на хостинге нужно.
4) Не понятно как организованна работа с БД. А без БД все это лишено смысла.

Но взвесив плюсы и минусы перешел к более простому решению. К всем нам знакомой связке php + mysql, и собираюсь реализовать сервер в виде REST API.
Плюсы:
1) Это просто сайт. И может быть залито на любой хостинг.
2) Можно наконец приступить к работе, не изучая больше ничего дополнительно.
3) В случае необходимости переписки, если игра пойдет и будет давать большую нагрузку, можно будет нанять любого хорошего программиста и он полностью поймет мой код.
Минусы:
1) Это просто сайт и на вход могут пойти абсолютно любые данные и мне надо защищать свой сервер, как если бы я защищал любой другой сайт. Ну с инъекциями то все понятно. Но как защищаться от DDOS я пока не знаю.
Хочется как-то шифровать запросы, но потенциальный взломщик сможет при желании увидеть каждую строчку клиентской части, а я не имеют понятия как в таких случаях делают шифрование на стороне клиента.
2) Это решение далеко не оптимально по нагрузке. И чтобы сервер держал сотни подключений мне все равно придется осваивать новые для меня технологии. Однако учитывая, как тяжело игры набирают популярность, может быть у меня и не возникнет потребности оптимизировать нагрузку.
3) Архитектура типа запрос-ответ накладывает некоторые ограничения на обмен информацией, но думаю я просто подстрою логику под это ограничение.

Сброс веса

В конце января меня клинануло и я решил сбросить наконец лишнее. За февраль у меня наверное -5-6.
Но сброс веса требует не только дисциплины и воли, но и банального времени.

Я почти каждый день нахаживал километры. В среднем наверное два часа в день ходил, хотя бывало и побольше. Был день когда я прошел 29км. Был день когда я прошел 55км (почти весь день ходил).
Вот поэтому залогированно так мало времени за компом.
Под конец месяца в город пришла жара и ходить стало намного сложней. Что и на графике видно, полоски стали длиннее.

Акции

Основной счет -15,4%
Второстепенный счет. 0% (Точнее + 18рублей)
Тиньков -7,7%
Крипта +14,7%


Автор: Elsper.ru


VN:F [1.9.14_1148]
Rating: 10.0/10 (1 vote cast)

Итог января 2018

Прошлый тут

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

Продуктивность

Рабочих 58. Маловато.

В середине месяца виден пик — это меня переклинило, и я чего-то уработался.
На самом деле за день до этого мне пришла в голову идея, более объективно посмотреть на себя со стороны. И я начал дневник размышлений и наблюдений, который озаглавил «рефакторинг жизни». Как видно дальше запал погас и работать получалось в лучшем случае половину времени. Но я не сдаюсь.

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

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

1) Первая аксиома. Человеческое состояние переменчиво. В одно время мы хотим одного, в другое другого.
2) Из этого следует вывод, что надо сознательно выбрать предпочтительное состояние, запомнить а лучше записать цели, желания и ценности присущие в этом состоянии.
3) И когда к человеку приходит «не то» состояние, и ему хочется какой-нибудь фигни, вредящей целям и ценностям «главного» состояния, то во первых наблюдения помогут это заметить, во вторых понимание переменчивости состояний помогут просто переждать ненужные импульсы «не того» состояния не вовлекаясь в него и не сильно с ним ассоциируясь.
4) Однако другие состояния тоже часть нашей личности и их тоже нужно подробно анализировать, чтобы понять, почему они противоречат «главному», какие плюсы они несут, какие минусы, и как получить плюсы, но убрать минусы.

И получается например:
«Сейчас у меня состояние, при котором я хочу смотреть развлекательный ютуб. Но, вон выше у меня записано, что мое «главное» состояние не включает этого желания, и даже чаще противоречит ему. Почему тогда текущее состояние противоречит главному. Надо разобраться. Итак, тяга к ютубу — это с одной стороны серотониновая наркомания, с другой недостаток социальных контактов. По первому пункту, как там бороться с зависимостью? Ага есть вариант просто выкинуть зависимость и не удовлетворять ее. Значит мотив продиктованный наркоманией можно выкинуть, а недостаток социальных контактов вылечить встречей с друзьями.
Состояние разложено на составные и утратило свою целостность и «силу». Просто подожду несколько минут, пока психика окончательно переключится с него на другое»
Это не реальный кусок из дневника, а просто пример цепочки размышлений.

В конце месяца просадка, это у нас была поездка на несколько дней. И хотя я собирался в поездке плотно поработать, я с удивлением обнаружил, что это даже сложней, чем дома. Я назвал это «эффектом настройки», типа, что дома я хоть как-то привык себя настраивать на нужную мне деятельность. А тут все окружение другое, «настройка слетела», и наружу вылез мой внутренний овощ. Из этого наблюдения я получил довольно важный и неожиданный вывод: я на самом деле овощ, стремящийся к большему, а не гений, сгибающийся под тяжестью лени, до овощного состояния. Как это понимание повлияет на меня пока не ясно, но думаю влияние будет позитивным.

Так же начал интересовать психологией. Пока читаю Эриха Фромма. Думаю еще Юнга и пару книг от основоположников НЛП присмотрел. Пока очень мало прочитал, но уже сразу видно, что психология очень крутая штука и читать надо именно труды, а не выжимку или статьи, потому, что Фромм например не просто вещает то, что думает. Он подводит к своим идеям, попутно все объясняя. И именно эти объяснения — как раз и является самым ценным, а не конечное знание. Потому, что цепочка объяснений чувствуется как «реальная». Она вызывает у читателя чувство «понимания». А если прочитать статью с выводами или конспект, то получишь что-то среднее между постом из паблика ВК и лекцией в институте. Такое знание выветрится через день, или два.

Работа

Можно сказать, что переход на Unity завершен. Много сил и дней отняли банальные маски. Если во флеше я просто мог создать спрайт, задать ему размеры и включить режим маски, то тут все через жопу. Я в итоге сдался и купил вот этот плагин за 19 баксов. Точнее мне его купил издатель. Но даже этот плагин мне пришлось допиливать самому, чтобы без проблем использовать маскирование mesh в рантайме.
Перенес наконец хомяков. Но особых подвижек в дальнейшей разработке нет. Занимался рефакторингом, который поможет теперь добавлять новые столы почти без усилий. Так же встроил множественность рабочих мест, множественность точек приема ресов, и множественность точек выдачи ресов.

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

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

Акции

Акции неожиданно хорошо себя показали. Пока не посчитал, думал, что у меня как обычно куча косяков. Впрочем косяки у меня тоже есть в первые дни февраля я уже словил минус на 5%.

Основной счет. +12%.
Второстепенный счет. +17,6%
В обоих акках покачался на качелях ИнтерРАО.
Тиньков. +9,7%. Дивы, и компенсация прежних просадок.
Крипта. -35%. Зато наконец закупился.

Полифазный сон

Попробовал попрактиковать полифазный сон. Суть полифазного сна в том, чтобы спать не один раз в сутки, а несколько.
Есть разные режимы такой забавы от лайтового типа «сиеста», до безумных схем в которых человек суммарно спит 2ч в сутки.

Я выбрал схему, которую называют everyman. Уже из названия видно, что она «подходит всем», но я выбрал еще более упрощенную версию.
Оригинальная схема включает в себя 1,5 — 3,5 часов сна ночью и три отрезка днем по 20 минут.
Мой вариант 4-6 часов ночью и все те же три отрезка по 20 минут.

Сама идея полифазного сна заключается в том, что медленный сон не нужен. Поэтому надо приучить свой мозг максимально быстро засыпать, проскакивать фазу медленного сна и за несколько минут отдохнуть в быстром сне.
Однако другие люди считают, что медленный сон нужен, и поэтому, мне кажется режим everyman, включающий в себя большой ночной сон с медленным отрезком — золотая середина.

В общем не сразу, но я перешел на такой режим. Я вставал примерно в 7. В период между 11 и 12 я спал первую 20 минутку. Вторую в 17-18 впихивал. С последней было сложней, я ее втискивал в 22-23, периодически заходя на более позднее время. После чего бодрствовал еще до часу-двух и ложился.
Иногда пропускал 20 минутки. Иногда ночь спал дольше. Но, в среднем, сон занимал 5-7 часов. На фоне обычных 8-9.
Планировал начать с легкого режима и по мере привыкания сокращать время сна, но привыкания толком не происходило. Утром всегда было тяжело вставать. В дневные периоды не всегда получалось спать, иногда хотелось спать больше, чем 20 минут, но в целом, получалось после 20 минут вставать.

Из интересных эффектов: день разбивался на несколько микро дней, в каждый из которых надо было втиснуть что-то, чтобы не было чувства потерянного времени, что способствует повышению насыщенности жизни.
Так же каждое пробуждение, это новое состояние психики. Просыпаешься часто другим человеком, как и после привычного ночного сна. Иногда это в плюс, иногда в минус, потому, что хорошее состояние тоже слетает.
Стал гораздо смелее относиться ко сну, перестав переживать о том, сколько сплю и когда ложусь. Я теперь точно знаю, что если мне будет не хватать сна, я могу вставить 20 минутку днем и это реально поможет компенсировать недостаток.
Так же из положительного что такой режим позволял высвободить и вечер, и утро. Лично для меня в вопросе выбора режима сна неизбежно возникает конфликт, бодрствовать утром часов в 7, или бодрствовать вечером в полночь-час. Оба периода классные, и раздельный сон позволяет бодрствовать в оба, не отказываясь от них.
Из отрицательных: все та же разбивка, очень тяжело планировать что-то длящееся больше нескольких часов. Обычно вводя такие планы, я был вынужден пропустить какую-нибудь 20-минутку.

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

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


Автор: Elsper.ru


VN:F [1.9.14_1148]
Rating: 6.5/10 (8 votes cast)

Итог декабря 2017.

Прошлый месяц по ссылке

С игр 2489$ падение от месяца к месяцу. Вот что бывает, когда делаешь мало релизов.

Игра про остров принесла 261$ итого помесячный доход выглядит так

январь 3
февраль 9
март 35
апрель 162
май 169
июнь 200
июль 520
август 515
сентябрь 620
октябрь 630
ноябрь 317
декабрь 261

3441$

Результат получился средним. С одной стороны она продолжит приносить какие-то деньги и дальше, с другой на нее было потрачено примерно три месяца активного труда и в пересчете на помесячный доход она дала мало денег. Впрочем игра про рыцаря все равно выглядит еще более провальной. Потрачены деньги, куча времени а прибыль в декабре только 386$

Поэтому сосредоточусь на своем потенциальном хите, игре про хомячков.

Продуктивность

Рабочих 82 часа. Что для меня больше обычного. Все же освоение чего-то нового может хорошо увлечь. При этом я еще и очень много играл сразу в несколько игр. Основное время заняла oxygen not included, игра по жанру очень близкая к хомякам.

Unity

Продолжаю осваивать юнити. Допиливать свои классы и переделывать свою среду.

1) Нашел самый быстрый способ вывода графики. Благодаря шейдерам и полигональной нарезке он реально быстрый. ИМХО быстрее возможно только в кокосе получить.

2) Написал свою функцию сортировки объектов

public float recalculate_by_siblingindex(Transform tr)
    {

        float z_temp = 0;
        foreach (Transform child in tr)
        {
            var pos = child.localPosition;
            pos.z = -(z_temp);
            child.localPosition = pos;
            z_temp += recalculate_by_siblingindex(child);
            z_temp += 1f;
        }
        return z_temp;
    }

Он выстраивает иерархию через z индекс в зависимости от иерархии вложений.

Почему мне пришлось ее делать? Потому, что стандартный компонент SortingGroup не сортирует коллайдеры.
Зато теперь я могу использовать привычный 2D механизм очередности, как это было в флеше, и как это в общем-то и должно быть в 2D играх.

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

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

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

5) Вставил анимацию из спайна. При чем сделал это через код, что было не так-то просто.

ИСПРАВИЛ ОШИБКУ в официальном runtime коде для спайна, который не давал мне использовать самые быстрые шейдеры. (Самые быстрые шейдеры рисуются только с одной стороны. Сторона рисовки определяется порядком вершин треугольника, таким образом, чтобы они шли по часовой. В самом спайне есть возможность повернуть объект. После чего при сохранении того же порядка вершин треугольников, треугольник встает к нам обратной, невидимой, стороной.)
Так вот в файле https://github.com/EsotericSoftware/spine-runtimes/blob/3.6/spine-unity/Assets/spine-unity/Mesh%20Generation/SpineMesh.cs есть кусок

    var tris = currentSubmeshBuffer.Items;
    int triangleIndex = 0;
    var skeleton = submeshInstruction.skeleton;
    var skeletonDrawOrderItems = skeleton.drawOrder.Items;
	for (int a = submeshInstruction.startSlot, endSlot = submeshInstruction.endSlot; a<endSlot; a++) {			
		var attachment = skeletonDrawOrderItems[a].attachment;
		if (attachment is RegionAttachment) {
			tris[triangleIndex] = attachmentFirstVertex;
			tris[triangleIndex + 1] = attachmentFirstVertex + 2;
			tris[triangleIndex + 2] = attachmentFirstVertex + 1;
			tris[triangleIndex + 3] = attachmentFirstVertex + 2;
			tris[triangleIndex + 4] = attachmentFirstVertex + 3;
			tris[triangleIndex + 5] = attachmentFirstVertex + 1;
			triangleIndex += 6;
			attachmentFirstVertex += 4;
			continue;
		}
        var meshAttachment = attachment as MeshAttachment;
		if (meshAttachment != null) {
			int[] attachmentTriangles = meshAttachment.triangles;
			for (int ii = 0, nn = attachmentTriangles.Length; ii<nn; ii++, triangleIndex++) tris[triangleIndex] = attachmentFirstVertex + attachmentTriangles[ii]; attachmentFirstVertex += meshAttachment.worldVerticesLength >> 1; // length/2;
    }

 

Разработчики просто перебирают слоты, и рисуют два треугольника на базе прямоугольного куска текстуры. (Этим они кстати игнорируют всю фишку полигональной нарезки, которая меня наоборот так радует, потому, что позволяет ускорить графику. И возможно я даже заморочусь и перепишу и этот кусок)

Так, вот они просто игнорируют поворот и создают повернутый полигон.

Чтож, я просто проверяю слот на разворот и меняю порядок вершин треугольников!

var tris = currentSubmeshBuffer.Items;
int triangleIndex = 0;
var skeleton = submeshInstruction.skeleton;
var skeletonDrawOrderItems = skeleton.drawOrder.Items;
for (int a = submeshInstruction.startSlot, endSlot = submeshInstruction.endSlot; a < endSlot; a++) {
    
	var attachment = skeletonDrawOrderItems[a].attachment;
	if (attachment is RegionAttachment) {

        if (submeshInstruction.skeleton.slots.Items[a].bone.ascaleX < 0) //Моя правка, чтобы треугольники смотрели в камеру.
        {
            tris[triangleIndex] = attachmentFirstVertex+1;
            tris[triangleIndex + 1] = attachmentFirstVertex + 2;
            tris[triangleIndex + 2] = attachmentFirstVertex + 0;
            tris[triangleIndex + 3] = attachmentFirstVertex + 1;
            tris[triangleIndex + 4] = attachmentFirstVertex + 3;
            tris[triangleIndex + 5] = attachmentFirstVertex + 2;
        }
        else

        {
            tris[triangleIndex] = attachmentFirstVertex;
            tris[triangleIndex + 1] = attachmentFirstVertex + 2;
            tris[triangleIndex + 2] = attachmentFirstVertex + 1;
            tris[triangleIndex + 3] = attachmentFirstVertex + 2;
            tris[triangleIndex + 4] = attachmentFirstVertex + 3;
            tris[triangleIndex + 5] = attachmentFirstVertex + 1;
        }
		triangleIndex += 6;
		attachmentFirstVertex += 4;
		continue;
	}
	var meshAttachment = attachment as MeshAttachment;
	if (meshAttachment != null) {
		int[] attachmentTriangles = meshAttachment.triangles;
		for (int ii = 0, nn = attachmentTriangles.Length; ii < nn; ii++, triangleIndex++) tris[triangleIndex] = attachmentFirstVertex + attachmentTriangles[ii]; attachmentFirstVertex += meshAttachment.worldVerticesLength >> 1; // length/2;
	}
}

Конечно тут учтена только ось X (сделать игрек вообще не проблема по аналогии) и это работа связанная с поворотом кости, а там есть еще поворот самой текстуры (думаю чуток поразбираться и можно сделать, место где задаются вершины теперь известно).
Но свою проблему я решил.

6) Еще в юнити есть удобная возможность добавить все графичесские атлассы в одну папку (папка при этом должна быть в папке Resources) и потом просто вызвать код

public static Sprite[] sprites;
...
...
sprites = Resources.LoadAll<Sprite>("Atlases/");

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

7) И в итоге я так и не понял до сих пор на кого рассчитан юнити на дурачков или на профессионалов. С одной стороны там есть много достаточно сложных вещей.
С другой я несколько недель парился с тем, что юнити от балды подставляет позиции и масштабирование, пока не узнал что, оказывается в функции
transform.SetParent(parent) есть второй параметр, который при вызове функции ломает напрочь все позиционирование и масштабирование таким образом, чтобы родитель не оказывал влияние. То есть если у родителя масштабирование 0.5 и мы добавялем объект, то объекту выставялется масштабирование 2, чтобы на выходе получилось 1, которое было до добавления. Так же и с координатами.
И по умолчанию он ВКЛЮЧЕН. Блин, ну если я назначаю родителя, то очевидно не просто так же, а чтобы через родителя в том числе влиять на потомков. А юнити зачем-то ломает эту базовую логику.

В итоге мой кодовый фреймворк-надстройка занимает уже около 100 кб кода. (Спайн и прочие сторонние асеты я конечно не считаю), несколько материалов, пачку разных папок. При всем при этом в редакторе у меня только один объект — камера. И к ней прикреплен только один скрипт, который уже тянет все остальное и в итоге, во время исполнения те же хомяки выглядят вот так в 3D режиме

(Для снимка сделал все объекты активными)

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

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

Так же решил повысить ставки, и сделать хомяков мультиплеерными.

В целом по юнити было еще много всякого. Все же 80 часов было потрачено.

Акции

Основной счет -1%.
Второстепенный счет -7.5%
Тиньков +1,2%
Крипта -3,7%

По итогам всего 2017 года

Чистое изменение на конец года от всех вложенных денег.

Основной счет -6,9% (Большую часть из которых я потерял вот так)
Второстепенный счет -21,5% (которые он получил еще когда был под ДУ)
Тиньков +3,4%

Тут чистое изменение по итогам года не получается посчитать, потому, что не знаю сколько было на счету в начале года. Поэтому просто перемножу проценты помесячно.
Крипта +67,4%

 


Автор: Elsper.ru


VN:F [1.9.14_1148]
Rating: 7.2/10 (12 votes cast)

Unity. Тесты скорости разных способов вывода графики.

(Кому лень читать весь пост, читайте вывод в самом конце)

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

Для теста берется 1000 элементов квадратов 200 на 200 между которыми раскидано 16 текстур (200 на 200) с прозрачными и полупрозрачными кусками.
И рандомно меняем им позицию каждый кадр. Плюс часть вариантом тестировались с тряской общей сцены, а не отдельных элементов.

Статья получилась очень специфичная, так, что тем, кому не интересно, лучше пропустить.

Continue reading «Unity. Тесты скорости разных способов вывода графики.»


Автор: Elsper.ru


VN:F [1.9.14_1148]
Rating: 5.1/10 (10 votes cast)

Ноябрь 2017

Прошлый тут

Общий доход с игр 2800. -480 относительно прошлого месяца
Игра про остров принесла только 317. И теперь у нее 3180, не очень много, но и не очень мало.

январь 3
февраль 9
март 35
апрель 162
май 169
июнь 200
июль 520
август 515
сентябрь 620
октябрь 630
ноябрь 317

Новый релиз принес копейки. Только 33 доллара. Это демотивирует, потому, что из всех игр в нее вложено больше всего времени, денег и сил.

Для других проектов не написал ни строчки, потому, что решил переводить оба на Unity и пока трачу время на его осваивание.

Продуктивность.

Выхожу из черной полосы бездельничанья потихоньку.

Хотя rescuetime.com уверяет меня, что я показал результат хуже чем в прошлом месяце на самом деле в ноябре 44 часа программирования, а в октябре только 23 с половиной. Плюс на графике видно, что динамика продуктивности положительная.

Акции

Основной счет -2%
Второстепенный счет +2%
Тиньков +2,2%
Криптовалюты +16,8% (Сейчас 92% счета в кэше, и пока не вижу возможности войти)

В середине месяца снизил долю русских акций, обжегшись на аэрофлоте (вышел в коридоре 157-160 по пути чуток по-спекулировав, сейчас аэрофлот 148.), но снова влез, на этот раз в втб и еще в пять компаний «по мелочи».
По ВТБ сейчас моя средняя 0,056, актуальная цена в данный момент 0,0516, то есть я потерял 7,86%. Собственно если бы я не полез обратно на российский рынок то месяц был бы в плюсе.

Unity

Всерьез и окончательно решил переходить на юнити.
Осталась еще некоторая неуверенность, потому, что не рассмотрел варианты corona и cocos2d…
Но:
1)Бесплатность. После флеша я побаиваюсь бесплатных решений. Рано или поздно с них придется уходить.
2)Язык. Lua у меня сразу вызвал отторжение.

Сравните сами

while num < 50 do
  num = num + 1  -- Нельзя ++ и +=
end

И

while (num < 50) {
  num++; //Можно и ++ и +=
}

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

К тому же у corona мало серьезных проектов.

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

У юнити же C#, на котором я уже написал хорошее приложение и остался очень высокого мнения о языке.

3)Перспективы. Ну тут очевидно. С юнити всегда можно перейти в 3D разработку, уже как минимум просто повернув камеру. Потому, что на самом деле разработка и идет в 3D.
Но главный секрет в том, что ВСЕ быстрые игры это 3D, даже мои три последние игры написанные на флеше это технически все тот же 3D (но только если они написаны через starling).
Просто, если вы не видите 3D, это лишь значит что его так глубоко обернули, что оставили только 2D абстракцию (как в том же флеше)

Юнити же изначально трехмерный и максимальной быстрый выход к базовым функциям графики подразумевается сам собой. Поэтому, да можно начать с спрайтов, но если захочется максимальной скорости, то переход на уровень mesh потребует только подтянуть некоторые теоретические знания, касающиеся 3D.

С другой стороны это неприкрытое 3D может мешать, когда делаешь плоскую игру. Но это уже дело привычки.

__

Другие системы?
Unreal?
Тот же 3D и слишком дорогой. 5% отчислений хотят.

Флэш?
Он прекрасен для 2D, но годы шоу под названием «похороны флеша» не прошли даром. Он стал отставать от андроида. И время от времени то там то там какая-нибудь ошибка в релизнутой игре происходит. И со временем процент ошибок стал критичной причиной для перехода.

Все остальное не подходит по той же причине что и флэш. Бесплатные, не сильно распространенные решения имеют слишком критичный (для меня) риск начать однажды накапливать ошибки в готовой игре, как это начал делать флэш.

__

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

Texture2D texture= Resources.Load("имя_файла_без_разрешения", typeof(Texture2D)) as Texture2D;

Файл должен быть в папке Resources.
Нет папки Resources? Не проблема, создай ее где нибудь (на любом уровне вложения) в папке Assets и кидай туда картинки.

Еще очень много неочевидных вещей. Хотя у меня складывается ощущение, что они очевидны для всех кроме меня.
Итак, я гуглил создание маски на меши, использование шейдеров, генерацию мешей, и создание событий клика мышки.

Ответы есть на каждый запрос, но каждый раз авторы пропускают какую-то важную (для меня) деталь.
Чаще всего дают код, без малейшего пояснения куда это вставить, ответ висит заплюсованный, а мне ничего не понятно.
Так например, маска на меши делается через шейдеры, в гугле есть несколько вариантов этих шейдеров, но нет ни одного ответа, объясняющего куда этот шейдер ставить.
Просто запрос про шейдеры выводит десятки статей о том, как это круто использовать шейдеры и какие интересные вещи с ними можно сделать. О том, что шейдер выставляется в настройках материала ни одной строчки.
Генерация меша? Пожалуйста, вот статья прям в мануале https://docs.unity3d.com/ru/530/Manual/Example-CreatingaBillboardPlane.html
Вон там вершины, нормали, координаты на текстуре. А вот понять КАКОЙ ИМЕННО ТЕКСТУРЕ соответствуют эти координаты я должен как-то сам.
(В итоге я конечно понял, когда где-то увидел пример кода, что берется текстура материала меша)
Как текстуру прилепить к материалу в графичесском редакторе я так и не понял. В коде просто

GetComponent<Renderer>().material.mainTexture = текстура из примера выше;

Но когда во всем этом разберешься, то остаются только положительные стороны.


Автор: Elsper.ru


VN:F [1.9.14_1148]
Rating: 6.5/10 (15 votes cast)

Спoнcopcкиe ссылки