It's cool and all and I typically enjoy lowres renditions... unless, it actually impacts gameplay.
Since the gameplay is so much about 4D, clarity in what you see becomes more important and the extremely low resolution actually impairs the player rather than serve a positive (typically 'leaves more to the imagination').
It wouldn't take much of an effort to double or triple the resolution which I think would help the gameplay.
The reason it is so low res is actually more interesting than simple aesthetic choice. Think about the sensor(or eye) needed to view a 3d scene, it is 2d right. So this is a 3d sensor(voxels) for a simulated 4d camera. and then we are looking at the 3d sensor. (with our 2d sensor(eyes)), it's sensor inception.
So it is as low res as it is because it is a bunch of voxels simulating a 4d camera.
The dev put out an interesting video on the topic.
I tried pretty hard to increase the rendering efficiency on consumer GPUs. The biggest issue is that the main view is actually a 96x96x96 grid of "pixels" (or voxels). This makes scaling brutal: going up to 128x128x128 we'd double the total amount of pixels, to around as much as 1920x1080 resolution. Doubling the grid res to 256 would get us 16M voxels, which is about the same as two 4K displays. On top of that simple 4D object meshes scale much worse in terms of tetras than 3D objects do.
A quick solution could be to give the user a few resolution options, so they can bravely test the limits of their hardware.
So I've just modified the engine to allow you to specify a custom resolution in the URL:
(Higher resolutions might break rendering entirely if the accel structure doesn't fit in allowed memory anymore. I was able to push it to 160x160x160 on my machines)
I'll also try to think of other ways to make the rendering more efficient, maybe a BVH instead of my simpler grid-based acceleration structure? My background is not in computer graphics, so others here might have better ideas.
Fully agree. The low-res makes this unnecessarily hard to navigate. Which is a downside if your core gameplay is to teach players to navigate in a challenging environment.
And seemingly we have stopped considering the fact that when we engineer something, we consider so much more than the behavior specified in the ticket.
Behavior built on top of years and years of experience.
And the problem with AI is that unless you explicitly 'prompt' for certain behavior you're only defining the end result. The inside becomes a black box.
Isn't having a prompt file turning the black box into an explicit codification of those years and years of experience? That would make it easier to understand and disseminate.
I haven't found their limit, but I have found my limits, of waiting for them to do their thing...
I tend to re-enjoy handrolling code more. I delegate the stuff that annoys me.
We have a large multiplatform codebase, the issue seems to be more the time it takes to navigate the code and reason about it, rather than the size. Arguably the size is causing 'them' to be slower in that regards, but I haven't found the limit yet. And with compaction, it's even less of a problem.
They wouldn't copy each other for copyright infringement as much as it was a mark of respect. They carried each other's arts as an evolution and respect towards each other rather than copying; all bringing a small twist on what was before.
reply