С Aseprite не имел опыта работы, хотя на момент поиска инструмента наталкивался на него. Мне приглянулся Pyxel Edit за его простоту для новичка. Главное что там есть фича рисовать карту в живую, дабы смотреть результат в реальном времени.
До этого пытался рисовать в Photoshop и это был для меня АД. Пытался так же для автоматизации изменений использовать Smart Object-ы, но даже на карте 16 на 32 тайла Photoshop наглухо вис и отъедал всю оперативку на ПК (а это 32 гб). После этого психанул и купил Pyxel Edit =))
Набросков как таковых вообще нет, рисовалось на живую. Так же поглядывал в качестве примера на такие игры как bomberman, contra и zelda.
Публичная версия, увы, еще не скоро будет, потому особо показывать пока нечего.
Разработка идет с использованием таких инструментов: kotlin, libgdx, box2d и box2dlights (но в будущем планирую сам написать raytrace освещения, ибо текущая либа не покрывает все хотелки). Для сетевой составляющей пока в процессе выбора, если у вас есть хорошие варианты, с радостью бы их посмотрел.
Почему взял эти инструменты?
kotlin — по работе немного имел с ним дело, но недостаточно, чтобы понять его. Сам язык заинтересовал различным сахаром, которого нет в java (основной язык мой). В качестве способа его изучить выбрал писать игру, что тоже впервые, но тема меня эта давно интересует так же.
libgdx, box2d и box2dlights наиболее популярные и внятные инструменты для написания игр на языках JVM. Так же смотрел libktx, но из-за отсутствия нормальной документации не смог его применить. Плюс это просто прослойка libgdx (даже не абстракция для упрощения) и потому решил, что нет смысла тратить в двойне больше времени на изучение двух либ, если можно взять libgdx.
Стараюсь по максимуму избегать велосипедостроения, дабы на заниматься поддержкой своего добра, от того так же много времени уходит на поиск инструментов и изучение примеров игры на libgdx в связке с box2d.
Я вот недели полторы пишу игру, до этого ни разу не писал и сразу же столкнулся с подобной проблемой. Перерыл и попробовал просто тонну паков и ни один не подошел по стилистике.
В итоге купил Pyxel Edit для рисования спрайтов, tileset-ов, tilemap-ов и анимаций, и рисую сам. Процесс с трудом, но идет.
Самым сложным оказалось рисовать гуманоидного типа персонажей, пришлось раз 5 рисовать с нуля, но в итоге достигнул более менее хорошего результата (для первой версии игры точно пойдет).
По игре, кратко аналог Bomberman с сетевой составляющей и элементами прокачки. Так же упор идет на освещение, оно будет играть там важную часть.
Уже сейчас наблюдается такая ситуация между AMD и nVidia. Картинки в играх могут сильно отличаться по насыщенности и менее заметно различными деталями. Не узнавал, в чем причина таких отличий, но по сути уже сейчас корректность сравнений давно нарушена.
А потом ломались через полгода и пришлось менять. Был опыт, раза три менял на слайдере шлейф, хватило. С телевизором такое удовольствие нежелательно вообще
Двоякие ощущения от этой статьи, ибо от нее складывается ощущение, что legacy-код лучше не трогать. Я категорически не понимаю этого, для меня это из разряда старческого консерватизма, который не редко вредит, чем помогает.
Почему я так думаю? У меня есть опыт в переделке различных частей крупной системы под собственные соображения из разряда: тут некрасиво, тут запутано, да кто так пишет-то?? Ну короче синдром сантехника таки наблюдается у меня.
Все эти соображения появляются не на пустом месте, они исходят от того что приходится выполнять задачи по доработке и реализации новых функций, а текущий код настолько дурно написан, что оставлять его в текущем виде — риск нарваться на кучу проблем в будущем. Да и доработка такого кода требует больших затрат.
В итоге я начинаю планомерно переделывать весь код начиная с тестов. Допилив и дополнив тесты приступаю к рефакторингу. Обычно под участки для рефакторинга попадают те части кода, которые непосредственно затрагивает текущая задача. Тем самым я не только выполняю задачу, но и облагораживаю код для облегчения будущих переделок. Спустя пары десяток смежных задач большая часть кода становится менее связной, гибкой, простой в доработке и главное как минимум не медленнее предыдущей реализации (иначе какой смысл?).
Статья вредная и однобокая. Переделывать старый код не только можно, но и надо, главное делать это осторожно, планомерно и частями. Ну и соответственно чтобы аргументов было чуть по более, чем у человека с синдромом сантехника.
В моем случае в детстве применялись такие методики:
Забрать компьютер и отправить ребенка пахать на огород. Физический труд и размышления о «тяжкой» судьбе способствуют выздоровлению, иногда можно применять ремень для лечения плохого взаимопонимания, ибо порой речь люди не понимают, только боль.
Первый тест — дорожки №2-4. Центр у меня слегка сдвинут в право, ибо (тут догадка, но видимо верная) левое ухо однажды получило травму и чуть хуже воспринимает частоты средние и высокие. Низкие частоты по середине. Причем такая трабла с любыми плеерами и наушниками, т.е. дело действительно в моих ушах. Иногда проблема исчезает странным образом.
Второй тест — дорожка №10. Там есть такой пункт:
Отличной микродинамикой и исключительно высоким качеством
обладает звуковой тракт, если Вы услышите очень тихий шелест (время 1 мин
09 сек), когда барабанщик случайно задевает локтем тарелку и тут же
зажимает её рукой.
Вот хоть убейся, но не слышу там шелеста. Даже не поленился и зашел в аудио редактор, включил спектральное отображение и внимательно изучил место на наличие призвуков в дорожке. Их просто нет =) Потому дока слегка косячная.
Подтверждаю, сам одно время писал конвертер любого файла в изображение и JPG всегда бил файлы. Его тогда просто не использовал в итоге.
Как решение, можно использовать не все 256 значений цвета, а только 64 значений, которые размазаны от 0 до 255. Получается переизбыток в 4 раза, расстояние между цветами сделает байты «контрастнее» между собой. Так же если за пиксель взять не 1, а 4 пикселя, то есть шанс побороть проблему JPG.
Правда при чтении из него придется усреднять значения, а объем данных станет в 8 раз меньше помещаться.
Конечно это теоретически всё, эксперименты помогут найти лучшее решение и параметры.
Это понятно, но суть вопроса в другом. Как вообще достаточно умную систему научить не втыкать в одно решение, а находить достаточно быстро все доступные (или их часть, главное быстрее и больше человека).
Т.е. не быть такой тугодумной, как взрослый человек в некотором классе задач.
За статью спасибо =)
С Aseprite не имел опыта работы, хотя на момент поиска инструмента наталкивался на него. Мне приглянулся Pyxel Edit за его простоту для новичка. Главное что там есть фича рисовать карту в живую, дабы смотреть результат в реальном времени.
До этого пытался рисовать в Photoshop и это был для меня АД. Пытался так же для автоматизации изменений использовать Smart Object-ы, но даже на карте 16 на 32 тайла Photoshop наглухо вис и отъедал всю оперативку на ПК (а это 32 гб). После этого психанул и купил Pyxel Edit =))
Набросков как таковых вообще нет, рисовалось на живую. Так же поглядывал в качестве примера на такие игры как bomberman, contra и zelda.
Публичная версия, увы, еще не скоро будет, потому особо показывать пока нечего.
Разработка идет с использованием таких инструментов: kotlin, libgdx, box2d и box2dlights (но в будущем планирую сам написать raytrace освещения, ибо текущая либа не покрывает все хотелки). Для сетевой составляющей пока в процессе выбора, если у вас есть хорошие варианты, с радостью бы их посмотрел.
Почему взял эти инструменты?
Стараюсь по максимуму избегать велосипедостроения, дабы на заниматься поддержкой своего добра, от того так же много времени уходит на поиск инструментов и изучение примеров игры на libgdx в связке с box2d.
P.S. Так же ссылочка на Pyxel Edit
В итоге купил Pyxel Edit для рисования спрайтов, tileset-ов, tilemap-ов и анимаций, и рисую сам. Процесс с трудом, но идет.
Самым сложным оказалось рисовать гуманоидного типа персонажей, пришлось раз 5 рисовать с нуля, но в итоге достигнул более менее хорошего результата (для первой версии игры точно пойдет).
По игре, кратко аналог Bomberman с сетевой составляющей и элементами прокачки. Так же упор идет на освещение, оно будет играть там важную часть.
Почему я так думаю? У меня есть опыт в переделке различных частей крупной системы под собственные соображения из разряда: тут некрасиво, тут запутано, да кто так пишет-то?? Ну короче синдром сантехника таки наблюдается у меня.
Все эти соображения появляются не на пустом месте, они исходят от того что приходится выполнять задачи по доработке и реализации новых функций, а текущий код настолько дурно написан, что оставлять его в текущем виде — риск нарваться на кучу проблем в будущем. Да и доработка такого кода требует больших затрат.
В итоге я начинаю планомерно переделывать весь код начиная с тестов. Допилив и дополнив тесты приступаю к рефакторингу. Обычно под участки для рефакторинга попадают те части кода, которые непосредственно затрагивает текущая задача. Тем самым я не только выполняю задачу, но и облагораживаю код для облегчения будущих переделок. Спустя пары десяток смежных задач большая часть кода становится менее связной, гибкой, простой в доработке и главное как минимум не медленнее предыдущей реализации (иначе какой смысл?).
Статья вредная и однобокая. Переделывать старый код не только можно, но и надо, главное делать это осторожно, планомерно и частями. Ну и соответственно чтобы аргументов было чуть по более, чем у человека с синдромом сантехника.
Забрать компьютер и отправить ребенка пахать на огород. Физический труд и размышления о «тяжкой» судьбе способствуют выздоровлению, иногда можно применять ремень для лечения плохого взаимопонимания, ибо порой речь люди не понимают, только боль.
Дешево, сердито и действенно!
Первый тест — дорожки №2-4. Центр у меня слегка сдвинут в право, ибо (тут догадка, но видимо верная) левое ухо однажды получило травму и чуть хуже воспринимает частоты средние и высокие. Низкие частоты по середине. Причем такая трабла с любыми плеерами и наушниками, т.е. дело действительно в моих ушах. Иногда проблема исчезает странным образом.
Второй тест — дорожка №10. Там есть такой пункт:
Вот хоть убейся, но не слышу там шелеста. Даже не поленился и зашел в аудио редактор, включил спектральное отображение и внимательно изучил место на наличие призвуков в дорожке. Их просто нет =) Потому дока слегка косячная.
Как решение, можно использовать не все 256 значений цвета, а только 64 значений, которые размазаны от 0 до 255. Получается переизбыток в 4 раза, расстояние между цветами сделает байты «контрастнее» между собой. Так же если за пиксель взять не 1, а 4 пикселя, то есть шанс побороть проблему JPG.
Правда при чтении из него придется усреднять значения, а объем данных станет в 8 раз меньше помещаться.
Конечно это теоретически всё, эксперименты помогут найти лучшее решение и параметры.
Т.е. не быть такой тугодумной, как взрослый человек в некотором классе задач.