Who cares about text and/or numbers? Like I said, there are Comment Blocks that talk about what the first and second inputs are for. The Comment Blocks also specify that you can only put integers and/or variable values in these blocks.
I haven't coded Syntax Errors in the code, so you don't get an error message when you accidentally type a string instead of an integer for the X Move and Y Move block values.
If you make them number inputs, that literally won't be able to happen.
just put variables in the number inputs! you can do that!
I feel like you're thinking about the whole thing from the perspective of text-based programming languages. This is NOT a text-based language.
This is my own syntax meaning I decide what syntax, words, and language the Game Engine uses
Bump.
Wdym? (Also, I want to depreciate Physicsbody2D because it can only have one sprite as a floor.)
Cool! Just make the Block Comments multi-line. 
Whatever happened to this? I want to help.
The DevSquare Game Engine trend didn't really go as well as I expected and died...
Wait, hold that thought. It didn't die. It didn't live nor did it have a future to begin with.
I'd like to take over this if it's fine with you.
OK, you can take over DevSquare AS LONG AS you give me credit (Because I made DevSquare).
I have a contribution. Take whatever you want of it or none. Please if you don't accept stuff tell me why.
This gives the entity momentum, and gravity which accelerates them instead of moving them at a constant rate until ground collision. I think that you should also integrate a system where the absoloute position of an object can be different to where they're shown, so a moving camera can be used easily in the engine.
The link to my (hopefully) contribution is Snap! Build Your Own Blocks
It's a bit slippery but solves my problem of Kinematic Gravity.
Yeah... Also I'm going to make my own.
It's just because friction isn't added. I don't know if it should be in the rigidbody block or it's own 'friction' block
Ideally you have the player moved back up until they're just on the surface of the object. But you have to choose to how small of a unit you do that. I would probably use increments of one of Snap!'s distance.
Here is the new official project:
https://snap.berkeley.edu/snap/snap.html#present:Username=joecooldoo&ProjectName=DevSquare
You should make it so you can set a Y level as collision for the physicsControl2D
Updated news.