Can you get it to have grenades that show you the viewpoint of the grenade. They should do that and nothing else. This grenade does NOT spin.
Get it to represent the grenade viewpoint using a stereographic projection where infinity is at the top pole and we cut out the top ~4/9 of the grenade's viewpoint sphere. (So i.e. in the 2D plane you get a finite sized viewpoint to map back onto a little rectangle on the bottom left of the screen where you get to see what your grenade sees.
See how far it gets with:
1. Realistic light-bending blackholes. There should be many different black-holes + wormholes bending light/bullets.
2. Shooter that works in hyperbolic space and ideally another in spherical space.
It looks like your game has a black hole in there somewhere but I'm not sure how it interacts w/ everything.
In 2023 I read Tristan Needham's wonderful book, Visual Differential Geometry and Forms. It inspired me to want to build a game where you could inhabit a non-euclidean space, but I was too busy and didn't get around to it. This last weekend my team at the Neo hackathon vibecoded a realtime multiplayer FPS from scratch on arm macs without an engine. You can see a quick demo here: https://t.co/YfVO8AP3mD
Agents were pretty good at creating graphical features by sending my screenshots and videos. They were able to program game-playing bots to test things like level winnability, hitbox correctness, etc...
However, for multiplayer "what it feels like" aspects of the game (which are critical imo for a real time fps) it was really hard to get AI to test it itself.
I think creating fast tooling to quickly reach the desired physical configurations for tests as well as having good tooling to truly test multiplayer is critical to develop games quickly with AI like this.
TBH this is one of the first times I've completely vibecoding without reading almost any of the code. Usually I read all PRs and might make some manual edits every couple PRs. For this app I tested by playing the game only. The only exception was around 10-20 skills I developed on the fly.
Crazy how effective Claude is. I used a combination of @cognition's Devin and Claude Code.
Opus 5.5 on high or extra (with or without ultracode) was better for graphical development, but Devin's cloud mac os VMs were absolutely invaluable to enable overnight work. Big fan of both of these tools.
What might inference engineering as a job for humans look like in the future and what skillsets might be most valuable?
What are some open questions/challenges that the agents are not yet able to do in a setup like this? I haven't read the paper/in depth blogpost, but surely they can easily handle heterogeneous models, hardware, and request patterns within reasonable bounds of what is standard + economically valuable right now on the small-ish scale (single node?). Are they able to optimize things at larger scales?
@simran_s_arora It looks like it should be possible to continually post-train these agents on this specific task while you do it, since you're producing tons of data.
Does it just naively work? and/or I'm curious if you tried it and have some observations :)post
One solution here is to send back a link to the user that contains the necessary (ephemeral) creds/tokens to do the refund with zero effort
(i.e. ai calls tool to send user the refund-clickable, ui then offers a way to click refund)
now only if user "messes up the click" will there ever fail to be a refund
(but they need to be able to make a single click)
Like anything where the LLM calls a tool to refund depends on some function of the user input. If that function is wrong, then no amount of what you do seems like it will ever stop a faulty refund from going through. Maybe there has to be user input (etc... etc...) but it can still misunderstand.