Suggestions for more dynamic behaviours

[Jack8680]

A few behaviour suggestions to allow more dynamic content and modding, partially based on Kamdroid's post:

• 'Download File' behaviour
  • Accepts a url and a file name to save as
    • Both allow inputs from behaviours
  • Downloads particles, sounds, or graphics
• Rework 'Set Graphic', 'Start Particles', and 'Play Sound' (and similar behaviours) so that a file name can optionally be manually entered (while keeping the current system as default)
  • Works with 'Download File'
  • Allows input from behaviours
  • 'Set Graphic' would be a lot simpler to use with large tilesets
• Similar to the above point, allow objects to optionally be selected by name alongside the current option
  • Allows name inputs from behaviours

[EDIT:

Perhaps also a set collision behaviour, although I imagine it'd be hard to have a nice interface, especially if this were to work with input fields.]

The three above features would allow content to be downloaded accross the internet and used to install player-created content or things like custom events without requiring an update to the game.

Additionally, it would be nice if behaviours could also be run from code (like the gamemaker language), since it would make mod support even easier; however it's not necessary, since this can be manually implemented to an extent.

[Deeeds]

@Jack8680 Sorry to waste your time... but I've got a question, that's stupid.

What do you mean by "dynamic behaviours"?

I've read both posts about this, but have no idea what is being discussed.

[Jack8680]

@Deeeds Maybe dynamic isn't the right word, but I use it to mean being able to accept inputs that aren't already defined, for example selecting an object that doesn't exist at the start of the game and is only spawned in later, or selecing a graphic by a name stored in a variable.

[GameCRAZY]

@Jack8680 I like this concept; it would work very well in Hyperpad.

@Murtaza has mentioned how they are working on implementing code, but how users might not be able to run it in the hub because Apple does not allow it. Hopefully, this is not the case when it arrives.

This makes me wonder though... how close can Hyperpad get to running actual code without really running languages like Swift or Objective-C? They might be able to get away with it to a certain extent, based on what the contingencies are for the App Store.

[iTap Development]

@Jack8680 I think dynamic is the right word. Attributes are predefined or dynamic.
@GameCRAZY i think apps can now download and run code for educational apps, but the user has to be able to view and edit the code etc. At least that’s what i heard.

[Jack8680]

@GameCRAZY if it's not possible, allowing broadcast/receive on a loop would make it pretty easy to create custom functions, allowing you to loop through code and create your own language.

Edit: thinking about it now, it's already possible (but more tedious) to do this already with behaviour on and attributes.

[Deeeds]

@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.