Timeboxing means iterations don't get longer
You ask how to shorten iterations. But that implies they are taking more time, which implies you're not applying time boxing. In any iteration when complexity starts to weigh more (or you have other unforseen setbacks), you don't change iteration length. You instead descope the incremental addition you planned at the start of the iteration. Some iterative methods suggest doing this assessment at the middle of an iteration (before it's too late). Read more about what OpenUP suggests:
When a team is falling significantly behind, or critical problems occur that prevent the team from meeting the iteration objectives, it may be necessary to descope work to ensure that the team delivers a useful product increment by the end of the iteration, while maximizing stakeholder value. Work with the team and stakeholders to revise the Iteration Plan and, as necessary, reduce the emphasis on less critical tasks by postponing them to a subsequent iteration. In rare cases, if the iteration objectives still seem impossible to meet, the team might consider terminating the iteration or reformulating the iteration to a new objective.
If you look at the first chart you can see that added value is less at later iterations. This means iterations still take as long as before, but maybe there's less new functionality (relatively) within each iteration.
As you say, iterative's strength is to reduce risk by getting feedback frequently. It sounds like you're talking about project complexity dogging you down on the later iterations? I don't agree this is a weakness of iterative. It's a weakness of badly managed complexity.
Theoretically, you put the projects biggest risks up front. This means you have a very unstable project, but as you manage the big risks, it is supposed to stabilize. Complexity, of course, is one of the risks.
Scripting languages and automated processes help reduce the risk of complexity, which can be called "accidental" complexity (and is discussed in another answer). Highly iterative yet complex projects (Chromium is a good example, even if it's not a game) have lots of infrastructure to manage complexity. Take a look at https://www.chromium.org/developers for lots of examples of things like coding advice to the BuildBot.
What this figure doesn't show is the project stability, which probably looks something like this:
Until the technical risks are well understood, you're dealing with simple prototypes