PixelPAD Creation
PixelPAD was designed to take learners beyond Scratch. Its APIs are intentionally designed with features that are conducive to learning underlying mechanics and code. So, although a powerful engine, PixelPAD was built for education, and therefore lacks "magic buttons" that just give objects physics, or just makes a game "work".

This approach ensures transparency for the user, and supports educational outcomes.

It is however possible for users to import libraries into their code base for access to higher-level functions.
PixelPAD Vision and key factors driving direction
Getting Started Quickly
Any unnecessary steps that do not contribute to learning was abstracted. This means users can immediately run their project without spending time setting up their environment.
The Start and Loops being separated on PixelPAD is because of this key point. The first iteration of PixelPAD had the start and loop as separate methods, requiring users to create their own classes that inherit the start and loop. It also required users to have knowledge of Python indentation syntax, class creation syntax, and inheritance. All of this before the user got started.
So this was extracted away, and presented the start and loop into separate sections, allowing users to have an immediate impact using one line of code!
Power users can still make use of creating their own classes and inheriting from PixelPAD's super class if they wanted. This is done like this:
No Magic Buttons
Mentioned earlier, "magic buttons" was something that is actively avoided. Pixelpad avoids buttons that make their projects just work. Projects should have their code transparent to the user, not something hidden behind a menu or checkbox.
Any user that is curious about how someone else coded their game can do so by clicking on "see inside". No private repositories will be possible.
Education First
PixelPAD has always been a learners' platform first, but that doesn't mean amazing projects have not been made on this platform!