Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

I didn't think about URL restrictions for the web exports, that is interesting.  I'll have to look into it =).

For 1st/3rd person view I only use one camera. It is for the inclined movement that I need two of them.
The body doesn't move in the direction of the camera but on the direction of the input. The camera rotates the body based on the direction it is looking at. When I tilt/incline the body based on the slope inclination I now have to be careful how I rotate the body. 
So I guess one way to do it, is to incline the base, and then let camera rotate only the visuals. But the direction has to be rectified so that it follows the direction the visuals are facing.  It seems to be easier to calculate that direction when the camera has the same inclination as the body. 
So I keep one camera on the body and one external camera that is not affected by the inclination.

I guess you don't really need 2 cameras for this, on the body you could use a node3d/marker3d and feed it the camera rotations, but it was easier for me to just duplicate them and I get the benefit of switching between them if I want to see the view from the inclined camera or the external camera.

Unfortunately, this kind of works and kind of does not. In my tests I found so many bugs that it was easier to start from scracth.

In the test movement it is only the camera that inclines with the body as I was still working on the other one when I uploaded the project.

I fully agree with the sliding being terrible. I am testing both CharacterBody3D and RigidBody3D. CharacterBody3D doesn't really have the sliding issue, but forcing it to walk on a 360 slope remains a challenge. The RigidBody3D has no problems with the 360 slopes but it has the sliding issue.

It seems I can't fix neither =). 

Thank you!

(+1)

We tried posting one of our games on CrazyGames and when looking things up for it they recommended the URL restrictions. It does mean needing to maintain a list of all the possible domains for anywhere you want to host, but once setup it shouldn't be too bad. For basic jam games we don't currently bother, but it is on our list to add to our template so it is always available when we need it.

Having extra pieces that make testing easier is often good, especially early on. We have plenty of debug extras in our games, with only some of them exposed for testers who know where we hide them (5 quick clicks on Development Preview to unlock and 1 more to open the unlocked menu). While trying to figure out the camera stuff I agree that the 2 camera approach is a good one. I can see how having both be cameras can make it easier to compare things when the math doesn't seem to be working. I'd so much rather be able to switch between the views and see how they compare than just look at the math and end result. You seem to be on the right track, experimenting with different ways to do things to find what works. Personally, the only issue I have with the current system is the small hops interfering with my jump timing as I approach an edge.