Skip to main content

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

I agree with being prepared, and these days having an EULA is reasonable for a full game. Maybe keep it in game, but put it as a button to view it. Godot with GDScript does have an issue with being easy to steal as a non-compiled language. Using custom export templates with encryption does make it harder, but only so much. We do use the custom export templates option for all our games now. Those who are doing the ripping off of games aren't really going to care about any EULA agreements. Most are also likely going to be in places where any legal action will be difficult to take, and with or without an EULA, trying to get big companies like Google, Apple, or Steam to care about an indie claiming their game was stolen can be a pain. Each game having its own encryption key, and web exports using URL restrictions, seem to be among the best current options for indie devs. It won't stop those with the resources, but it will make it require more effort, which might stop some. Having a license agreement in the game is reasonable, and is something we should think of adding as well. We do have a basic copyright on the About/Credits page, but adding a bit more somewhere may help should any legal issues arise. Personally, I'm not ready for adding something that pops up on load, but having it from the main page might show up in the future in our games.

Honestly, the movement test's slippy movement was what drew most of my focus. I just retried it, and the tilt didn't seem too bad. The tilt was only odd in that I am controlling the camera with the mouse, so it changing was just an annoyance that was then adjusted as need by the mouse. Not doing 3D myself, why do you need 2 cameras for the workaround? Wouldn't you just have one outside the player that has its position adjusted to match the player's position every frame? Even with the dual (1st/3rd person) view options, I would think that you could have a single camera that tweens between the 2 positions as a smooth transition effect, rather than 2 dedicated cameras. Even with 2 cameras, Wouldn't they just have preset offsets from the player's position while moving with the player? Some day we will learn more about the 3D stuff. The kids really want to play around with it more, but it opens up so many additional details to work with, that we are sticking with the 2D stuff we know for now, and trying to have a solid base for the many aspects of game dev before opening a new can of worms.

Best of luck to you as well!

(+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.