So I'm wondering if there's a way to speed up this procedure?

First of all, you should be able to save and load your game at any time, even if it is not part of the game design. This way you can prepare a game situation, save it, and reload it for debugging purpose on demand.

Further on, changing code while continuing the program, often called hot-deployment, depends on the language and tools you use. It is possible to do it with scripting languages more easily, because many scripting languages like lua have the ability to compile a text string at runtime and add it to your running environment (or replace existing functions). But this is only half the truth, because changing the code base will not help you in all cases. Often bugs change the state of the game (corrupting gameplay data). In this case changing the code will not help you.

Here is a quick list of tools/features which helps you, top is most important in my opinion:

1. Debugger !

2. Logfile !

3. Save/Load

4. Ingame console and/or web interface to check the game state and change parameters.

5. Quick start: start the game and load the current game level immetiadly

6. Hotdeployment (be aware of chaninging game state !)

From the beginning of designing my game engine, I've decided it would work deterministically. This approach is best if coded like that from start, but could still be possible to implement later in the process:

Being the game deterministic, the engine saves and journals all sources of undeterminism (player keystrokes, random number generator seeds, etc) and saves them to a file. The file is a mere KBs big even after an hour of playing. It's size depends on the amount of undeterminism sources you need to track and the framerate you're running at (i.e. simulating at 60hz needs double the space of a 30hz simulation)

When the game is closed or crashes (I use SEH to catch the crash and save the journal) I can later replay the whole session (I can even fast forward, but how fast I can fast forward depends on how powerful my system is, as it must simulate all frames until the crash without rendering waiting for vsync).

This has proven to be an invaluable tool. I've caught so many crashes in no time (specially those hard-to-reproduce ones), also experimented, and even see through the debugger how a variable's value evolves through every frame.

There are a few caveats:

1. A few rare bugs may corrupt the journal, but this is extremely obvious and often blatantly obvious.
2. If the bug is caused by an untracked source of undeterminism (i.e. an uninitialized variable is the most common one), the replay will be different on every run. However you can still use this to try to understand when is the moment that your simulation starts to diverge and nail down the source of undeterminism. You can also start removing stuff until the replay is simple enough.
3. Sometimes the SEH fails to save the journal, and the replay session is lost.
4. Changing code to fix one or more bugs may cause your replay session to diverge before the crash, thus it's no longer useful in seeing if the fix actually works.

I can't tell you how to write your journal, as it is specific to each game engine. However, I point you a few starts:

http://gafferongames.com/game-physics/fix-your-timestep/

http://gafferongames.com/networking-for-game-programmers/debugging-multiplayer-games/ -> Keeps a journal for debugging networked games, but it's basically the same thing except for single player, and you're not journaling network packets, but rather key strokes.

More modular coding generally makes debugging easier and quicker. "Modules" of code may be permanently or temporarily (for the purpose of development) tied to interfaces which are specifically designed to aid the debugging tool (or tools) by turning sections of coding ON or OFF or SWAP the suspected buggy coding with your revision attempt. While we are on the issue of preventative structure to aid debugging, class files ( or jar ), dlls, a organized bin folder, and other modular forms of coding have some advantages in the debugging. You should be able to better isolate where the bug might be if your modules of coding are well labeled. For example, you would expect that a bug in the implementation of a particular entity would not be in seemingly unrelated class files nearby.

There are a few applications available (actually integrated into the source code) which track suspected bugs, but I have never used them. A C# programmer friend of mine loves them.

Probably you just need to look for a better debugger for the time being.