Skip to main content

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

So, being greeted with a big EULA right at the start is not something I'm used to for a jam game. I did read through it, and it seems to be typical CYA legalese. Of course, "agreeing" to EULAs and T&C is also considered to be one of the most commonly told lies in the world, so plenty will just click and play without reading. I will say that starting a jam game and seeing something like this would generally have me just stop there and move on, as most jam games aren't really worth "agreeing" to random EULAs. Between our past interactions and this being a submission to our jam I am willing to take the time to read through it, but it is something to consider. Of course, these days people are crazy sue happy and adding something like this to protect yourself is understandable.

In the intro text, the edges are being clipped. The left edge is most notable.

The intro story has me questioning who your character is, who you are dealing with, and if this is a bad deal to agree to.

When you are close to an interactable object it shows text telling you to press E to interact, but if you cannot interact, then nothing happens. There should be some form of player feedback that you can't currently interact. Either the text saying you can/lack the required item to interact, or even a negative sound when you try to convey that the key press did nothing. I know this is in an early state and may be on the list of things to deal with, but still want to point out the things I notice.

3D platformers are not really my thing. I often find I have a hard time translating the camera view into real world positioning that my brain can process well for judging where edges are and when to jump. In this game, I think the platform textures could use with additional texturing/shading to give more definition, and help judge distances. As bad as I normally find 3D games, the fairly plain surfaces made it harder to judge. I will say that the background was good and allowed enough contrast that adjusting the camera I was able to get enough detail to make some progress.

I made it through the green zone, but it took several tries and was a challenge. I almost lost when going down an angled platform and it suddenly had me doing small hops, right before reaching the edge. I landed just before going over and was able to make the jump to the next platform.

I used W, and sometimes S for movement, and the mouse for almost all rotation/direction changes, except when testing the controls. The mouse being able to adjust your direction was helpful in landing some jumps where it was hard to judge the next platform exactly from the previous one, as I could respond faster, and by just the right amount, with it.

I did try your other movement test. The inertia/friction on it made it feel like the PC was running on ice or oil. That would not be fun to play, at least for me. I also had trouble getting it to release the mouse cursor and ended up using keyboard shortcuts to close the tab to exit.

I tried the blue level and got to about 4 platforms from the end. With more attempts, and slowing down a bit to do more estimating distances at the end, I'm sure I could make it. However, it is really taking a lot to focus on the edges and timing things, and I'm not up for more right now. One of the kids has already played, and they got further, so will be able to provide some feedback on later levels.

The slope movement definitely needs work. Those hops are very problematic. I don't do much with 3D, so don't know enough to be sure about might fix it. I have some thoughts, and maybe they will translate into something that can help. My take on the issue is that as you are running down a hill your forward velocity is greater than the gravity pulling you down, resulting in you being off the ground, which is causing your character to switch to a jumping/falling/in air state. Obviously, messing with the overall gravity would affect the feel of the game and be a pain to balance properly. Maybe you could do a local increase in gravity on the sloped platforms, but even that would mess with timing. I'm not sure if the 3D models can be refined to fix the issue. With this in mind, my "fix" would be to add some logic to the checks for if you are in the air to consider if you just pressed the jump button to start leaving the ground, and if not, check if you are a short distance above the ground, probably with a Ray Cast. If you did not jump, and are above ground, and the distance is small enough, then treat it like being on solid ground. You could also limit this to only trigger if the ground is marked as a slope, and even based on travel direction being downhill. Maybe also add some logic to adjust the position so you actually are on the ground. This could be a manual calculation of the Z position so the player stays touching the ground, or possibly increasing the gravity a small amount for a short time, maybe a single frame at a time, to pull the character down. Again, 3D is not my thing, so my thinking here could be completely off, but maybe something in it can be a seed for something that will work.

This seems like a good start. There is already a bit of story, even in its early state. They layout of starting from a central location and going out to each zone to get the next key works. The music fits the game. The geometric platforms work for the game style. It is a challenge, but I was able to complete the first level without too many retries. I can't speak to later levels or level progression, but it was decent. It may be a bit tough for a first level, and you may want to start things off with more of a tutorial/training level, but it wasn't so difficult that I gave up before finishing it.

(+1)

Thank you for the feedback!

I agree with all the things you said, a bunch of them are already included in my plans, so I guess I am on the right track.

I tried to copy how most steam games start and add an EULA, I understand and share your distaste for it, especially for game jams. I planned this game to be less of a game jam kind of project, but I was struggling with getting feedback so adding it to this jam felt like a proper thing to do.
Looking at most itch games I guess this is not that common here, mby I will modify the web version to not have it (in normal game jams I do not add the accept dialog and just leave it as a download file on the game page).

There are also a bunch of conversations about game obfuscation in the Godot community witch kind of lead me to have a more proper EULA.
It used to be a lot shorter and simpler. For the kind of games I am making right now this is a bit much indeed.
A quote that I found out around the time I made decision to add a proper EULA and kind of resonated with me was:
"Failure to prepare means preparing for failure."

Not that this will solve obfuscation or any of the problems that could appear, but more like a minimal thing to do.

 Thank you for pointing out the slope problems. This seems to be one of those things that divide people from "this is fine" to "you should fix this". 
It turns out to be a bigger monster I have to tackle than I expected. Right now the character does not tilt when he is on slope (that seems to be how most simple games like this do it). As a result the character walks forward instead of down forward on slopes, making it act like a old cartoon character that remains in air for a bit before he remembers there is gravity.
Playing with the gravity doesn't really change much, I had an older test in the past that delayed the in air check for floors, giving the player more time to react. People liked that more (if I give up on the tilt idea I will probably get back to this solution).

The new movement system (thank you VERY much for checking that out!) does tilt the body but it also tilts the camera.
So I tried to make the camera follow the body, but now the movement starts to break. The rotation of the camera and that of the body no longer align and my math capabilities are showing their limits. 

I tried a workaround to have 2 cameras one on the body and one outside of it, and move the body based on the one that is inside while the view from the outside camera is no longer tilted. It kind of works and it kind of doesn't. The movement feels worse than the initial cartoonish movement (when it not breaks). I am also questioning if tilting the camera is something I need to fix, mby the camera should rotate with the body. I do admit that it makes one a bit motion sick ... that is not good...
Having both first and 3rd person camera options is an addition hurdle as well.

Just sharing my problems in case you will ever face something similar. =)
Did you take any notice of the camera tilt when playing the other movement test?
I was surprised to hear your mouse got captured, on my devices it does not get captured. But it should do that, so I wonder what is wrong with my devices =), probably just another browser error.

Thank you a lot for taking the time to play my game and give me feedback!
Best of luck with your games!

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