Edge cases что это
Я уже достаточно давно работаю продуктовым дизайнером и активно ищу идеи для собственного продукта. И, как это часто бывает, всё самое нужное у нас под носом. Так мне пришла идея, которая витала в воздухе уже очень давно 😄
Забегая вперед, скачать приложение можно здесь, и вот у нас ещё лендосик есть 🙈
Представь, что у тебя сегодня поезд. За день до отправления ты пишешь список того, что нужно взять с собой, что нужно сделать, чтобы ничего не забыть. Ты собираешь все вещи, перед выходом тщательно перепроверяешь, не забыл(а) ли ты что-то выключить или закрыть. И вот, вроде бы всё проверили, всё отлично, можно идти. Захлопываешь двери, садишься в такси и едешь на вокзал.
Вроде всё классно, да? А тут бац, и та самая глупая мысль: «а я выключил(а) утюг?», или «а я закрыл(а) дверь?». Начинаются бесконечные попытки вспомнить, судорожные звонки соседям/друзьям/родственникам и вот это вот всё. Не круто.
Есть масса решений этой проблемы, от самых простых, типа снять всё на видео или сделать что-то необычное (на пример похлопать себя по щекам), чтобы точно запомнить. И заканчивая самыми высокотехнологичными: камеры видеонаблюдения, умные замки и т.д.
Все эти методы по-своему действенные, но, если для первых достаточно просто не забыть, то вторые требуют ощутимых финансовых вложений, к которым не каждый готов.
Идея проста как мир — приложение-чеклист с небольшими доработками 🙈
Флоу простой до невозможности, следи за руками:
- На онбординге ты даешь доступ к уведомлениям и трекингу геолокации. Там же устанавливаешь свой дом. С ФСБ, СБУ и ФБР договориться не вышло, так что данные продавать некуда, они никуда не уходят, можешь не волноваться. Всё, что произошло в Locked.app, останется в Locked.app 😏
- После, ты создаешь переключатель для каждой активности. На пример у меня это двери, окна, свет и бойлер.
- Ну и наконец, когда ты будешь всё так же проверять это всё перед выходом — просто отметь это в приложении, всё просто ✨
Ага, разбежался. Было бы всё так просто — люди бы просто юзали напоминалки.
Когда ты только начинаешь пользоваться приложением — это новый опыт для тебя. Соответственно ты вряд-ли будешь забывать переключить тогл. Но когда он станет частью твоей ежедневной рутины — ты станешь о нём забывать. Это главная проблема.
Решил я её довольно тривиально. Аплик просто отслеживает твою геолокацию в фоне, чтобы уведомлять тебя, когда ты уходишь из дома. Тогда вероятность забыть переключить тогл становится в разы меньше. Когда ты возвращаешься домой — все тоглы выключаются сами.
Тут тоже довольно чувствительный момент приватности. Если бы кто-то перехватил данные о том, что ты не дома и, возможно, забыл закрыть дверь — было бы как минимум неприятно. Потому пока что я не готов предложить какие-то синхронизации и подобные штуки, потому что нахожу это небезопасным.
Ещё один edge-кейс — курьеры. Если ты работаешь курьером или по любой другой причине можешь в течении дня проехать мимо своего дома — приложение отключит тоглы и тебе придется включать их заново. Чтобы этого избежать — ты можешь отключить автовыключение в настройках. Это было максимально простым решением, а самое простое — часто самое лучшее 😁
Всё началось в очередной раз, когда я, матерясь про себя, поднимался пешком на пятый этаж чтобы проверить, закрыл ли я двери 🙈
Тогда я решил, что этому пора положить конец, потому что ну реально задолбало.
В голове быстро родилась базовая концепция того, что и как можно сделать, и после, за чашечкой кофе мы с другом накидали это всё более детально, расписали роадмап и взяли всё это дело в работу. На исходе у нас было 1.5 дизайнера, 0 разработчиков и конечность бесконечность желания и стремления.
Начали с банального опросника, который раскидали всем, до кого смогли добраться, чтобы собрать какую-то базовую аналитику.
Оказалось, что проблема в той или иной степени актуальная для всех поучаствовавших в опросе. Потому решили, что стоит попробовать.
Мы собрали и протестировали несколько прототипов. Для экономии времени, параллельно с этим тестили и дизайн-концепции. В итоге пришли к чему-то похожему на то, что вышло в итоге:
Я оттягивал этот момент как мог, но надо было начинать это всё дело кодить. Поскольку бюджет у проекта был сильно ограничен кругленьким ноликом — я решил, что писать его буду сам. Изначально рассматривал Flutter, но после ресерча понял, что будет тяжело имплементировать фоновый трекинг геолокации. Там был готовый модуль, который легко настраивался, но он стоил денег, которых, помним, у нас нет.
Решил, что лучше всего для этой задачи подойдет Swift, тем более что был наслышан о простоте и легкости SwiftUI.
Конечно, поскольку у меня практически не было опыта в программировании, код на 90% состоит из костылей, по кускам выдранных из всяких гайдов на Youtube, StackOverflow и других ресурсов, и на 10% из лично моих костылей, которые я городил чтобы всё это поженить.
Получилось, на удивление, неплохо. Ты можешь лично затестить результат, скачав приложение по ссылочке. Не стесняйся оставлять честный фидбек, будем улучшать 😄
Сейчас у меня вообще нет времени заниматься апликом, к сожалению. Есть уже много фичей в мыслях, но сейчас, честно говоря, немного другие приоритеты. Приложение будет апдейтиться, приложение будет жить, потому что оно делает главное — решает проблему.
После публикации его на реддите и во всяких дизайн-комьюнити, получил много фидбека (естественно, не всегда положительного), что приложение бесполезное, что много рекламы и т.д. Часть фидбека принял к сведению и уже внедрил возможность отключить рекламу за денежку и немного порезал её количество (ну камон, мне нужно хотя бы дев аккаунт отбить 😄). Часть пропустил мимо себя, потому что, очевидно, не все комментарии имеют смысл.
Ну и повторюсь, скачать приложение можно здесь, и про лендосик не забываем 🙈
Надеюсь и от вас получить какой-то фидбек, чтобы понимать, есть ли смысл вообще развивать Locked.app куда-то дальше, или просто оставить его как есть и накидывать каких-то фичей по личным потребностям)
Теперь нужно запилить приложение, которое будет напоминать, что нужно поклацать тоглы в вашем приложении :)
А если серьезно, интересный проект, но с геолокацией и приватностью конечно очень деликатный момент.
В последних версиях IOS есть возможность выводить виджеты. Попробуйте запилить небольшой виджет, который можно будет закинуть на страницу с приложениями в айфоне. Люди включают свои телефоны довольно часто, есть большая вероятность, что при том же выходе из дома человек разблокирует телефон и увидит виджет приложения, сразу клацнет тоглы.
По монетизации, так же тонкий момент. Это довольно простое приложение, реклама и платный доступ отобьёт все желание им пользоваться, как мне кажется. Думаю тут могут хорошо зайти Донаты, как это делают в HomeBro (были статьи на vc). Спустя N дней после того, как пользователь начал использовать приложение, выводите ненавязчивое всплывающее окно, по типу «мы старались, закиньте разработчикам на кофе и сервера, если приложение вам помогает». Так вы сохраните лояльность пользователей и начнёте генерить выручку
Edge case — An edge case is a problem or situation that occurs only at an extreme (maximum or minimum) operating parameter. For example, a stereo speaker might distort audio when played at its maximum rated volume, even in the absence of other extreme… … Wikipedia
Edge — An edge in common usage denotes a sharp border of a (solid) object.cience and technology* Edge (graph theory), a line segment joining two nodes in a graph * Edge (geometry), a line segment joining two vertices in a polytope * Edge case, a problem … Wikipedia
Edge detection — is a terminology in image processing and computer vision, particularly in the areas of feature detection and feature extraction, to refer to algorithms which aim at identifying points in a digital image at which the image brightness changes… … Wikipedia
Edge city — is an American term for a relatively new concentration of business, shopping, and entertainment outside a traditional urban area in what had recently been a residential suburb or semi rural community. The term was first used in Tom Wolfe s 1968… … Wikipedia
Edge contraction — In graph theory, an edge contraction is an operation which removes an edge from a graph while simultaneously merging together the two vertices it previously connected. Edge contraction is a fundamental operation in the theory of graph minors.… … Wikipedia
Case Western Reserve University — Motto Thinking Beyond the Possible Established WRU: 1826 CIT: 1880 CWRU: 1967 Type … Wikipedia
Case Blue — Case Blue German summer offensive in 1942 Part of the Eastern Front of World War II … Wikipedia
Case (singer) — Case Woodard Case Woodard, né a New York, est l un des premiers chanteurs à avoir commencé à travailler dans l industrie du R B. Il a travaillé avec les plus grands artistes R B ou du Rap comme Usher et Ja Rule. Il est sous contrat avec Def Soul … Wikipédia en Français
Edge preserving smoothing — is an image processing technique where the edge information is preserved during the smoothing process. It uses non linear operator which is able to remove texture and noise, while keeping edges and corners. The technique is known also as edge and … Wikipedia
Case Woodard — Case Woodard, né à New York, est l un des premiers chanteurs à avoir commencé à travailler dans l industrie du R B. Il a travaillé avec les plus grands artistes R B ou du Rap comme Usher et Ja Rule. Il est sous contrat avec Def Soul. En 1996 Case … Wikipédia en Français
Edge coloring — A 3 edge coloring of the Desargues graph. In graph theory, an edge coloring of a graph is an assignment of “colors” to the edges of the graph so that no two adjacent edges have the same color. For example, the figure to the right shows an edge… … Wikipedia
В своей первой статье я рассказывала о том, как дизайнерам сблизиться с разработчиками и научиться думать, как они. В то же время, цель этой статьи — дать дизайнерам полезные советы по использованию в своей работе методов и терминов из сферы программного обеспечения. Надо ли дизайнерам кодить? Нет. Но в рабочем процессе нам может очень пригодиться такая суперспособность, как умение создавать дизайн пограничных состояний.
Что такое пограничное состояние (edge кейс)?
При разработке компьютерных программ, инженеры в первую очередь рассматривают задачу с общей точки зрения: среднестатистический сценарий, который произойдет с большой степенью вероятности. Затем они переходят к рассмотрению edge кейсов: пограничных условий, которые, скорее всего, не возникнут. Но если разработчики не учтут возможность их возникновения, программа может полететь ко всем чертям.
Текст на картинке: «Катастрофичесская ошибка. Пользователь попытался использовать программу так, как она была задумана.
Возможные действия: 1) стереть этот компьютер 2) рыдать»
Пример непоправимой ошибки в результате столкновения пользователя и пограничного состояния. Источник.
Что я подразумеваю под фразой «создавайте дизайн для пограничных случаев»? Это причудливый способ сказать вам: думайте о каждом вашем пользователе. Вы можете разрабатывать дизайн для edge кейсов, прибегая к отладке с помощью экстремальных пользователей и локализуя не только для языков, но и для культур .
Отладка с экстремальными пользователями
Грейс Хоппер обнаружила первый в истории баг. Источник.
Иногда приложения для программного обеспечения сталкиваются как с программными, так и с аппаратными ошибками, которые возникают из-за багов (проблем в коде). Грейс Хоппер, одна из первых женщин-программистов, обнаружила первый программный «баг» (от англ. bug — букашка). Она нашла мотылька в одном из компонентов компьютера Mark II. Кто знает, что он там забыл, но с тех пор именно баги стали виновниками всех ошибок в работе программного обеспечения.
Отличным способом отладки проблем в вашем дизайне будет изучение экстремальных пользователей — людей, у которых все cлетает почти сразу, а также тех, у кого программа летает так быстро, что они были бы не прочь, если бы она превратилась в ракету. Если говорить серьезно, экстремальные пользователи — это либо «отрицатели», которые удаляют ваше приложение или перестают им пользоваться вскоре после установки, либо продвинутые пользователи, юзающие ваш продукт и днем, и ночью. Экстремалы играют важную роль, так как помогают вам определить все уязвимые места.
На первых стадиях работы приложения Periscope прямые эфиры исчезали через 24 часа. Однажды мы получили фидбек от одного из продвинутых пользователей о том, что его/ее фанаты делали скриншоты во время эфира, и человек никак не мог об этом узнать. Ситуация была довольно неоднозначной, так как мы обещали своим пользователям, что их эфиры будут исчезать бесследно. И мы хотели решить эту деликатную проблему наиболее осмотрительным образом.
Мы создали специальное сердечко в виде камеры, которое появлялось в потоке сердечек, как только кто-то из зрителей делал скриншот эфира. Тем, кто вел эфиры, понравился этот вид кастомной реакции — он выглядел особенным. Также людям нравилось, что появился еще один способ узнать своих зрителей лучше. В данном случае они были так увлечены эфиром, что захотели оставить его частичку себе на память, добавив в галерею своего телефона.
Локализация: знайте свою аудиторию
Локализация ПО — это перевод и адаптация программы. И если традиционно перевод осуществляется после того, как подготовлен исходный документ, то в программном обеспечении локализация происходит параллельно с разработкой. Таким образом, можно быть уверенным, что получится представить любую отдельно взятую функцию в каждой из языковых версий. Вам, как дизайнеру, заботящемуся о пользователях, нельзя списывать со счетов интернационализацию.
Вот ряд вопросов, которые вам необходимо задать самому себе, создавая дизайн для последующей локализации:
Самый элементарный вопрос: на каком языке вы разрабатываете дизайн?
Мы разрабатываем дизайн на английском, так как он — общая основа и известен каждому в нашей команде. Покажу на конкретном примере: текст кнопок. У фразы «Go live» (Выйти в прямой эфир) есть одна проблема: слово «live» можно прочитать как [ lɪv] и как [laɪv]. А так как суть Твиттера — передавать то, что происходит именно сейчас, мы решили, что LIVE, написанное заглавными буквами, будет читаться как [laɪv]. Помимо использования заглавных букв, мы также часто помещаем это слово в красную прямоугольную рамку и вставляем ее как значок «прямой эфир» на тв.
Какие переводы вы включаете в ваши дизайны?
Использование переводов в мокапах может иметь ОГРОМНОЕ значение.
К тому же, нам важно разрабатывать дизайн для некоторых наших крупнейших рынков. Это довольно просто сделать, помещая в мокапы уже переведенный текст. Например, вернемся к уже упомянутому нами тексту на кнопках. Одни из наших самых больших рынков это Турция и Россия, и переведенные фразы «Canlı Yayın Başlat» и «начать трансляцию в прямом эфире» в соответствующем контексте выглядят гораздо длиннее.
Являются ли ваши образы универсальными в отношении культур?
При анализе различных рынков следует также принимать во внимание культурный контекст. Например, в Твиттере на иконке создания твита используется изображение пера.
Использование образа пера для иконки создания поста в Twitter.
Создание твита можно считать самым важным действием на всей платформе. Однако западный образ пера как инструмента для письма не сработает на Востоке. Например, в Японии — одном из наших самых быстрорастущих рынков — никогда не использовались перья, только кисти. Исследование показало, что очень многие японцы нажимали на иконку, пытаясь обновить ленту, так как для них она была похожа на кнопку «Обновить». В итоге мы пришли к решению поместить на иконку всего одно слово: Tweet («твитнуть»). Твитнуть — это слово, придуманное Twitter. И оно универсально для всех пользователей платформы.
От программного обеспечения к дизайну
Основные термины для запоминания:
Пограничное состояние — ситуация на грани, которая вряд ли произойдет при стандартном использовании программы.
Программный баг — проблема в программе, из-за которой возникает программная ошибка.
Отладка — решение проблемы в программе.
Локализация в программном обеспечении — перевод и адаптация программы.
Основные процессы для запоминания:
Дизайн для пограничных случаев: необходимо учитывать всех пользователей и различия в языке, культуре и мировоззрении.
Отладка с экстремальными пользователями: они могут поделиться оценкой пользовательского опыта изнутри.
Обеспечивайте локализацию не только для разных языков, но и для разных культур. Учитывайте это в своих мокапах.
Чтобы стать супердизайнером, надо думать как разработчик. Источник.
Раньше я считала, что, мыслить на языке кода во время создания дизайна значит ограничивать себя в креативности. Я хотела, чтобы мои дизайны были беспрецедентными. И я знала, что краткость и возможность многократного использования в программировании имеют большое значение. Но я не видела связи между уникальными дизайнами и системной основой кода и логики.
Я открыла для себя, что чем больше своих знаний программирования я вкладываю в собственные дизайны, тем быстрее я работаю, и тем последовательнее могу выстраивать свой рабочий процесс. И включив методы программного обеспечения в свой дизайнерский процесс, я могу развиваться как дизайнер.
Здесь вы можете прочитать первую часть моей статьи, где я рассказываю о том, как дизайнерам научиться мыслить на языке кода.
Edge cases are a common topic of discussion in software testing. The definition of “edge case” itself is pretty straightforward. But there are many different types of bugs that can fall under the category.
Edge Case Definition and Meaning
In software testing, edge cases are bugs that are uncommon for users to encounter. Note, though, that this doesn’t always mean that it’s hard to reproduce the bug.
Sometimes the bug may be happening 100% of the time – but only on an iPhone model that makes up a very small share of the customer base. Other times, the bug might be happening across browsers/devices, but only 1% of the time.
An edge case can be a minor issue – for example, an inconsistency in the exact shade of blue used on an iOS app vs. the Android version. But it can also be a bug that’s severe when it does happen – like a crash.
Common Edge Cases
This is a bit of an oxymoron, as the whole point of an “edge case” is that it’s not happening affecting many users. But there are still certain edge cases that can be fairly common among different apps or websites overall. Some of these include:
- Crashes. One of the most common edge cases is when an app crashes without an obvious or very reproducible path. Oftentimes, the developer would be able to look at the code and determine the cause. But as a tester, you may not be able to easily reproduce the crash. (Good luck getting a screen recording!)
- A section of the app or website taking an extra 5 seconds to load once in awhile (regardless of network speed).
- Audio continuing to play in the background after closing a video screen on occasion.
Some edge cases are unique to the app or website they occur on. But others can be seen on many different types of websites or mobile apps.
How to Find Edge Cases in Software Testing
Sometimes you might stumble upon edge cases without even trying. After all, as a tester, you’re using the software far more than a real user likely would be. Therefore, you have more opportunity to encounter anything and everything that could go wrong.
Other times, you’ll have to seek edge cases out via regression testing. That means checking every section and function in the software. This can also make it more likely to find certain bugs that may happen as a result of heavy usage.
Writing Edge Test Cases
Ideally if you have test cases for regression testing, these will uncover any potential edge cases. Or at least any that have even a remote chance of affecting real users! Edge cases don’t necessarily need specific test cases. That might also waste valuable time that would be better spent looking for more universal bugs.
But a good set of regression test cases should enable you to find all but the most uncommon edge cases. If you’re not sure how to write good test cases, you can learn more in our guide to QA test cases. You can also learn how to write test cases without requirements.
Do Edge Cases Need to be Fixed?
It depends on a couple of factors. Just how uncommon is it, and how severely does the issue affect usability? For example, a bug happening 1% of the time may sound pretty rare. But if the bug is a user being unable to check out of a shopping cart, and the platform has 500,000 users, that could make a big dent in revenue.
Some teams think that a bug being an edge case means it never needs to be fixed. But this isn’t always the best outlook. Just because something doesn’t affect a large number of users, or happen very often, doesn’t mean that it can’t cause problems. Particularly if it’s an easy fix, it’s often worth doing. Not only will this improve the software, but it will also lessen the chance that your customer service team will have to respond to complaints from users affected.
Users can abandon an app or website because of bad user experience. Even if the bug doesn’t severely impact functionality, it could still be worsening the overall user experience.
It’s also beneficial to keep in mind that a bug affects more than just the people who encounter it. These days, word can spread fast – and many people are more than happy to use public social media accounts to complain. Even if a bug doesn’t affect the majority of your users, an affected user may tweet about it. As a result, your product will look bad to anyone who sees the post.
Edge Cases in Software Development
If you work in software testing, you’ve likely encountered edge cases while testing an app or website. If you haven’t used the term before, it can be very helpful when describing bugs to developers. If you tell a software developer that a bug is an “edge case,” they’ll immediately understand that it may not be 100% reproducible. This can save time going back and forth, and misunderstandings on both sides! (Learn more about the QA and developer relationship.)
Finding Edge Cases
If you’re looking for software testers to find edge cases for your app or website, contact Mindful QA! We’ve been featured on over a dozen “best software testing companies” lists, and would love to test your software.
About the author
Wes Silverstein is the founder of Mindful QA, an American software testing company fueling social progress. Wes lives in Los Angeles, and regularly contributes content to our QA blog.
В прошлой части мы зафиксировали основные подходы к созданию склонов в платформере, а также разобрали часто встречающиеся ошибки при реализации этой задачи. Теперь речь пойдет про Edge-кейсы, которые обязательно нужно учитывать при разработке игры.
Что такое Edge-кейсы и почему необходимо обращать на них внимание?
При разработке компьютерных программ в первую очередь рассматриваются задачи с общей точки зрения: среднестатистический сценарий, который произойдет с большой степенью вероятности. Затем переходят к рассмотрению edge кейсов — пограничных (или крайних) случаев, которые могут быть неочевидными на начальных этапах разработки. Однако если не учесть возможность их возникновения, плохо протестировав свой проект, edge-кейсы дадут о себе знать, и в игре появятся баги.
В нашем случае edge-кейсами будут наклонные и ровные тайлы, которые соседствуют друг с другом и нуждаются в особой обработке. Рассмотрим это на конкретных примерах.
Переход из верхней части склона на ровный тайл
Когда персонаж пытается перейти с верхней части склона на ровный тайл, мы сталкиваемся со следующей проблемой:
Персонаж воспринимает ровный тайл наверху как стену. Поскольку персонаж всё ещё находится на склоне, он ниже, чем ровный тайл, поэтому проверка столкновения обрабатывает ровный тайл так, как если бы это была стена.
Решение состоит в том, чтобы пометить ровные тайлы в верхней части склона как другой вид наклонного тайла.
Когда для этих тайлов выполняются проверки столкновений, они используют продолжающийся наклон (подробнее об этом можно прочитать в первой части статьи), выходящий за края тайла, как показано тут:
Это означает, что при проверке столкновений ровный тайл воспринимается как продолжение склона. Но подождите — теперь склон простирается слишком далеко и создает другую проблему на вершине склона:
Важно сделать так, чтобы столкновения на склоне выходили за пределы тайла по причинам, упомянутым ранее. Однако в случае, когда склон заканчивается и встречается с ровным тайлом, продолжающийся наклон, который выходит за края тайла, должен быть ограничен.
Обратите внимание, что пунктирные зеленые линии больше не проходят над вершиной склона. Если проверка столкновения попадает на наклонный тайл, но объект находится справа от тайла (за вершиной склона), то коллайдер ровного тайла не поднимется выше вершины склона.
Переход из ровного тайла в нижнюю часть склона
Следующая проблема заключается в том, что при движении от плоского тайла к нижней части склона персонаж находится слишком низко, чтобы фактически столкнуться со склоном. Его проверки на столкновение просто попадают на тайл ниже склона.
Решение снова состоит в том, чтобы пометить ровные тайлы в нижней части склона как другой вид наклонного тайла. Таким образом, когда проверка столкновения попадает на тайл ниже склона, коллайдер этого тайла поднимается на высоту склона в этой точке, и персонаж подталкивается вверх на склон.
И ещё немного edge-кейсов…
Есть ещё несколько edge-кейсов. Например, враги поворачиваются внизу склонов и не могут наступить на ровный тайл:
Это снова решается добавлением продолжающегося наклона, выходящего за края тайла, в соседний ровный тайл. Нужно снова пометить этот тайл как другой вид наклонного тайла.
Я не думаю, что стоит разбираться во всех этих edge-кейсах. Надеюсь, вы поймете, что решение этих проблем — всего лишь предотвращение любых затруднений передвижения в том месте, где должен быть плоский тайл. В совокупности это позволяет объектам плавно перемещаться по склонам.
Решать все эти edge-кейсы, применяя продолжающийся наклон, выходящий за края тайла, к соседним ровным тайлам, довольно сложно. Однако это автоматизированный процесс, выполняемый в коде, поэтому нет необходимости каждый раз настраивать его при редактировании уровня. Это затрудняет возможность добавления склонов различной крутизны, потому что было бы слишком неудобно обрабатывать все возможные случаи стыковки ровных тайлов и наклонных.
Время разработки
Для склонов фактическое время разработки составило 7 часов 30 минут. Я доволен этим — это оправданное количество времени, которое можно потратить на какую-то функцию, которая может многое добавить в игру. Ограничения, которые я наложил на склоны, с самого начала определенно помогли сократить время, необходимое для реализации.
Результаты
Я думаю, что даже эта ограниченная реализация наклонных тайлов может многое добавить в игру!
Вот гифка, которую я сделал для субботнего скриншотника в твиттере. Это показывает, что столкновение на склоне работает хорошо в различных случаях — в том числе в качестве движущейся платформы.
И моя первая попытка добавить пару наклонных тайлов на существующий уровень в моей игре:
Мне нравится, что это помогает сделать немеханические части окружающей среды более естественными.
Читайте также: