Game programming (or any kind of programming for that matter) ceases to exist, as the computer can come up with the perfect game for every individual itself.
I'm not saying we have Star Trek quality software to do our job for us, more like a Cray on every user's desk. we still have to make the games ourselves. but how would vast quantities of resources (memory and processing power) change how we did that? IE how might the architecture of game code change?
Forget games; I would use a computer to predict the future and become infinitely rich.
Bitcoin mining FTW! Until everyone starts doing it and a bitcoin drops to $0.06.
We could use ray tracing for most things which would remove the need for a lot of fancy effects. For example doing reflections would just work, ambient occlusion would just work etc.
good point. didn't think of that one. realtime raytracers would replace texture mapped triangle/poly engines as the standard graphics engine.
funny thing, when i started in games, i thought we'd have realtime raytracing in games by now. and i remember when we gamedevs used to wish every user had a math coprocessor so we could use hardware floating point instructions instead of slow floating point emulation or fixed point integers.- i've been making games for that long. and still no realtime raytracing.
Some points I thought of:
- Physics would be totally simplified. No more broad/narrowphase, bounding volumes, etc... just good old per-vertex n^2 collision checks (well you would probably still want to use bounding volumes for stuff like characters, but you don't have to anymore!)
- Pretty much any form of preprocessing could be gone. BSP-Trees, static light/shadow maps, you name it. This could heavily simplify code, especially on the tool side of things. Moved an object, need to notify the build pipeline and rebuild the static shadowmaps? Nope, not anymore, just take everything as it is and use it
- Any form of manual optimization would be gone. Memory layout, SSE, Multithreading (for the most part), Assembler... I can't speak for everyone but I for sure would prefer not having to write Struct-of-Array style code, for the most parts.
- Oh, and lets not forget about all the GPU-centered algorithms. GPU-Particles, GPU-Clothing, GPU-Watersimulation. Would be way easier if we could just write all those algorithms on one processor, I personally find regular CPU-code easier to work with than ie. compute-shader based equivalents.
all object types could have all possible member variables for all object types (unlimited ram), so you only need one type of "uber" game object type for everything.
Uh, why would you want to do that now? The reason we don't have "uber"/god classes is not because RAM doesn't support it, but because its harder to read through on 100k line cpp file, than it is through 1000 100 line ones (since you are only interested in part of the code anyways). I mean, be it composition/inheritance or whatever, but a door is a door, and not an "if(i_am_a_door) doDoorStuff();" alongside another thousands of those in a huge god class, for every possible game object, unless I misinterpreted your intention here.
so, how could unlimited ram and clock cycles simplify game coding?
Software rendering could return to the mainstream and all my software optimization knowledge would go to waste. I have mixed feelings about this.
so, how could unlimited ram and clock cycles simplify game coding?
It wouldn't.
Oh, it might be nice for the first person working on a game, because you wouldn't have to give a shit about structure, design or anything else - just bung everything in a function and off it goes.
Of course, by the time the 10th person comes along to work on that bit of code all they are going to find is a horrible mess which no structure nor reasons behind it and find it impossible to maintain which would lead to either a) them rewriting it or b) murder.
("But they could just add another bit...", "Sure, because bugs never come from unintended interaction of code...")
You pretty much just contradicted yourself saying that programmers wouldnt care about structure, and then right bellow you show why they would.
And yes it would simplify game coding because you no longer need to worry about optimization... which is a very large part of any game/engine/tools codebase. People above already even gave examples of how things would become simpler... no need for scene graph management, no need for data proprocessing, etc.
That they should and if they would are two totally different things; I've seen enough code by enough people to know what would happen...
The thing is that not having to worry about optimizations means that code would be easier to write and cleaner, not the other way around. I've seen a lot of code that's convoluted and unintelligible, and only because of optimizations. Just look at the things we need to do to organize objects in a scene. All of the data structures and nasty code to deal with them goes away if your entire object collection is just a linked list. Same goes for all the convoluted rendering code, that all goes away if you have a simple ray tracer.
I'm not saying we have Star Trek quality software to do our job for us, more like a Cray on every user's desk
With such a limited definition of "unlimited", we are already there.
As seen from the 80s game developers perspective....
For true unlimited, well, then we just end up at "simulate the universe, including a perfect game designer and artist doing the job for us, while predicting exactly what we want without us even having to say anything"
