Thank you for sharing, I appreciate the emphasis on local speed and privacy. As a current user of Hex (https://github.com/kitlangton/Hex), which has similar goals, what are your thoughts on how they compare?
The standalone Touch ID key button is just under the size of 2x2x1 Lego. I integrated mine into a space diorama set for better vibes: https://imgur.com/a/Im7t9Xb
Excellent article, and I appreciate how you gave an overview of solutions that didn't make sense for you but were otherwise important to know about.
Could you expand on how your pathfinding works for both ground-based and flying enemies? I've been trying to wrap my head around how to handle this on my own game, and trying not to invent a wholly separate solution for enemies than can avoid obstacles vertically.
The scaffolding is built from convex volumes, and I know which cuboid faces are "walls" and which are "windows" so I link the windows into a graph where the shared-faces are waypoints and do A*, using straight-line distance as the cost function.
Big obstacles are just built from the scaffold itself, and small obstacles are avoidable by just doing "whisker-traces" to veer around them (the navigation path is a movement hint used to calculate accelerations, not followed strictly).
Yes, but that's why ~~good~~ fun enemy AI for games is both an art and a science.
My approach is that the path from the pathfinding algorithm is just a known good solution. The path the agent gets back from the algorithm doesn't have to be just a list of Vector3's for the window centers. It could get back a list of each window quad instead, and then aim for a random point in the next quad shifted by the distance between the two quads. You can also do some raycasts from each agent occasionally to do local-avoidance-type behavior (which you'll likely have to do anyway so that enemies spread out a bit and avoid non-static geometry).
I'd also ask if this isn't somewhat accurate for how people would do things? We have specific rules that we have internalized on what side of a road to drive on. But, absent those rules, it isn't uncommon to just drive down the center of the road. Largely expected on many surface streets that don't have brightly painted lanes and large shoulders.
To that end, you could always encode the rule of what side of a window to aim for? Something you probably want to do if you are going to be aiming for bidirectional agents going through them?
Very fun. Unfortunately there is a way to, in my opinion, cheese it. I made it to 2485 on my second attempt.
Reversed to avoid spoiling the game:
.gard ot reyalp eht gnicrof yb devlos eb dluoc siht ebyaM .kcab ot kcab tsrub eht reggirt ylbailer ot mhtyhr a ni taht od ot eunitnoc tsuj nac uoy ,kcilc ot ecalp thgir eht dnif uoy fI
That's great feedback, thank you. I built a rudimentary control scheme on top of the minimal Crisp library and will take a look into doing a little more with it.
Good job. Problem with a game like this is that it's too deterministic, you use the exact amount of impulse to aim the disc at the exact same spot every time. If you have decent handeye coordination it swiftly becomes rather trivial.
The real game is less deterministic purely by having to contend with messy real world physics. If you want to make the game a little more engaging, I'd recommend trying to figure out a way to mix up where you have to fire the shots from, etc, add blockers to get in the way to shuffle the timing, etc.
This is true, I jammed the game out rather quickly but next thing I’d try is a hold-for-power control scheme (like the interactive demos in the article)
as someone who has made huge mammoth games that I have never finished, this is the most well executed stylistic epic damn thing EVER. From the sounds to the low res, love it.
The workaround/hack is to send your token via the "Sec-WebSocket-Protocol" header, which is the one header you're allowed to set in browser when opening a connection. The catch is that your WebSocket server needs to echo this back on a successful connection.
This is excellent! There used to be a similar app called "Sticky AI", but the company abandoned it after a while and the backend for the app shut down. This works great and has no external dependencies.
For those who don't know either company: Unity is a popular 2D/3D commercial game engine, and Parsec is a low-latency remote desktop tool that initially focused on gaming, but pivoted to an enterprise product for remote creative teams during the pandemic.
As someone who used Parsec for ages to game at 1440p 60hz via AWS on my old-as-sin MacBook: thank you for the amazing work you and your team mates did, and I'm stoked to see the company have such success!
I use parsec at home to run a gaming machine in a gaming room... and use the same machine as an art creation machine in another room, parsec is one of the few solutions that plays well with pressure and stylus, custom resolutions and even 120 hz (surprisingly useful when trying to have responsive UI in art apps)
It’s the remote control product, with some extra features and permissions for teams (useful for having a cluster of devices and assigning them out to remote workers who need specific hardware etc).
