Tips for the final stretch of a large game's development?

[Akril15]

So, I've gotten to the stage where I've added most of the major elements to a very large solo game project (300+ rooms, 100+ characters, 270+ views), and I've just about gotten to the point where I'm attempting a proper playthrough from start to finish.

The problem is that the tedium and slowness is really starting to drain me. Even with the debugging elements I've implemented (shift+left click teleports the character anywhere onscreen, I've got a custom GUI the takes the player to any room), after around a month of work, I'm barely played through about 1/8th of the game.

I'd just like to know if anyone has some tips or advice for dealing with this sort of thing. I've been working on this project for some time, and I don't want the alpha testing stage to squeeze out all my enthusiasm before I'm done.

[Kastchey]

Wow. This is indeed an impressive scope, and I can see how attempting to solo test this kind of monster of a game could drain your creative energy.

Is there a reason why you wouldn't want to get help from some dedicated testers at this stage? I know you explicitly asked about solo testing tips so it's more my curiosity than a suggestion.

[cat]

Some things that might help (I have no experience with making large projects myself, but I either use the tricks below for my own short projects or saw them when testing larger projects):

• When you encounter an issue that is not game breaking, don't stop. Just note it down and continue playing. After some time (or when you really hit a game breaking bug) you stop playing and fix all the issues.
• In addition to a textfile with notes and open issues, I like to leave notes in the code, e.g. // TODO: add some animation here. This way I don't have to do it immediately, but also don't forget it. Plus, it is easy to search a project for "TODO" (and very rewarding when there are none left in the end)
• In addition to jumping to rooms, you could build a GUI to jump to certain story points/chapter. You will not only be teleported to a room, but also the inventory and needed global variables are set. Of course, you will still have to test the full playthrough in the end to make sure it all connects, but it can help to test later parts of the game.
• The more is skippable via cutscene/ESC, the quicker you are with your playthrough. If a certain animation/action/sequence annoys you when testing, rest assured that some players will also be annoyed when they see it (maybe they are stuck or play the game a second time). Do them and yourself a favour and make them skippable. You could even make parts of a dialog skippable when a conversation goes on for a few lines.

[Crimson Wizard]

1. Get more people to help you with testing.
2. Define distinct logical chapters in your story, make GUI for jumping to a chapter, as cat suggested above, and make sure it's possible to test individual chapters separately.

If you combine these two, then testers may also test separate chapters in parallel.

[Kastchey]

These are very good tips, cat. I don't really have experience with large games either, but I do use text files with notes even when I work on my small or medium sized ones.

I usually split the notes into categories that make sense to me, let's say "Bugs", "Extra features", "Missing graphics", "Typos" etc. It's super satisfying to cross these out in bulk later, when I decide it's time to go back to the project file! It also makes things feel less chaotic and overwhelming.

I also like to take version notes and list, on a high level, what was changed. It not only helps tracking down the root cause of possible mess-ups, but also gives this nice feeling of progressing through the corrections and updates when you look back at how much you have done in terms of updates and fixes.

[cat]

I usually split the notes into categories that make sense to me, let's say "Bugs", "Extra features", "Missing graphics", "Typos" etc. It's super satisfying to cross these out in bulk later, when I decide it's time to go back to the project file! It also makes things feel less chaotic and overwhelming.

I even like to move stuff from a "Todo" list to a "Done" list. Initially, the todo list is overwhelmingly long, but seeing it get shorter and the done list longer, is so rewarding.

I also like to take version notes and list, on a high level, what was changed. It not only helps tracking down the root cause of possible mess-ups, but also gives this nice feeling of progressing through the corrections and updates when you look back at how much you have done in terms of updates and fixes.

Assuming you are using proper version control (e.g. Git) anyway, you could do this via tags.

[Akril15]

Thanks for the replies, everyone!

To answer the issue of getting more testers for the game, I will definitely seek out some beta testers once the game can be finished. Right now, though, there are a lot of small, but crucial parts of the game that aren't finished yet that I need to fine-tune.

• In addition to a textfile with notes and open issues, I like to leave notes in the code, e.g. // TODO: add some animation here. This way I don't have to do it immediately, but also don't forget it. Plus, it is easy to search a project for "TODO" (and very rewarding when there are none left in the end)

I've actually been doing exactly that, using the exact same word!

• In addition to jumping to rooms, you could build a GUI to jump to certain story points/chapter. You will not only be teleported to a room, but also the inventory and needed global variables are set. Of course, you will still have to test the full playthrough in the end to make sure it all connects, but it can help to test later parts of the game.

1. Get more people to help you with testing.
2. Define distinct logical chapters in your story, make GUI for jumping to a chapter, as cat suggested above, and make sure it's possible to test individual chapters separately.

If you combine these two, then testers may also test separate chapters in parallel.

The game actually is going to be divided into chapters in its finished state, so I guess there's no reason why I shouldn't have shortcuts to the start of each one for testing.

I usually split the notes into categories that make sense to me, let's say "Bugs", "Extra features", "Missing graphics", "Typos" etc. It's super satisfying to cross these out in bulk later, when I decide it's time to go back to the project file! It also makes things feel less chaotic and overwhelming.

I even like to move stuff from a "Todo" list to a "Done" list. Initially, the todo list is overwhelmingly long, but seeing it get shorter and the done list longer, is so rewarding.

I've definitely been there as I've been working on this thing. Unfortunately, that todo list can be like an accordion sometimes as I keep turning up more things that need doing while I'm crossing things off.

(Also, I think I may have posted this thread in the wrong forum. If any mods feel like it belongs in Adventure Related Talk & Chat, feel free to move it.)

[Ponch]

1. Get more people to help you with testing.
2. Define distinct logical chapters in your story, make GUI for jumping to a chapter, as cat suggested above, and make sure it's possible to test individual chapters separately.

If you combine these two, then testers may also test separate chapters in parallel.

This! It's how I manage my games. For us indie developers, we have to work smarter, because we can't work any harder than we already do. Break that game in distinct chunks and test each one on its own before finally testing the whole thing end to end.

[Crimson Wizard]

To answer the issue of getting more testers for the game, I will definitely seek out some beta testers once the game can be finished. Right now, though, there are a lot of small, but crucial parts of the game that aren't finished yet that I need to fine-tune.

Honestly, with the game as big as yours, it may make sense to get "alpha" testers too. Not only that will speed things up, but they may give you a first impression of your game, and maybe notice logical mistakes in story and design that you missed.

[Kastchey]

CW has a point there. In the final stage of the game, it may be much more difficult to change or fix things that you had missed when solo alpha testing, if there are code or story parts already built upon them, with lots of dependencies.

[Rik_Vargard]

I didn't see it here (I think) but what you can also do is change the player's starting room so you don't have to restart after changing stuff that makes you restart like new animations, gui stuff and so on. Just don't forget to add the inventory and change variables etc. as it should be at that point in the game, in function room_FirstLoad(). So you can really focus rapidly on that particular moment. And I did find this more reliable than using a teleport gui. But that's just me. 

[Danvzare]

Holy crap, that's impressive! 
And here I thought MY game was big. Just how long have you been developing this game?



Ok, moving on from that. Here's the things that I've been doing in developing my game (which is pretty much what I do for all of my games).

I've had a bunch of different starting points selectable from the main menu. Basically start from Act 2 and start from Act 3. Which set up the necessary variables. If all of the parts work individually, then presumably they'll work together. (I've also tied their visibility to the debug mode, so I don't even have to remove them when I'm finished with the game.)

Another thing I've been doing is quickly going through the part of the game I've just made (basically speedrunning it) to make sure it's completable. Then playing through it slowly, trying to interact with everything while taking notes. Fixing those problems I encountered. And Then getting a family member to play through it while I watch and take notes (it's nice to have a laptop handy, since it's quicker and easier to type, but you might prefer pen and paper).

Next up I'm planning on doing that exact thing, but to the entire game from start to finish, rather than each individual part. So that's a quick run through, a slow playthrough, then alpha testing. Making notes, and then fixing those problems between each playthrough.

After that I plan to get a friend to playthrough the entire game without my oversight, with them giving me any feedback that they might have at the end. I have to ensure the game is as bugfree as possible for this beta testing phase, to ensure they can complete it. (If they meet a game breaking bug or simply get stuck, it might put them off, and they might never finish it.)



But that's just my process. Naturally it's different strokes for different people. That being said, looking through the other responses, it looks like I'm not alone in this approach to development.

That being said, the bug fixing phase really is the part that kills my enthusiasm. I just detest testing!
Thankfully my brother loves testing. And having that source of feedback, critique, helpfulness, as well as someone that is always excited to see what you're making, is by far the most useful thing you can have when developing a game. 
I'm quite lucky in that regard. 

[Akril15]

I didn't see it here (I think) but what you can also do is change the player's starting room so you don't have to restart after changing stuff that makes you restart like new animations, gui stuff and so on. Just don't forget to add the inventory and change variables etc. as it should be at that point in the game, in function room_FirstLoad(). So you can really focus rapidly on that particular moment. And I did find this more reliable than using a teleport gui. But that's just me. 

I've been moving the character from room to room and changing/adding various elements of the game in game_start for a bit. It does make things a bit easier (as well as keep track of what has to be changed from chapter to chapter).

Holy crap, that's impressive! 
And here I thought MY game was big. Just how long have you been developing this game?

I've been working on it for several years, but I've been planning it for some years prior to that point.

Thanks again for the input, everyone. I've never really asked how people handle the testing stage of their games, so this has all been pretty enlightening.

[Rik_Vargard]

Holy crap, that's impressive! 
And here I thought MY game was big. Just how long have you been developing this game?

Thanks a lot, it's quite a short little big game that took me a little under two years to develop. 

Back on topic: You do good to ask external people. As a good noob, I didn't. I tested my game so much in all possible ways and fixed dozens and dozens of bugs until everything felt right. I even tested doing things I myself would never do.
So I released my game and, oh boy, did that release became totally messy. For weeks. It was hell.
I learned that however you test it, people will have their own brains and logics. And they will break your game.
But thanks to them and their reports it's now all over.
Lesson learned