itch.io

Heh, nope! (I actually considered adding a NO AI sign to my NO AI sign, but it became a bit too messy.)

When I saw the ROCK PAPER SCISSORS theme, I clevery deducted that I could use TextMesh with https://www.copyandpastesymbols.net/scissors-symbol.html and it worked mighty fine, but it turned out to be broken in HTML5 export. So I ended up dropping it. Still, I felt awful clever while it lasted.

Stellar work, pretty much the best news I've had this year! Noticed you included Neopaint. Quite some time since I saw that one. For some reason, that one really hit me in the nostalgia.

If you want, you're welcome to add the whole updated collection to your itch.io page, call it Shareware Motherlode II or something? Although I really like the build-in update prompt, a single download might be easier.

Thanks for an excellent jam. I learned a few new things; picking up objects, jumping, adding 2D screen and interacting with it, and using Bolt physics. While I couldn't play any of the Quest only ones, seeing the fancy AR stuff was pretty mindblowing. I consider getting Quest myself, so I can playtest that platform too.

Thanks, found it—player_calibrate_height on PlayerBody. Now that I'm no longer hovering above the floor, I see that my table was way too high. I think the player height thing was somehow related to my early failure at scaling the player down to dollhouse scale via world_scale. I don't want to change it back, though; I like that the entire game takes place in a single space.

I think my general problem is that I don't really understand VR in Godot all that deeply. The XR Tools gives some neat shortcuts to most of what I need to do in an VR space, and this works for 99% of the game, but every now and then there's those weird little thing which isn't pre-coded for me—registering a button press, turning the player towards 90.0, rendering to specific left or right eye, triggering a double jump (kinda fixed that), extending XRToolsPickable (screws with XRToolsGrabPointHand) ... probably more. Still, this jam has pushed me to actually look at what goes on inside the XR tools, which I sorta considered to be some kind of overworldly stuff not meant for lesser beings. So things a starting to make a little more sense.

I always assumed that player height was something which are handled by the upper layers, such as openVR, which decided where the floor are positioned, and the in-game player height is just "how far is the HMD from the floor"). But GodotXR have a hardcoded player height in godot_xr_tools/player/standard_height which defaults to 1.85 meter. Changing this values makes your shorter and taller in-game.

Is it me who are ignorant of how height work in VR?

Also, should I add some set-player-height settings?

Turning off eye_gaze_interaction grants me two fresh errors:

E 0:00:00:0993   is_top_level_path_supported: OpenXR: Unsupported toplevel path /user/eyes_ext
  <C++ Error>    Condition "required_extension == "unsupported"" is true. Returning: false
  <C++ Source>   modules/openxr/openxr_api.cpp:200 @ is_top_level_path_supported()

E 0:00:01:0008   is_interaction_profile_supported: OpenXR: Unsupported interaction profile /interaction_profiles/ext/eye_gaze_interaction
  <C++ Error>    Condition "required_extension == "unsupported"" is true. Returning: false
  <C++ Source>   modules/openxr/openxr_api.cpp:220 @ is_interaction_profile_supported()

Yes, it was enabled. (No clue why I enabled it)

Thanks for reporting! I've noticed you had the same problem with SPACE WALK. Unfortunately I don't have Quest, so can't really test those HMDs.
Do you want a link to the source? (I won't link my source project publicly, since they contain paid assets)

Thanks, functionPickup had it right there, dunno how I missed it! The button  press kinda still screws with my head, but I'll keep at it.

Thanks, this was very illuminating!

There were some framerate voes, I believe? I'll see if I can optimize it a bit.

I think I'll add a goal. Had wanted to do that, but then I didn't bother. I also thought that people would just naturally avoid the spikes, so no need to make them actually do anything. But I guess I need to figure out how to detect if the player collide with trap or goal zones.

Another downside is the level randomly exploding. I'll try making the pieces keep their position instead of snapping to the hand. Maybe there is some hack I can use to dampen their movements, too. Also, making the pieces slightly thicker would help keeping them upright.

1) is there a way to adjust the pickup distance? When I play my game, I often accidentically pick up stuff from the table, so it would be nice if the pickup distance could be shorter. (I'm using the Valve Index, and picking stuff up is finickry.)

2) How do I detect a trigger press? This is such a basic thing, but I have still not figured it out, instead relying on the presets shipped with Godot XR Tools.

3) If you tried my Feet is Jump! entry, could you give it a solid roast? How could you forget X, this here aspect was the lodestone of crappiness, that sorta thing!

Excellent entry. If you don’t have any stargazing experience, the haptic hints works very well. Could be improved by letting the cards be less bright, and they could also have been rotated a bit so you don’t have to twist you wrist as much.

Greater than the sum of its parts. This is a walking simulator where you walk around on empty planets. Completely empty planets—they don’t even have any texture. So this shouldn’t be much fun. But the music and the environment just feel soothing, and the novelity of walking on miniature planets with gravity, which you can sometimes traverse in a few seconds, is a fun one.

I liked this mix of outer-space photo safari and hidden object. The one downside is that there’s only teleport locomotion. Not entirely perfect, but got potential.

Now that our entries are out there in the wild, I thought it would be fun to hear how it went for you guys?

Personally, I started out in good style by forgetting everything about the jam, and only remembering it on July 9, thus losing a day. My devlog for July 9 was "Started this project. Gonna fail the jam, know I will." and for July 10 it was "Wow, so gonna fail!!!" but things kind of picked up after that.

I originally wanted the player to switch size via world_scale, but the small size caused some screwup, so I abandoned this, instead hardcoding each dollhouse scale platform to adjust the position of their true-scale twins.

As research, I watched https://www.youtube.com/playlist?list=PLfX6C2dxVyLxXl3gJwakzdqRaV7WKlqFR and learned how to add UI, pick things up and jump. I also got too anoyed with the awkward physics, and finally tried out Jolt. Worked straight away. For some reason the player was suddenly dollhose scale like I originally intended. No clue why, but I got rid of it by setting world_scale of the player to 1.0 at startup.

Boosting the jump height to something pretty overpowered really improved the experience. I think this is a general truth in VR; having more physical provers than in real life simply feel empowering.

When the deadline finally arrived I was plenty beat, but satisfied I had something ready. And then, the deadline was expanded to what was actually promised! My brain simply refused to do any more work, but in the end, I got it to give the game a few more updates. I made the player body no longer collide with the pickup object (turned out to be a massive improvement), added some traps and adjustable starting position and fiddled with the lighting and visuals. The trailer still shows the state of the game at the first deadline.

So, what's your story?

No, never used that one. But my game does have some screen you can interact with via Viewport-2D-in-3D

Luckily, the game seems to run fine despite the error. But I'd like to get rid of it.

E 0:00:02:0239   get_height: Viewport Texture must be set to use it.
  <C++ Source>   scene/main/viewport.cpp:137 @ get_height()

E 0:00:02:0239   get_width: Viewport Texture must be set to use it.
  <C++ Source>   scene/main/viewport.cpp:127 @ get_width()

This is where the error happens, apperently:

I guess I must have done something—but I'm unsure what it is.

Yeah, that extra day they added confused me a great deal too. Hey, tried running your game on PCVR, and it complains about a misssing pck file.

Me, I thought that maybe you didn't count the weekend. But It's a relief that a week still has seven days.

I use this code to get the raw player height, without it being poluted by whether they are looking up or down (which raises/lowers the HMD). Is this the best approach? It seem to work for my index.

var head_up_value:float = 0.08
var head_down_value:float = 0.1

func get_cam_y_corrected():
    var corrected_cam_height:float = 0.0
    if $/root/World/Player/Cam.rotation.x > 0.0:
       print ("correct with head_up_value")
        corrected_cam_height = $/root/World/Player/Cam.position.y - ($/root/World/Player/Cam.rotation.x*head_up_value)
    else:
        print ("correct with head_down_value")
        corrected_cam_height = $/root/World/Player/Cam.position.y - ($/root/World/Player/Cam.rotation.x*head_down_value)
        return corrected_cam_height

I'm just about to finish off what must count as my finished game. One thing I spend a unreasonable amount of time on was hunting around in vintage books for wallpaper textures, and creating a wallpaper with gold print. So if you want that, here it is:

https://kasper-hviid.itch.io/feet-is-jump?secret=m7x9t9ObYrpbuAXf5tAWbXx8Mc

Thanks! My game is still a mess, but now it's a mess with double-jump.

I know I can trigger the normal jump with $Player/Body.request_jump() but I don't really know how to do the second double-jump. Anyone have any experience here?

Thanks, good to know the reason behind it. I'll try adding a more noteable button.

Earlier, when I made a browser game and selected Embed in Page, it would embed in page. If I clicked Fullscreen, it made it fullscreen.

Now, clicking Play game opens it in a new maximized browser window. This can be made into fullscreen, but the button for this is easily overlooked. This annoys me a great deal, because I want my game to be played in pure fullscreen, but the design discurages this.

Does anyone have a workaround?

I guess some folks love it, but for me, it is just frustrating somehow. I would much rather prefer a fixed price. Does anyone know what the norm are here?

Nothing wrong with pixelart, but I just want to try something else. But this is hard, with roughly 99% of the sprites being pixelart. I found this old thread, but it just refuses to work. Am I doing it wrong? Is there another workaround?

Dunno what goes wrong, it runs fine on my Valve Index. Which HMD are you using?

Nope, sorry!

I've noticed there were no post about this, so thought I'd made one, spreading the word and whatnot.

The deadline for submissions is closing in, so hurry up!

Bundle Submission for the Worthy of Better, Stronger Together Bundle for Reproductive Rights

Thanks, glad you like! Let's just say it's Public Domain.

Absolutely! AGK is basically BASIC, with some extra stuff added, so you pretty much code everything from scratch. I personally prefer AGK Basic over AGK Studio, the later feels a bit bloated, with multiple dockers and such, whereas AGK Basic is more pure code.

The concepts are explained on the images on the right of the sales page. But granted, it's very easy to overlook. Thanks for good feedback!

Ah, thanks! Didn't have Java installed, so I just tried unzipping it with 7-Zip.

Hi, I think your game is missing an executeable!

Hi, thanks for your interest! Yes, you can add add your own stereoviews, by placing the left and right images in \media\stereoviews Check out the manual for further details

I have quite a lot of games, both bought and freebies, but the library navigation is pretty much unusable. I know there is a website to help navigate those in That Very Big Bundle, but is there any script or something for my entire library?

Yeah, free games are hard to sell. I think people naturally assume they aren't worth much. And you can't put them on sale. I wonder if it would give more downloads if I stuck a price on them, so I could put it on sales...

Even if your game is pixelart, avoid use that pixelart font on your sales page.

Bookmark itch.io pages with juicy design, and use them for inspiration. Personally, I'm quite habby with the design of this one: https://kasper-hviid.itch.io/the-shareware-motherlode

Also, don't be humble. Try selling your stuff as aggressively as possible. Like, if you made a mobile game called A Dream of Amber, which has a truly original concept and is totally addictive, try using the flimsiest of excuses to push it into the conversation.

An advice I once heard is that for the hours spent making your game, use half that that much time promoting it. Don't make the mistake of feeling burned out by finally finishing the game, clicking "publish" and then moving on to your next project.

Understand the concept of the marketing tunnel, that is, the way a potential buyer slowly gain more interest in your game. At the top level, he doesn't care about you game at all, he doesn't even know it exist, so you only have a few seconds to make him interested.
- At the top opening state, the potential buyer looks a the front page of itch.io and let his eyes pass over the games available. Here, you have about 0.1 second to make him focus his attention on your games cover image instead of any of the others.
- At the next stage, his eyes are focused on your games banner. Good. You now have about 3 seconds where he skims the art and read the title.
- At the next stage, he may hover his mouse over the cover, to see what pops up.
- At this stage---oh boy---he actually clicks!  Once on the sales page, he skims it over, quickly deciding if he want to venture further, or go looking for another game.