Skip to main content

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

1. The tools don't actually have hit detection  but rather the controller holding the tool is being detected. So, even if you swing the tool, if your controller is not in contact with the block, nothing happens. 

2. The avatar seems to be about 2 blocks tall. So, if you mine only the top block of the side of a wall, you can move forward without mining the leg height blocks. You go over the leg height block into something like a crotch but then, when moving forward, lower body is clipping through the  leg height blocks. All ends up weird with half of your body phasing through blocks.

3. The jogging only is triggered when, after the headset goes up above the starting height by 2 inches or so, the headset goes down to the starting height. Why not trigger motion going up and down both ways? and reduce the detection height to 1 inch. Side note, nothing for going below the starting height and up. 

4. You need to at least instruct the players better on how to place blocks. fling the controller holding the block 3 ~4 times in the same location is not easy to understand at first.  Personally, I don't get why there is a need to include mini-blocks floating in the air. Why not let them drop in place in unfinished mode? You can make a hammer to hit the blocks to finish them up.

Thank you so much for the continued feedback! This is invaluable and really motivating to continue working on the prototype :-)

1. I will check/test it again this afternoon; could easily be that I made some mistake with marking the interaciton points on the tools. One think to keep in mind though is that at the moment you still need to move the Controller ~30cm for a hit to trigger (not the interaction point at the tool); the idea was that you still need to move signficiantly to work on a block.

2. I can try to block the movement forward when there is a lower block in front of you. Would indeed make more sense. But it will probably take me some time to figure this out as I still would like to keep the "autojump" feature that you can run up blocks which make the logic to check what should happen a bit more complex because now I just run forward if there is no block in front of your head and move up when there is space above you.

3. I'll try to start the detection also on the "high" point; this is a good suggestion (in my experiments my gait was that I always went down when starting to jog in place; but that might easily be totally different for other people). One problem with the thresholds is that I need to make sure that the walking does not trigger easily when performing other motions (especially mining, looking around or leaning); also the latency should be as small as possible (which means I can't look to much into the past to make the decisions); if you are intereseted in the details you can have a look here: https://github.com/NeoSpark314/godot_oculus_quest_toolkit/blob/master/utilities/oqrec_recordings/run_in_place_analysis.ipynb this is a (slightly older version than in v0.3.1) of the step detection algorithm; there you also see that at least for my gait my running always started at a low point.

4. Yes; this needs to change. It was just the fastest solution that came to my mind when I wanted to release 0.3.0. The suggestion with the hammer is awesome! I will try to add this; how do you think "unfinished" should look? I could make it that you can finish it with a hand but later when you crafted a hammer it goes much faster. What do you think: should an unfinished block just stay there for ever? or should it disappear after some time?

Thanks again; btw. If you want you could also reach me via Discord: NeoSpark314#4701

1. I found out when the tools did nothing. I got very close until my controller were hitting the block and there was a reaction

2. It could be complicated I guess. You'll have to check both whether there is a block in front of your head and whether there is a block above that block. At this moment,  "autojump" feature in this situation becomes  "autojump" and "crouch" but not easy to visualize "crouch" in VR.  There would be less issues if the avatar was one block tall but that creates more issues with other game mechanics 

3. The only thing I have to add is that people barely move above their starting height playing VR in the vertical  movement.  I bet even if you get the detection down by half an inch, it would be fine.

4. Not really original idea on my part. Games like "medieval engineers" on PC did it before. If you want to be simple, make them a bit transparent? or just put in a block frame. It get the impression you want to be less arcadey than base Minecraft.   "medieval engineers" was bit bit more like that. Slightly more realistic build simulator games. 


Will check the discord ID. I'm a novice with that service at the moment.

With which tool was the problem you describe in 1. ?

I just did a brief test with pick axe; there it worked for me as intended: https://www.youtube.com/watch?v=6vBfgo3_J1A  (in the video my controller is far from the actual voxel I'm digging with the tip of the pick)

I did not know about Medieval Engineers; this looks really cool (and inspiring) from the videos I have watched. Thanks for sharing this!

Will try to get you a video but my version died with just a black screen coming up. Need to remove and reinstall the program.

Do you already have the version 0.3.1 installed; this has a reset start position to work around a bug in 0.3.0. With 0.3.1 you can just update without uninstall (uninstall would loose your save file if you did not back it up before using for example SideQuest)

(1 edit)

Already got the version 0.3.1 . My problem was that the game didn't boot properly. Just black screen. Seems I'm having overall issue with my quest. Doesn't seem to be booting at all. Will get back to you.

sent a friend request on discord.  "uo_weyun"