Binny is the PPB mascot! We have an information page about them, and we celebrate their birthday on March 22nd: The day of PursuedPyBear’s first commit! (e88f5ec46831c57f658b96d9eaaa35da86652bdd, for those that are curious.)
And how does a game engine celebrate a birthday? With a game jam!
So, it is our pleasure to announce Binny’s Birthday Bash Jam!
(Jam Page)
This year, it will take place from March 3rd to March 19th over on Itch.io! We suggest spending about 72 hours working on your game, using whatever schedule you’d like.
This is meant to be a fun jam, with the only hard rule being that you use the PursuedPyBear game engine.
It is open to everyone everywhere in the world, ages 13 and up.
As always, you can find help in our Discord.
]]>PursuedPyBear 1.0.0 was very late, and the maintainers have been focusing on other projects since then. As such, no work was done with the remainder of this release cycle!
So no 1.1 this week. Keep an eye on the Southern Solstice for our next release.
Continue to try out ppb 1.0, and give us feedback in the discord or via the issues tab.
]]>With the release of our beta, we’re in feature freeze, so contributions will be focused on bug fixes, documentation, and examples.
We like example code! If there’s a thing you figured out how to do and want to contribute, you can submit a PR with a new example folder. Name the nested folder with the feature set, mechanic, or task you’re showing off. Inside your example folder you can name your assets and scripts whatever you like, but include a README.md to explain how to run your example and what you’re trying to do!
Our expectations are that your example does something different from the other examples, that it runs in every version of Python that ppb supports (we go back to 3.6 right now), and we’d like the code to be readable. We’ll coach you to the last one if something is confusing.
Any bugs discovered while testing out ppb should be reported, either to the github issue tracker or to the it-didnt-work channel in the ppb discord. We’ll confirm and mark the issue.
Want to fix bugs? Check out the bug label on the issue tracker. Anything there can be fixed during freeze, and any new bugs surfaced during the process are eligible as well.
Our expectations are tests regarding the error, and the code fix. Otherwise, keep it PEP-8ish and we’re happy to answer questions on the issue or in the #development channel on discord.
This is the big lift: We want to polish our docs. Piper is tasked with a reference guide to discuss the overall ppb architecture and a pong tutorial. Outside of that, we could use how-tos and cookbook entries, other tutorials, and better onboarding documentation for all situations: learning ppb, contributing to ppb, and joining the community.
A tutorial should take between 30 minutes and 4 hours and present a complete working project. By that, we mean a functioning video game you can play. You may reference prerequisites (don’t feel like you need to explain event handling in every tutorial) and only focus on the part of the tutorial you’re going for. Make sure each tutorial has an introduction that explains its goals, what external tools you’ll need, and the basic outline. From there, you may break up your tutorial however you see fit.
If its across multiple pages, please add a subdirectory in the tutorials documentation, just to keep the files nicely ordered.
We need a lot of these! Anything you might need to do in a game could conceivably have a related how-to article. How-to articles are short. No more than 10-20 minutes to complete, and should show actual code and explanation to do a specific task. For example “How to fix your UI elements to the camera” could be a How-To article.
Cross reference with the API documentation for any built in features you’re using.
Don’t worry about getting it right the first time. The maintainers will be glad to help you through the process of hitting the above goals, we just would like to see as much of these done as possible.
And if you’re a new contributor? Don’t forget to add yourself to the CONTRIBUTORS.md file!
]]>PPB has a booth! As the conference is virtual, so is the booth. But this will be the best way to chat with us about PPB, gamedev in Python, or anything else.
We’re also working on some goodies. You’ll have to come visit to find out. 😉
As in previous years, PPB will be hosting sprints!
Unique to PPB, we encourage all kinds of ppb-related activities:
All of these are valuable to us, so we encourage any of them! All skill levels are welcome.
1.0 is coming this June! So these sprints are one last chance to get all the details in order for our big debut.
We’re hoping to have a lot of the breaking changes done before PyCon, but we could always use more help looking in strange corners. Look for the pre-conference alpha release.
]]>We finally support text rendering! We don’t support system fonts, so you’ll need to include your .ttf or .otf files with the rest of your resources just like images or sounds.
Just like the rest of ppb, text resizes based on the shape of your sprite, and it attempts to fill the space.
In tackling text rendering, it became required to loosen the restrictions on the shapes of Sprites. As such, we now support rectangular
sprites as well as square ones. The default Sprite is still a square, but you can also use ppb.RectangleSprite to manage things that
aren’t square.
Part of this refactor included doing away with the Sides interface: instead of Sprite.top.left it’s Sprite.top_left.
ppb has long supported a basic software camera as part of its rendering process. Building levels bigger than your viewport is much more simple than in other libraries since the constructs already exist. That said, the original camera was somewhat ugly. You had to know and understand the difference between the window screen space and the in-game coordinate grid.
The good news: we rebuilt the camera. Now, it’s width and height attempt to approximate the actual dimensions of the window, translated into game space. So if you test collision between the camera and an object, you’ll know if the object is visible on screen.
The bad news: In order to make the Camera work as well as it does, it gets added to new scenes by the Renderer during the SceneStarted
event. So instead of setting up your camera in Scene.__init__ you should do your initialization in Scene.on_scene_started.
This will be short and sweet:
We removed the DoNotRender flag. A Sprite with an image of None simply won’t render.
We added some initial (and optional) hooks for tinting your sprites and setting the render opacity of your sprites. Include
Sprite.tint with a 3 tuple color (r, g, b all in the range 0-255) to tint. Sprite.opacity with a value between 0 and 255 to
change the opacity of a render.
See the detailed change log on github and get the latest version of ppb with pip install ppb.
First, the simple one: event dispatch performance was dramatically optimized, because the performance of the previous method was just bad.
The big thing is that PursuedPyBear no longer depends on PyGame and uses PySDL2 instead. This was done because PyGame has never supported Python 3.8 in a final release, despite 3.8.0 being released in October, 2019. We are now using PySDL2 instead. This should require no changes from our uses, although Linux uses will require additional steps to install the SDL libraries (see the installation instructions).
Additionally, a pass was made at improving the docs: Double checking the accuracy of existing documentation, adding detailed documentation to ppb.engine.GameEngine and adding our first discussion pages. One discussing the design and constraints of the Asset system and another outlining the principles of ppb as a project.
We anticipate this release to have no impact on the vast majority of users, and minimal impact on the rest.
The detailed changelog can be found in the GitHub Release.
]]>The work-around seems to be to install Python 3 from the Python Software Foundation and not via Homebrew.
For more information, see:
Unfortunately, with PyGame’s focus on their v2 effort, we do not expect them to produce updated wheels when this bug is rooted out and fixes are released.
]]>Asset objects are given to systems. (api reference, As part of this, we’ve introduced the concept of a Virtual File System (VFS). The VFS allows assets to be loaded from the Python Path (sys.path), using the same structure as python modules. This simplifies the usage of asset packs (like ppb-mutant) and allows assets not tied to a sprite (namely sound effects) to work.
As a quick example this v0.6 code:
class MySprite(ppb.BaseSprite):
image = 'thingy.png'
resource_path = 'resources/sprites'
becomes this v0.7 code:
class MySprite(ppb.Sprite):
image = ppb.Image('resources/sprites/thingy.png`)
You may also notice that ppb.BaseSprite became ppb.Sprite. This is the result of a bunch of refactoring, and the old name is now deprecated and will be removed in a future release.
Also part of this effort is that there’s three generated image assets available: ppb.Circle, ppb.Square, and ppb.Triangle. Instead of loading data from a file, these generate basic shapes in memory.
The lesser headline is the addition of sound effects! (
Note that the warning about PyGame and Python version compatibility from the v0.6 release notes still apply. In summary: Do not use PyGame 2 or Python 3.8 at this time.
Added:
ppb.vfs module - Enables loading of files from Python packages (#306)AbstractAsset ABC (#329)AssetLoaded event (#315)ppb.Circle, ppb.Square, and ppb.Triangle generated images (#363)ppb.Sprite is now the base sprite class (#357)ppb.run() accepts arbitrary engine and subsystem arguments (#307)Changed:
ppb.BaseSprite is now deprecated in favor of ppb.Sprite (#357)Removed:
__resource_path__() protocol removed in favor of ppb.vfs (#306)Invisible:
ppb.sprites.BaseSprite now truly just a base class, using mixins to provide features. (#357)
ppb.sprites.SquareShapeMixin (#357)ppb.sprites.RenderableMixin (#357)ppb_vector (#303)ppb v0.6
and (drumroll please), ppb-vector v1.0, a stable release!
[party horn noises]
I am not going to get into the full changelogs here, they are both quite long. You can find them on GitHub (ppb, ppb-vector). I’m just going to list some highlights.
ppb-vectorBetween the refactorings, the renamings, the immense amount of testing, a lot has
happend. A lot. Far and away the most significant change is that Vector is
now immutable. While this makes a lot of things inconvenient, we think it will
improve maintainability for everything in the long term.
Other than that, all of the computations and methods have remained the same.
I would like to call out @nbraud for their immense help with the hypothesis-based test suite and improving the numerical algorithms. This literally would not have happened without their help and the software is dramatically better for it.
As a stable release, the PursuedPyBear team is commiting to
Semantic Versioning going forward. That means that 1.0.1
should contain only fixes, no API improvements, 1.1 will be the first version
with new methods and features, and it will be backwards compatible all the way
to 2.0. So if you want to be paranoid, specify ppb-vector>=1.0,<2 in your
dependencies.
ppbThe Summer 2019 release! :beach_umbrella: (See our release schedule) This comes with our usual smattering of features, rebuilds, and changes, but I would like to highlight a few things.
First, we now have online docs, hosted by ReadTheDocs! You can find them next to
Binny (that would be the blue binary bear in our logo) or at
https://ppb.readthedocs.io/.
Second, I would like to highlight a significant breaking change: We flipped the Y-axis. Postive Y now points up, towards the top of the window. Why? Because that is what is taught in most mathematics classes.
Third and finally, there are impending releases of Python 3.8 and PyGame 2. Do not install these if you are using PursuedPyBear v0.6. PPB is not compatible with PyGame 2, and PyGame 1 is not compatible with Python 3.8. Use Python 3.7 and PyGame 1.9 until an updated version of PPB is released. These requirements are encoded in our various metadata files, so hopefully your tools will honor this or warn you if not. And we will get an updated release out as soon as PyGame 2 is out to fix this problem.
]]>Or maybe you’d like our brand new API for subsystems: No more replicating the renderer and updater just to add your own custom subsystem. And they interact with the engine in an all new way. Just respond to the new Idle event and handle your timing based systems with style.
Remember, this is considered a prerelease, so to get it via pip:
pip install ppb==0.6.0b1
Please report any issues you find to the github issue tracker!
First beta of our Summer Solstice 2019 release.
Note that because of incompatibilities, PyGame 1 and Python 3.6 & 3.7 are the only supported versions. Neither Python 3.8 nor PyGame 2 are supported in this release. (This will hopefully be fixed for our Fall Equinox 2019 release, but its largely out of our hands.)
Idle event has been added, fired each iteration through the event loop (#221)title argument has been added to ppb.run() (#258)ppb.make_engine() has been added to simplify customization (#255)GameEngine.loop_once() has been added to allow for external loops (#255)GameEngine() now accepts systems and basic_systems arguments (you probably want the former) (#295)ppb.Vector has changed significantly; see the ppb-vector changes (#204, #280)Scene.running, Scene.next) has been removed (#259)System.activate() has been removed (#221)GameEngine.register() now accepts callables instead of simple values (#228)ppb.abc has been completely removed (#284)ppb.utils.LoggingMixin now works with subclasses (based on the file the calling code is in) (#202)StartScene no longer requires an empty kwargs when passed a scene class (#236)GameObjectCollection (and its subclass Scene) work correctly with subclasses of children (#241)Sprite.size of less than or equal to 0 no longer causes error (#262)PreRender fires (#274)