I once asked this question because I wanted game making software similar to Unity with an easy scripting language but with a small file size. I like Unity but its installation size is around 1GB and it's cluttery and overcomplicated in its file and project management. Some people suggested Urho3d and coppercube. I like something like Blitz3d with its very simple scripting language but it's discontinued and lacks a world/level editor, and Godot engine has a neat editor but its scripting language is too difficult, requiring confusing multiple lines for a simple collision, and very bad documentation. So, are there any other neat editors with simple scripting language and good capabilities as Unity but with a small file size? Both well known and not so well known? and free?

And with good documentation.

53 minutes ago, sprotz said:

Godot engine has a neat editor but its scripting language is too difficult

You won't find better than Godot. It is only 50MB after extract, with almost the same power as Unity. You can use C# with Godot, but it's own language is like Python making it a hundred times easier.

Small engine, massive power, easy to use scripting language that is still fast and Open Source; it is easy to see why this engine is growing in popularity.

There litierly isn't anything better than Godot at that scale. I really recommend you try it again; maybe after a few python for beginner tutorials.

The only thing easier than Godot that is still small and has some power is: http://www.stencyl.com/

Yeah, I see that Godot is the answer, and I just saw a video that shows how collisions can be done with simple code. Watching more videos might reveal more.

It is good to see that you aren't giving up. It is literally the first step on the long journey to becoming a developer. I have two tips that I wish I knew back when I started.

1.) Learn how to make Classes and Functions. These two programming concepts are designed to make programming easy, shorter and faster.

2.) Prototype in 2D. The thing you will see as you make games is that 2D and 3D work the same, but 3D looks more complex especially when it comes to math. However because 3D is just 2D with a extra dimension, you can often make code in 2D and just use it in 3D without needing to change much; except adding a extra float.

The nice thing about working with a upcoming engine like Godot is that you will be among the pioneers. The documentation is sparse, yet as you gain experience you can help others.

I expect we will be seeing a lot from the Godot engine in the next few years.

On 7/17/2018 at 1:00 PM, sprotz said:

Godot engine has a neat editor but its scripting language is too difficult

This is your problem, not Godot's.  I don't want to sound mean but if you're having trouble with Godot's scripting language then you aren't going to have a fun time with any engine.  Bite the bullet and learn how to program or you will never make any progress.  Godot's scripting language is not difficult, it's one of the easiest things I can think of to work in and switching engines to look for an easier one is going to be an exercise in frustration.  Even C# in Unity is easy, C# is a very nice language to work in and I know plenty of people who have gone from 0 programming knowledge to developing games in Unity with C#.

Learning to program sucks.  It sucks for everyone when they're first starting.  They get frustrated and nothing seems to make any sense, but it just takes time for your mind to work through this stuff.  Keep trying, keep working at it every day.  Every day you'll learn something new, lights will come on in your brain and eventually you'll get over the frustration hump and things will start to make sense to you.  Switching engines won't get you over the frustration hump, you just have to grit your teeth and get to work.

Now honestly I'd stick with Unity if you're just starting out.  The amount of information about Unity on the web is shocking, you can google more or less any problem you're having and the Unity forums are huge and very active.  The install size really shouldn't be an issue, it's 2018 and storage is cheap.  If you want to move to another engine later then that's another issue, but if you're just learning then I think Unity is the place to be.  That said, Godot looks quite nice too.  The community I'm sure is growing as well, it wouldn't be a terrible choice.

12 hours ago, gaxio said:

 

I understand your answer but...

Actually, I'm a veteran programmer and I am used to Unity and Blitz3d. I am used to Unity's Js scripting language and Blitz3d's basic like language and I am familiar with Python like languages that Godot has.  The structure is ok. The problem is the complicated and 'difficult to make sense' keywords Godot uses and long multiple lines of code needed for simple operations movement, collisions. just like Ogre3d. And also it is obviously unpleasant switching to a new engine and having to learn an entirely different coding structure all over again. 

But I have mentioned one solution before, which is using functions to translate this new code to my familiar Blitz3d code. But this takes some time. Blitz3d's coding language is so simple that the keywords are short and easy to understand with often one line of code needed to do complex tasks.

The reasons for requiring small file size are for portability and other stuff.

7 hours ago, sprotz said:

The problem is the complicated and 'difficult to make sense' keywords Godot uses and long multiple lines of code needed for simple operations movement, collisions.

I'm not quite sure what you mean, could you give an example of this?  All these engines are going to involve working with an API and stringing API functions together.  None of it is as boiled down and simplified as something as Blitz3D, but on the other hand it's all a lot more flexible than Blitz3D.  The objective of engines like Unity and Godot is not to make it dead simple, it's to make it easy to do easy tasks and possible to do any task.  This necessitates a more general API.

7 hours ago, sprotz said:

But I have mentioned one solution before, which is using functions to translate this new code to my familiar Blitz3d code.

This is a bad idea.  Learn the environment you're working in and use its API, don't try to hide that API behind a self-made abstraction layer that will only confuse things when it goes wrong.  The Unity and Godot APIs are not difficult or overly-verbose anyway, you should not be having a problem with this.

For example, in Blitz3d, to handle movement controls you write this one line: If Keydown(up_key) Then MoveEntity Object 0,1,0

But in Godot, I don't know it so well but I think you have to declare "velocity' then write "Input.Is_action_pressed("ui_up")", then set "velocity" to a value, then write Move_and _slide("velocity"). All those steps just for a simple motion.

And?  That's a simple action, if you're judging how easy it is to script an engine based on how short the program is...  I don't even know what to say.  That's a completely arbitrary thing to judge an engine on and a very odd thing for a "veteran programmer" to say.  The entire movement in script in Godot looks something like this.

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.  It's flexible, succinct and it honestly shouldn't get much "easier" than that.  If you're afraid of typing a few lines of code...  I don't know what to say.  Keep switching engines to find the shortest, I guess, but like I said before that's a completely arbitrary thing to be judging an engine on.

In terms of ease of use balanced with expandability and popularity (which sounds unimportant, but unless you're self-sufficient then you need people to help you solve problems) you're not going to find many (or any, really) better options than Unity or Godot.  Pick one and start learning it.  And stop expecting it to conform to your irrational expectations, no software will and unless you learn to adapt to different languages, libraries and paradigms than you'll constantly have a bad time with game development.  It is what it is, stop expecting it to be something else and stop trying to make it into something else.

3 hours ago, sprotz said:

But in Godot, .... All those steps just for a simple motion.

The thing is that the moment you are using here is the same as Blitz3D. It also uses delta time and does collision checks.

If you want the direct movement, there is set_pos() as in set object position. This is teleportation like movement, it doesn't detect collisions. Use it like this:

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

To be clear, the Godot move_and_slide() is also a collision check. You don't do any collision checks yourself.

move_and_collide()  = Stop response of Blitz3D. The object stops when it collides.

move_and_slide() = Slide response of Blitz3D. The object slides when it collides. Uses gravity for incline when needed.

The Godot RigidBody is a realistic collision system.

The velocity setup is needed because you are also doing collision checks.