tl;dr the Jak series leverages tech in harmony with its design for powerful resultsThe objective of game design is to make a good game. If you can double physics processing then you can have twice as many actors doing things "at standard" levels of computation. You can make the moves twice as nuanced, adding fidelity to the translation between input and execution by a factor of 2.
All of what you say is certainly useful from a technical perspective. But is any of that really the job of a game designer? It seems to me that such optimizations fall under the purview of software engineers and game engine developers. If a game designer is spending most of their time optimizing the back-end, they aren't actually designing games. What they are designing is game engines.
Don't get me wrong, designing solid, quality game engines is a very worthy endeavor, and the industry is much better off for having good engine developers. But it is not the same as game design. Engine development helps to empower designers, and has become a very important aspect of game development. But it cannot be equated with game design.
I was thinking about this, and your point, and now I think I understand what you are saying a little better, and I have some time, so I'll tell you my new thoughts.
Optimizations that are independent are definitely more outside of the designer's scope than most things. Though sometimes they have to weigh in on how valuable something might be. For example they may agree that a month of a programmer's time optimizing something may be worth the results relative to a combat feature that will get cut instead. That's a designer's call, because he can understand the benefits/costs of each choice.
But that is a weak relationship. There are however very strong relationships, all over the place. In fact, the very best optimizations, and the very best designs, often rely on a harmonious synchronicity between design and code (and all other aspects), because it's in the cooperation of those separate areas that the best results can be achieved.
I'll give you an example.
Jak 2 and Jak 3 (and the original Jak and Daxter) blew me away for a lot of reasons:
1. The worlds were huge.
2. The worlds were interesting.
3. The act of exploration was neatly tied to the action.
4. There were no loading times.
Actually, the loading times were there, but they were so well paced and hidden that I almost couldn't remember if there were any at all after a play session, until I figured it out. This is back when I was much younger. These are old games.
Ok, I'm going to show you why the handling of loading times had an enormous impact on the quality of the experience, and how their handling required deep design decisions to be made in-tandem with the code base's construction. Then I'll show you the kind of experiences that suffered as a result of not doing these things.
Jak worlds are divided into sections. In Jak 2 for example there were 3 hub areas. Each area was massive. You could travel anywhere within it without encountering a loading screen. Each hub connected to a few play zones, or mission-givers. There were loading screens in the transfer between them.
When you wanted to change sections you had to travel to the correct barrier and walk through it. Only in the rarest of circumstances would the screen go blank. Normally something would happen instead. You would see a door open and lock behind you, then another open in-front, revealing the new area. In that example the narrative justification was: "There are dangerous poisons outside. No one except the hardy and well-equipped can go out there. The city is a fortress for this reason. Transferring from inside out or outside in requires a double-door system that keeps the citizens of the city safe." With this explanation the game bought itself 2 uses for the doors. You had to wait in-between them and you couldn't cross them until you'd received the correct permission and abilities.
The loading screens between these two areas was hidden well. You barely noticed it. And not only that, they re-enforced the narrative, and often provided a break in pacing the player very likely needed. In-order to support this design all of the missions had to be designed around it. Missions never crossed boundaries mid-way, unless in special cases, and in those cases the breaks were used to great effect. Players also had to cross barriers relatively infrequently, so as not to be annoyed, so it was common to spend a good amount of time in one area before having to cross into the other.
This kind of structure was everywhere, and each time the loading screen was unique, justified by the narrative, and woven into the entire world. Loading screens evaporated, and the feeling that you had this massive world to explore has hammered into you. You could feel it, and it felt you.
This kind of design required the following insights by the designer:
1. If we program more robustly we can increase the size of a level a little bit.
2. We can use this size to layer missions in single areas to make staying within them for even longer times enjoyable than it otherwise would be.
3. We can build narrative constructs to justify the waits when crossing barriers, then pace our content so that such a wait is not only acceptable but valuable to the player's experience.
Every mission, level design, and the evolution of the plot had to take these rules into consideration, and none of it could have happened without understanding what boundaries could have been crossed with the technology. The design team saw a way to take small boosts in loading speed and size and turn them into an aspect of the experience that was fundamental to the quality of the game, and probably its legacy.
.
This kind of pattern is everywhere in design. Understanding what can be leveraged in tech can enhance the design, and if the designers are willing to accept the resulting constraints, the synergy between both can create something far greater than what would have been if either had been developed in isolation of the other.
If I realize that I can calculate something on the GPU 10 times as fast as I can somewhere else, maybe I can redesign my game in such a way to take advantage of that, and create an experience that blasts its competitors in some particular way. They might look at my game and think, "how is that even possible?" And the answer would be, not because of our tech and its team, but our ability to cut what wasn't necessary, to take advantage of an opportunity that so many others pass over, because it doesn't provide anything immediately experience changing if used in the standard way.
In the same way that modern physics engines can give weight to certain kinds of actions that couldn't be given before, designing around what is possible can create a leap in the quality of the possible experience, without having to wait for the tech to develop; and then when it does the game gets even better, and so do you at leveraging what's there.
p.s. HL2, and
so many games are fucking hammered by poorly placed loading times. The loads in HL2 are always right when you're getting into a groove. For a tech-heavy company Valve showed its weaknesses on that one. It was almost unbelievable given the power of its physics and AI at the time.
p.s. ps. One of the critical reasons of success behind Jak was the size of its world. It stood head and shoulders above most games in, "giving a big world for you to do lots of things in."
Player
