9 hours ago, gaxio said:

 

extends KinematicBody2D
const SPEED = 200

func _physics_process(delta):
	var velocity = Vector2(
		float(Input.is_action_pressed("right")) - float(Input.is_action_pressed("left")),
		float(Input.is_action_pressed("down")) - float(Input.is_action_pressed("up"))
	)
	move_and_slide(velocity.normalized() * SPEED)

That's it. 

Exactly. Even Unity's code is shorter and simpler than that, and a number of other game engines' code.

5 hours ago, Scouting Ninja said:

 

if Input.is_action_pressed("ui_up"):
	self.set_Pos(Vector3(0,1,0))

 

This is more like it, except for auto collisions.

6 hours ago, sprotz said:

Exactly. Even Unity's code is shorter and simpler than that, and a number of other game engines' code.

I just don't know why you're focusing on these irrelevant and completely arbitrary things like install size and code length.  It's like going car shopping and focusing on the floor mats and tire irons.  I don't know why you're focusing on these two things and honestly I don't think you know why either.

As for the actual code length, it's as long as it needs to be.  If you want even shorter code, look at engines like GameMaker and Construct, which have default character controllers you can drag onto objects.  That's 0 lines of code, but as soon as you need that controller to do something a bit different you're back to the same problems every other engine her: gathering either 4 buttons or 2 axes of input and moving the character with that.  Every game engine will provide an API to do this and it's just a matter of using that API to do what you need.  Whether one API has longer function names (Input.is_action_pressed("up") vs key("up"), for example) is utterly irrelevant.  It's a bit of typing, that's it.  If that's really what's making you choose one engine over another, I just don't know what to say.

9 hours ago, sprotz said:

This is more like it, except for auto collisions.

It looks like you didn't understand the code you where using in Blitz3D I will explain it so that you can see Godot is exactly the same:

If Keydown(up_key) Then MoveEntity Object 0,1,0 

 If Keydown is your input. You use this to tell what input to check. The MoveEntity Object is the target this gode has to move and 0,1,0 and this last part is your vector.

Godot works exactly the same:

if Input.is_action_pressed("ui_up"): move_and_slide (Vector3(0,1,0))

if Input.is_action_pressed("ui_up") this is you input check. move_and_slide() by default move and slide will execute on the target object. Last is the vector Vector3(0,1,0) Godot uses long names that clearly define what each thing does, to make it easy as you don't have to remember abbreviations.

So the simplest movement in Blitz3D looks like this:

If Keydown(up_key) = true Then MoveEntity Object 0,1,0 

If Keydown(down_key) = true Then MoveEntity Object 0,-1,0 

If Keydown(right_key) = true Then MoveEntity Object 1,0,0 

If Keydown(left_key) = true Then MoveEntity Object -1,0,0 

The simplest Godot version is like this:

if Input.is_action_pressed("ui_up"): 
  move_and_slide (Vector3(0,1,0))
  
if Input.is_action_pressed("ui_down"): 
  move_and_slide (Vector3(0,-1,0))
  
if Input.is_action_pressed("ui_right"): 
  move_and_slide (Vector3(1,0,0))
  
if Input.is_action_pressed("ui_left"): 
  move_and_slide (Vector3(-1,0,0))

The nice thing about Godot is that you can visually see what part is the IF part and what part is the Execute part.

Both these methods are considered bad practice when working with games. Because code runs from the top line to the lower line. Meaning that if you move like this and pressed both the up and down key, the object will always move down.

So to fix this the Godot tutorial uses math, to provide better input like this:

#The vector is made above all the other code, so that the other code can change it
var velocity = Vector3(0,0,0)

if Input.is_action_pressed("ui_up"): 
   velocity.y += 1 #this now makes velocity Vector3(0,1,0)
  
if Input.is_action_pressed("ui_down"): 
  velocity.y += -1 #this now makes velocity Vector3(0,-1,0)
  
if Input.is_action_pressed("ui_right"): 
  velocity.x += 1 #this now makes velocity Vector3(1,0,0)
  
if Input.is_action_pressed("ui_left"): 
  velocity.x += -1 #this now makes velocity Vector3(-1,0,0)
  
velocity = move_and_slide(velocity) #this now calculates the smooth movment using the combined 

So the reason Godot teaches it like this, is that velocity increases or decreases as you hold the button. The += means Velocity.x = Velocity.x+1 in other words it's own value plus one. If you used just = then it would be 1 and this would mean that down would cancel up, instead of slowing down.

Of course you could have done the same thing in Blitz3D, to get more realistic input.

9 hours ago, sprotz said:

Exactly. Even Unity's code is shorter and simpler than that, and a number of other game engines' code.

No, Unity doesn't have simple collisions. You would have needed to grab the rigidbody component and add force to it. Or if you really wanted the simple collision style you would have to emulate it using rays, here is a 2D example: https://answers.unity.com/questions/972878/simple-top-down-2d-collision.html

Godot is much closer to Blitz3D than Unity.

It looks like you are having a hard time because you don't know programming. I recommend you do a few python tutorials. Python is easy and is very-very similar to GDScript.

3 hours ago, Scouting Ninja said:

 

 

I am a natural programmer, I simply prefer simplicity.  and neatness.  Many Unity users have found Godot difficult too. See, in Godot the script would be simpler if "Input" was omitted in "input.event", or Vector3 is omitted like in Blitz3d, or the function name should be clearer "Is_action_pressed" sounds confusing compared to "Keydown",  ahh clear.  But a Godot veteran might not mind.

Then as the code becomes longer and bigger, more confusion erupts when it comes to debugging. Perhaps it is just my style as every programmer has a distinct style of coding.

But don't worry, Ogre3D's code is much worse.

3 hours ago, sprotz said:

Godot the script would be simpler if "Input" was omitted in "input.event", or Vector3 is omitted like in Blitz3d

That would be a very bad idea for a serious game engine. In fact it can be said that the reason Blitz3D didn't make it as a game engine is because it kept omitting data types and never provided necessary libraries to provide the data type functions.

Some data types are similar but have very different jobs. Take Color VS Vector3 both look like this: Red = Color(1,0,0) and Right = Vector3(1,0,0).

A Vector3 has a length that we use like this: Vector3(1,0,0).length( ) this will return 1. Color doesn't have any concept of length, it in turn has handy color functions like Color(1, 0, 0).contrasted() that tells us the contrast level of the color.

There is also differences in how these lerp and other mathematical expressions. That is why Godot doesn't omit these data types, so that you can use them as intended.

3 hours ago, sprotz said:

I am a natural programmer, I simply prefer simplicity.

Blitz3D isn't using a natural programming engine. It is a full code based engine, using BlitzMax that is derived from Basic

speed = (0,0,0)

If Keydown(up_key) = true Then speed.y = speed.y +1;
MoveEntity Object speed

This code works in Blitz3D because it understands programming. It was just a simpler engine, intended as a stepping stone for moving to more advanced engines like Godot.

If we look at the Godot example it can be made the same way:

var Speed = Vector3(0,0,0)

if Input.is_action_pressed("ui_up") == true : 
   Speed.y += 1

move_and_slide(Speed)

Yes it does look a little different but that is because it can do more things. Once you notice that the : symbol just means Then it is easy to understand why : is used instead.

Because in Godot a Then function can do a list of things, like this:

if Input.is_action_pressed("ui_up") == true : 
   Speed.y += 1
   Speed.y = 1 / 2
   Speed.y = Speed.y +1

All three those calculations will now run when the up key is pressed. Think of the : symbol as it is used when writing and you will see it is the same concept.

Once you have learned how to use Godot, you will see that if you go back to Blitz3D you will be able to do a lot of things you didn't know Blitz3D could do.

3 hours ago, sprotz said:

"Is_action_pressed" sounds confusing compared to "Keydown"

But "Is_action_pressed" doesn't only refer to keyboard keys. It could be a finger pressing a touchpad, or a game controller joystick that can be pressed down and even a lever like the ones found on controllers.

"Key_down" would have been confusing; as it is only a key on a computer keyboard.

3 hours ago, sprotz said:

Many Unity users have found Godot difficult too.

This doesn't surprise me, I have seen professional C++ programmer's struggle with Python. It's like a mountaineer coming fully dressed in climbing gear, only to find a hill.

In Unity the variables also need declaring, yet again this is because it has a lot of extras for each data type:

public float Speed = 100f;

void MoveObject(float XAxis, float YAxis){
  
  TempVec = new vector3(0,0,0);
  TempVec.x += XAxis * Speed * Time.DeltaTime;
  TempVec.y += YAxis * Speed * Time.DeltaTime;
  
  this.transform.position() += TempVec;
}


void Update(){
  MoveObject(Input.GetAxis("Horizontal"),Input.GetAxis("Vertical"));
}

As you can see there is a lot more to C# scripting than there is to GDScript or Blitz. The advantage of the Unity one is that you get pressure sensitivity; the harder the button is pressed the more the object moves.

Looks like this would have been a very long conversation, but let's just stick to the topic.

To make my answer short, I find that Blitz3d has all the capabilities I'm looking for, to make a video game. The extra "data types" are auto declared by context in Blitz3d, like in natural language, so no need to write extra code for it. The only capability I don't find in Blitz3d is the advanced graphics rendering which I don't need.

8 hours ago, Scouting Ninja said:

 

The script you wrote for Unity, Could you write it in Javascript, please ?

8 hours ago, sprotz said:

The script you wrote for Unity, Could you write it in Javascript, please ?

OK, but it feels pointless as Java looks a lot like C#:

var Speed : float = 100f;

function MoveObject(float XAxis, float YAxis){
  
  var TempVec = new vector3(0,0,0);
  TempVec.x += XAxis * Speed * Time.DeltaTime;
  TempVec.y += YAxis * Speed * Time.DeltaTime;
  
  this.transform.position() += TempVec;
}


function Update(){
  MoveObject(Input.GetAxis("Horizontal"),Input.GetAxis("Vertical"));
}

Basicly just the declaring of functions and variables change. Because most of the code is using Unity's libraries. I want to point out that Java is no longer supported by Unity. C# is Unity's main language for users now.

8 hours ago, sprotz said:

I find that Blitz3d has all the capabilities I'm looking for, to make a video game.

Then you should use it, if it is what you like. Blitz3D can make good games, it is just a bit more difficult.

8 hours ago, sprotz said:

are auto declared by context in Blitz3d, like in natural language, so no need to write extra code for it.

This is true, but it means you have to compensate for it somewhere else.

For example, you will notice that a lot of Blitz3D games are empty. This is because not being able to declare vectors means that basic vector math has to be done manually. So things like path finding and even just having a enemy aim at a target is more difficult in Blitz3D.

Something that would just be a 4 or 5 lines of code in Godot will be a page full of code in Blitz3D, as you do everything manually step by step.

So usually people just end up making their own vector class or using a wrapper for Blitz3D -like Newton Physics- to get proper vector math. This in turn needs declaration of the vector or conversion.

It is still a good idea to start with Blitz3D, it is easy to learn and lots of games can be made without complex AI etc. It can also have good graphics if you use 3D models with hand painted textures.

On 7/20/2018 at 11:08 PM, Scouting Ninja said:

In Unity the variables also need declaring, yet again this is because it has a lot of extras for each data type:

public float Speed = 100f;

void MoveObject(float XAxis, float YAxis){
  
  TempVec = new vector3(0,0,0);
  TempVec.x += XAxis * Speed * Time.DeltaTime;
  TempVec.y += YAxis * Speed * Time.DeltaTime;
  
  this.transform.position() += TempVec;
}


void Update(){
  MoveObject(Input.GetAxis("Horizontal"),Input.GetAxis("Vertical"));
}

If you're trying to show a concise example of Unity then you're not doing a very good job of it.  A few things in your code are needlessly verbose.

[SerializeField] float speed = 100f;

void Move(float x, float y) {
	transform.position += new Vector3(x, y, 0) * speed * Time.deltaTime;
}

void Update() {
	Move(Input.GetAxis("Horizontal"), Input.GetAxis("Vertical"));
}

That's it.  There are no tricks or crazy syntax here.  And you're really all over the place with your naming (MoveObject has a redundant word in it, TempVec is a terrible name), the code is not DRY, it's incorrect and/or overly verbose ("this" is redundant, and position is a property, not a method).

3 minutes ago, SillyCow said:

One of the great things with unity (when you use it with Visual Studio) is the great intellisense support.

Amen to that.  This is one of the areas where C# shines, since it doesn't just store compiled code in assemblies (DLLs and EXEs and stuff) but also extensive meta-information about the classes and methods then it makes code completion almost trivial.  All the editor has to know is what you're trying to complete, look it up in the assembly and you're done.  Plus there are things like OmniSharp that abstract this, so almost any editor can have good, reliable code completion.  VS Code has never let me down in this respect, thought ironically completion in MonoDevelop has broken on me many times over the years due to it being a buggy mess.  That's hardly C#'s fault though.

But it really changes how you code.  When coding without code completion I'll have a vocabulary of API functions that I almost never stray from.  If I have a problem I can't solve, I'll go look up another function and try to add it to my vocabulary.  But often I'll find out later that there are API functions that do things I've been doing on my own, but that I could have discovered through code completion easily.  Often times I won't know which function I really need so I just browse through the completion list and see if anything looks appropriate.  It seems like such a tiny thing, but it's a pretty big deal.