I literally though of the same things. I was gonna write exactly that on the forum! I just had another idea in my head, it's a Tile Map features where you can crop many part of a picture to use them as different graphics for your project. And I would definitely love more sounds/music features.

@Deeeds This. Totally forgot about listing stuff, would love to see this implemented.

@Kamdroid Again, WELL DONE! I'll get to it soon. Promise. Sorry I haven't had a chance yet.... fighting with spawning and "relationships" in hyperPad's worlds without them.

@Kamdroid I’ve kind of found ways around this, but they are really confusing and involve turning on and off an Ignore Collisions behaviour lol. So yeah this could be good.

@Kamdroid Yes, you've got that right. I think Codea might be able to export to Mac and Apple TV as well as iOS, but haven't used it for a while. I used to like browsing its documentation and trying out things that caught my eye. It's an incredibly polished piece of work. Two Australians, I believe.

@Murtaza @Jack8680 @GameCRAZY @iTap-Development I think all of this is pointing at a bigger, fundamental problem in the current structure of hyperPad: A lack of proper instancing and references. The single best thing about classes and OOP. Fix this problem and everything on this list (and much more) becomes possible, and you get the biggest single benefit of programming, the creation of infinite replicants, communication between them, unique identifiers of each instance, accessible, storable references to each and the ability to uniquely change any of them. Having done this, any "thing" can point to any other "thing", even if it isn't known about at runtime. This is the greatest benefit that Objective-C has over C++, that it first seeks a responsive object, then gracefully fails if/when it can't find an object that's supposedly there and able to respond to the method call. It doesn't do this through every class in a project, only up the hierarchy. If it seeks unsuccessfully, it doesn't crash, it just returns a nil. The Apple SDK/API and Frameworks designs/architectures have relied heavily on this capacity of Objective-C. Very heavily. The wrapping (please excuse the pun) of Swift's language design around Optionals is another way to provide this flexibility, from an architectural and language design point of view, without the losses in speed prevalent in the way Objective-C handled hunting hierarchies. Sadly Swift is not nearly as freeform and carefree for the coder. Dealing with Optionals is a pain in the arse. But it's better than crashing when something that's sought isn't there, solving this problem by putting the burden of discovery and ascertainment of validity on the programmer. The same concerns must be addressed in hyperPad. What happens when something is asked for or expected that isn't there? With the very literal and predefined (and exacting) way relationships are handled now means there is no chance of this. But the moment you permit dynamic addressing you're going to get failures to find the object, address, property, attribute or whatever it is that's predicted to exist but may not. So you now have to come up with a way to elegantly fail, or provide a completely bullet proof way of dealing with the failure to find something. Creating the complexity of optionals in a visually coded language/environment is not something good for those allergic to spaghetti. Going the way of Objective-C is even weirder because it's almost an old trick from an old world problem. Dealing with a silent, graceful return of Nil (exceptions) isn't something many people are really good at doing in Objective-C, and they're real programmers. At this stage there's no debugging in hyperPad, and that might be the biggest problem. Tired. Nap time. Thinking language Code hurts.