3D platformer code is overly complex

[seadra]

Can't the 3D platformer be simplified? (or a simpler one can't be added?)

The corresponding Unity tutorial project is much simpler (and works a lot better and smoother):

http://unity3d.com/learn/tutorials/projects/stealth/player-movement vs https://github.com/okamstudio/godot/blob/master/demos/3d/platformer/player.gd

http://unity3d.com/learn/tutorials/projects/stealth/camera-movement vs https://github.com/okamstudio/godot/blob/master/demos/3d/platformer/follow_camera.gd

I'm also trying to understand: with godot, many stuff have to be done manually, but the corresponding Unity code feels like a breeze.

Is the 3d platformer demo a badly written godot code (in which case I was hoping a simpler re-write), or that's just the way things get done in godot?

I know, it's not exactly apples-to-apples comparison, but I'm referring to the things aside from jump/shots. In comparison, the way facing, movement or camera is handled, manual physics, manually checking if there is stuff there or not etc. is bloated code with godot (and Unity version has a very smooth transitions with quaternion lerps).

Camera code is also seriously complicate (and buggy); Unity camera code is quite simple and smooth.

Please please tell me that that is just a non-idiomatic, badly written godot code :)

Oh, and I think godo would benefit from a similar demo (you know, without jumps and bullets, just to demonstrate basic 3D stuff, maybe with light baking)

[godotengine]

the 3D platformer uses a dynamic character controller, it is more difficult to use but interacts more efficiently with existing physics. Unity does not support this anduses a kinematic character controller instead. The fair comparison is to the 3D kinemaric char demo:

https://github.com/okamstudio/godot/blob/master/demos/3d/kinematic_char/cubio.gd

which as you can see it's much simpler

On Sat, Dec 20, 2014 at 7:07 PM, pikapikachu notifications@github.com wrote:

Can't the 3D platformer be simplified?

The corresponding Unity tutorial project is much simpler (and works a lot better and smoother):

http://unity3d.com/learn/tutorials/projects/stealth/player-movement vs

https://github.com/okamstudio/godot/blob/master/demos/3d/platformer/player.gd

http://unity3d.com/learn/tutorials/projects/stealth/camera-movement vs

https://github.com/okamstudio/godot/blob/master/demos/3d/platformer/follow_camera.gd

I'm also trying to understand: with godot, many stuff have to be done manually, but the corresponding Unity code feels like a breeze.

Is the 3d platformer demo a badly written godot code (in which case I was hoping a simpler re-write), or that's just the way things get done in godot?

— Reply to this email directly or view it on GitHub https://github.com/okamstudio/godot/issues/1013.

OkamStudio

[reduz]

that said, the 3D platformer demo is pending a rewrite eventually using kinemaric character

On Sat, Dec 20, 2014 at 7:52 PM, Okam Studio notifications@github.com wrote:

the 3D platformer uses a dynamic character controller, it is more difficult to use but interacts more efficiently with existing physics. Unity does not support this anduses a kinematic character controller instead. The fair comparison is to the 3D kinemaric char demo:

https://github.com/okamstudio/godot/blob/master/demos/3d/kinematic_char/cubio.gd

which as you can see it's much simpler

On Sat, Dec 20, 2014 at 7:07 PM, pikapikachu notifications@github.com wrote:

Can't the 3D platformer be simplified?

The corresponding Unity tutorial project is much simpler (and works a lot better and smoother):

http://unity3d.com/learn/tutorials/projects/stealth/player-movement vs

https://github.com/okamstudio/godot/blob/master/demos/3d/platformer/player.gd

http://unity3d.com/learn/tutorials/projects/stealth/camera-movement vs

https://github.com/okamstudio/godot/blob/master/demos/3d/platformer/follow_camera.gd

I'm also trying to understand: with godot, many stuff have to be done manually, but the corresponding Unity code feels like a breeze.

Is the 3d platformer demo a badly written godot code (in which case I was hoping a simpler re-write), or that's just the way things get done in godot?

— Reply to this email directly or view it on GitHub https://github.com/okamstudio/godot/issues/1013.

OkamStudio

— Reply to this email directly or view it on GitHub https://github.com/okamstudio/godot/issues/1013#issuecomment-67752943.

[seadra]

Yes!!!

[reduz]

godot kinemaric character controller is a little more diffuclt to use than Unity's one, but it's designed to be a lot more flexible. check tutorial for 2D (but it's basically the same in 3D) : https://github.com/okamstudio/godot/wiki/tutorial_kinematic_char

On Sat, Dec 20, 2014 at 8:12 PM, pikapikachu notifications@github.com wrote:

Yes!!!

— Reply to this email directly or view it on GitHub https://github.com/okamstudio/godot/issues/1013#issuecomment-67753469.

[seadra]

Thanks! Aha, the 2D tutorial also covers slopes.

BTW, can the camera code be simplied as well? Can we do something similar to the Unity camera code? (cast rays from predefined positions to determine the angle, linear interpolation for smooth rotations)

[reduz]

The camera code in unity is for a different type of game, you can do exactly the same in godot, using pretty much the same code

On Sat, Dec 20, 2014 at 8:18 PM, pikapikachu notifications@github.com wrote:

Thanks! Aha, the 2D tutorial also covers slopes.

BTW, can the camera code be simplied as well? Can we do something similar to the Unity camera code? (cast rays from predefined positions to determine the angle, linear interpolation for smooth rotations)

— Reply to this email directly or view it on GitHub https://github.com/okamstudio/godot/issues/1013#issuecomment-67753643.

[seadra]

You guys rock :) I hope you won't mind leaving me this issue open for the kinematic/simpler rewrite for the 3d platformer

[rraallvv]

Just wanted to post a link with interesting stuff about why kinematic is preferred over dynamic. Source: http://www.digitalrune.com/Support/Blog/tabid/719/EntryId/40/Kinematic-vs-Dynamic-Character-Controllers.aspx

[Ace-Dragon]

Either way, what hurts the examples is that the code could use heavier commenting.

A new user might struggle to figure out what each part of the code does, more comments will make it easier for them to determine that it is this piece of code that allows that to happen in the game.

[reduz]

that's reasonable, the demos need more work and I would appreciate help with that, as i'm loaded with tasks ATM

On Sun, Dec 21, 2014 at 3:40 PM, Ace-Dragon notifications@github.com wrote:

Either way, what hurts the examples is that the code could use heavier commenting.

A new user might struggle to figure out what each part of the code does, more comments will make it easier for them to determine that it is this piece of code that allows that to happen in the game.

— Reply to this email directly or view it on GitHub https://github.com/okamstudio/godot/issues/1013#issuecomment-67777832.

[seadra]

I think the main problem is, the code and the data isn't well separated in the code, and the code could be more modular.

I'm not sure if this the best way to do the things, but here it goes.

How about simplifying the code by making use of more keys in animations? For example, we can represent the speed/accel using a Node2D exported Vector2, and we can use it as a key for each animation (idle would have x accel 0, running anim would be somewhat high, jumping upwards would have a positive y accel and so on, something similar to this --looks cleanly structured and neat, doesn't it?)

Not just accel of course, I think any animation-specific const property (including accel) belongs to the animationplayer as a track. It shouldn't be switched among a bunch or if/else statements in the code. (This way, code/data is separated better. The code/data separation is very clear here for example, the code is a lot shorter and simpler, and it's a fully fledged platformer character which can do even more things -like crouching- that the 2D platformer character in godot demos :) Adapting that modular coding style will require using animation_changed signal in godot of course)

This would greatly help reducing the complexity in all platformer demos.

~~One problem is, of course, using a Node2D to represent a 2D vector (say, accel) is overkill. I wish we could add properties to the player class (such as a Vector2 to represent accel) that can be accessed from the UI menu on the right-hand-side (this, Unity really does! ;)). Then we could key them as tracks.~~

[reduz]

i'm getting tired of telling you that you can already do that in Godot. Please be so kind to sit tonight with a bottle of vodka as your pal and calmly read the docs.

On Mon, Dec 22, 2014 at 4:04 PM, pikapikachu notifications@github.com wrote:

I'm not sure if this the best way to do the things, but here it goes.

How about simplifying the code by making use of more keys in animations? For example, we can represent the speed/accel using a Node2D, and we can use it as a key for each animation (idle would have x accel 0, running anim would be somewhat high, jumping upwards would have a positive y accel and so on, something similar to this https://github.com/frogatto/elisa/blob/master/data/objects/elisa.cfg)

This would greatly help reducing the complexity in all platformer demos.

One problem is, of course, using a Node2D to represent a 2D vector (say, accel) is overkill. I wish we could add properties to the class (such as a Vector2) that can be accessed from the UI menu on the right-hand-side (this, Unity really does! ;)). Then we could key them as tracks.

— Reply to this email directly or view it on GitHub https://github.com/okamstudio/godot/issues/1013#issuecomment-67875865.

[seadra]

OK, I'll re-read the docs again. Last time I read the docs, they were quite incomplete but I see that the situation has improved now.

The reason I assumed it wasn't possible in godot was because I had a script like this:

extends KinematicBody2D

var Accel = Vector2(0, 0)

func _ready():
    # Initalization here
    pass

and yet I couldn't see Accel in Property/Value box of the KinematicBody2D, where the key icon appears. Sorry. I added export and it worked.

Anyway, that is not what I was mainly trying to convey though --I was essentially suggesting a way of simplifying the platformer code.

Back to docs...

[SuperUserNameMan]

@pikapikachu : why don't you enter the current holyday game-jam contest ? it could be a practical opportunity to implement and show the way you want to simplify the platformer code. And as this game-jam is open-source, your demo could become an example or a technical demo for the community to learn from : http://www.godotengine.org/forum/viewtopic.php?f=18&t=1172

[seadra]

I see that it must have a winter holiday theme (hopefully they have some stuff in opengameart) and the deadline is Jan 2. I can't promise I can meet these conditions, but sure, I will prepare a platformer demo with frogatto-style "mechanics" and put it on github (hopefully within 30 days).

(BTW, unless there is a non-documented secret way, right now, making a tilemap with godot is quite a task --assuming that you have more than 5 tiles. Something like a terrain tool would also be a huge time-saver)

[seadra]

I noticed a bug.

I have a Vector2D, which I use a track in the animations. The Vector2D doesn't get updated when the frame or animation changes.

And in some cases, when I click on the Vector2D value on the right-side menu, I get the current value in the input boxes, even though the displayed value on the right-menu is wrong. And in some cases, even when I change the value in the input box, the value is not actually changed. I have to remove & re-add the key value. Quite strange.

Should I open an issue for this?

[seadra]

Added #1046 (I'm still going though the docs. Due to the lack of shader features and some others, godot ended up being a personal hobby thing and I have to work with Unity3D at working hours. I'm loving it though!).

[seadra]

@UsernameIsAReservedWord: I won't have time to prepare an entry for the jam, but here's my platformer code: https://github.com/seadra/castlevanilla

[seadra]

This blog post explains it better:

https://meshist.wordpress.com/2015/01/10/getting-started-gotchas-in-godot-engine/

The platformer example code uses a boolean switch to check whether the player is currently shooting and toggle the state at the end of the update function. This is pretty confusing, and would only get worse the more actions are available. A much better way is to respond to events when they happen. To enable this, in your node’s _ready function call

set_process_input(true)

You’ll need an _input(event) function to handle the events. There’s a bit of a trick to handling a single keypress. You’ll need to check the name of the event against your input map, make sure it’s pressed rather than released, and make sure it’s not the result of a key being held down

func _input(event):
    if (event.is_action(get_action('shoot')) 
        and not event.is_echo() 
        and event.is_pressed()):
        shoot_bullet()

[akien-mga]

This issue is a bit too unspecific, so let's archive it. Please open a more focused issue or PR if you have precise ideas about how to implement the 3D platformer demo (which as stated previously is already a complex game and the kinematic char demo is likely easier to get started learning Godot).