История выпусков Уведомления о выпусках | Лента RSS
Эта версия
Загрузка файлов
Загрузите файл для вашей платформы. Если вы не уверены, какой выбрать, узнайте больше об установке пакетов.
Source Distributions
No source distribution files available for this release. See tutorial on generating distribution archives.
Built Distribution
Uploaded 5 янв. 2021 г. py3
Хеши для minecraftapi-0.0.1-py3-none-any.whl
| 10a6f611c25e5b967c4d74f5ea7774df04f3394607a1090c795fe19084ff9fc7 | Копировать |
| ffaf09b96f4e6f5f67d6ba924053b89c | Копировать |
| c8cd89cc8a5b703e338ed80220210a3250de9cddbcd1eedd7ee2b16d01eff9e4 | Копировать |
Помощь
О PyPI
Внесение вклада в PyPI
Использование PyPI
Разработано и поддерживается сообществом Python’а для сообщества Python’а.
Minecraft для разработчика Java. Играть или программировать?
Пожертвуйте сегодня!
PyPI», «Python Package Index» и логотипы блоков являются зарегистрированными товарными знаками Python Software Foundation.
Источник: pypi.org
Долгожданный API в Minecraft!
Вы когда-нибудь хотели, чтобы Minecraft вел пошаговые бои? Или чтобы ты мог играть в шахматы в Minecraft? Или, чтобы я перестал задавать вопросы и перешел ближе к делу? Все это и многое другое возможно, теперь, когда API-интерфейс сценариев доступен в публичной бета-версии Minecraft!
Но что скриптовый API ( A pplication P rogramming I nterface)? По сути, это искусство настройки внутренних частей игры — написание новых команд во внутренностях Minecraft для модификации игры. Minecraft Script Engine использует язык JavaScript . Сценарии могут быть написаны и включены в пакеты Behaviour Packs для прослушивания и реагирования на игровые события, получения (и изменения) данных в компонентах, которые имеют объекты, и влияют на различные части игры
Давайте посмотрим на некоторые классные вещи, которые игроки уже сделали с API.
Эти гении на всемогущей Minecraft Wiki имеют множество справочных руководств и образцов пакетов здесь . У них также есть отличное руководство, которое объясняет сценарии в Minecraft лучше, чем я когда-либо мог (к сожалению, я слишком глуп, чтобы понять, как писать сценарии, моддинг или даже как вы включаете творческий режим. Вот почему мне не разрешают находиться в пределах пятидесяти футов от разработок Minecraft и вместо этого заставляют писать ерунду для этого прекрасного сайта, что совершенно нормально ).
Пошаговая система RPG боёвки
Сегодня его можно использовать для изменения элементов пользовательского интерфейса, анимации и объектов, но это только начало — мы будем расширять и расширять возможности по мере продвижения!
На этом все! Пожалуйста, поставьте лайк и подпишитесь на канал. Это очень сильно помогает! Спасибо.
Оригинал на Minecraft.net
Источник: dzen.ru
Технология разработки программных модулей. API.
Библиотека (англ. library) — это набор готовых функций, классов и объектов для решения каких-либо задач.
API (Application programming interface) — это некоторая функциональность, которую предоставляет программа, для обеспечения безопасного и удобного взаимодействия между ней и разработчиком, её использующим. API может быть частью программы, библиотеки, модуля, может быть рассчитано на программиста, и на обычного пользователя, может содержать визуальные элементы. Если простыми словами, API — это набор точек входа в систему, своего рода приборная панель, с набором кнопок и рычажков, для управления этой системой.
1.2 Понятие библиотеки. Почему она связана с API?
API может быть реализовано с использованием разной архитектуры кода, но важно понимать, что любое API имеет под собой твёрдый фундамент, называемый библиотекой. Это происходит явно или неявно. Например, если API строго привязано к программе, программа сама по себе является библиотекой, но неявной.
Однако, после некоторых экспериментов, я пришёл к выводу, что API – это не просто функциональность, расширяющая программу. Если мы хотим добиться наибольшей гибкости, API не стоит делать «дочерней» системой. Основная программа должна сама по себе расширять API. Иначе говоря, всю систему можно представить в виде следующей диаграммы:
В пользу такого подхода говорит следующее:
- Если мы реализуем основную программу на основе API, мы уже в процессе разработки, можем гарантировать наибольшую функциональность API, ведь в нём будет всё, что нужно для функционирования всей системы (основной программы).
- Параллельно с этим мы можем контролировать гибкость системы, и что очень важно, можем добавить возможность отключать/включать компоненты основной программы с помощью дочерних программ.
- Аналогично, основная программа сможет контролировать дочерние программы.
- Можно легко спроектировать приоритет для дочерних программ, повысить приоритет основной, а также понизить приоритет основной программы, если это необходимо.
- При изменении основной программы, дочерние программы не обязаны «поломаться», ведь подобное изменение не обязательно изменит основную библиотеку и API которое с ней связано
Однако, у такого подхода есть и недостатки:
- Первый и основной недостаток состоит в том, что такой подход хорошо применим только если система разрабатывается с нуля. Если мы имеем дело с уже готовой программой, применить данный подход сложно, и возможно лишь в том случае, если мы имеем полный доступ к программе, иначе говоря, если являемся её владельцем. К тому же, изменять что-то готовое в 100 раз сложнее, чем создавать новое.
- Иногда излишняя абстракция вредит. Если программа небольшая, и API предназначено для «корпоративного» использования, нет смысла добиваться огромной гибкости и функциональности, затраты на производство такого продукта будут просто несоизмеримы с полученным результатом.
- Если дочерних программ немного, то, опять же, затраты несоизмеримы с резульатом.
В любом случае, мы рассмотрим оба подхода, и «основная программа + библиотека -> API» и «библиотека -> API -> основная программа».
- Утилитарная – представляет из себя набор полезных функций/инструментов, для упрощения работы с рутинными задачами, в том числе с многократно повторяющимися.
- Системная – представляет собой своего рода рабочую систему. Сама по себе она ничего не делает, однако обладает способностью хранить и обрабатывать некоторый набор данных.
- Смешанная – комбинация двух предыдущих видов.
Спойлер: Достоинства
- Компактный размер исходного кода.
- Не требует больших усилий в проектировании.
- Вместе с самим API разработчик имеет доступ к реализации, может более тщательно анализировать ситуацию.
- Количество документации можно ограничить, поскольку разработчик может получить основной набор информации, исследуя реализацию.
Спойлер: Недостатки
- Доступ к реализации – обоюдоострое оружие, ведь если разработчик ненадёжен, то проект может стать достоянием общественности.
- Поскольку API поставляется вместе с библиотекой, общий размер подключённой к среде библиотеки может оказаться довольно большим.
- Если программа большая и многослойная – легко запутаться, и гораздо сложнее обнаружить точки входа предоставляемые API.
- При изменении реализации, API может также серьёзно измениться, что поломает дочерние программы
Модульное – разделено на несколько модулей (обычно 2), основной модуль встроен в библиотеку, берёт на себя основную нагрузку по обработке и хранению данных. Дополнительные модули – панель управления, иначе говоря, набор точек входа в библиотеку. Поставляется отдельно. Чаще всего используется подход: модуль API + модуль CORE.
При этом API никогда не обращается к модулю CORE, чтобы избежать ошибок компиляции при разделении. Сам же модуль CORE таких ограничений не имеет.
Спойлер: Достоинства
- У разработчика нет доступа к реализации, следовательно, даже если он окажется «нечист на руку» и опубликует исходный код – злоумышленники не получат ничего, кроме «панели управления». Панель управления без «двигателя» даст злоумышленнику разве что общее представление о возможной функциональности программы.
- Поскольку API разделено на модули, размер модуля, подключённого к среде разработки, может оказаться довольно небольшим.
- «Панель управления» не перемешана с реализацией, запутаться крайне сложно, всё будет на виду.
- При изменении реализации библиотеки, само API не обязано пострадать, иначе говоря, разработчик имеет доступ к тем же «рычажкам» и «кнопкам», просто работать они станут иначе. Это обеспечивает хорошую обратную совместимость.
Спойлер: Недостатки
- Требует хорошего документирования, иначе сторонний разработчик просто не сможет понять, что делает тот, или иной «рычажок».
- Количество исходного кода в совокупности может вырасти в 1.5 или даже в 2 раза, поскольку практически любой элемент будет иметь два экземпляра, один интерфейсный, другой внутренний
- Требует гораздо больших усилий в проектировании, чем интегрированное API
- Возникает довольно много проблем, связанных с взаимодействием модулей. Нужно добиться обособленности, при этом обеспечить корректное взаимодействие и передачу данных.
Как мы видим, у каждого вида есть свои достоинства и недостатки. Выбор зависит от требований к разработке продукта.
- Apache Commons:
- Библиотека: утилитарная
- API: интегрированное
- Библиотека: смешанная
- API: интегрированное
- Библиотека: смешанная
- API: модульное
- Библиотека: системная
- API: модульное
- Библиотека: утилитарная
- API: интегрированное
1.6 Диаграммы структур проектирования
Проектирование этих двух видов API можно представить в виде диаграмм.
Например, такой вариант интегрированного API:
И такой вариант модульного:
1.7 Итоги
Ввиду всего вышесказанного, можно сделать вывод, что архитектура кода будет напрямую зависеть от наших требований. Для разработки своего API я выбрал подход «Библиотека -> API -> основная программа» Библиотека получилась смешанная, а API модульным. Постановкой требований и проблем мы и займёмся в следующем разделе.
Автор mousecray Просмотры 1,422 Первый выпуск 4 Май 2021 Обновление 4 Май 2021 Оценка 5.00 звёзд 1 оценок
Источник: forum.mcmodding.ru