Thank you for sharing this, @sophia . I have to agree that the process of submitting my first game was a similarly positive experience. While I was ultimately unhappy with my results, twice, I did learn some really important lessons in the process:
1.) MVP - I knew about this beforehand, but I didn’t apply it for some reason. It stands for Minimum Viable Product. The concept being this would be the simplest most scaled back version of what you could charitably consider a finished game. I was aiming for a larger, more enriched experience from the start and built for such. As a result, while I had far more done and far more time into my project, I needed much more time to finish what I had already partially implemented than the time remaining at T-minus 3 days from the deadline. Also, since I started with that larger framework, I couldn’t easily prune the project back without breaking it (Trust me, I tried). So, I took a smaller element that I had added some time after I started (making it easier to disentangle from my tormented mess of a code) and separated it into its own project, reframing a setting and thread-bare plot on the fly. So, I abandoned the bloated carcass of my game 3 days before the deadline and essentially did an unintential speedIF run for a non-Speed comp. The results, while accomplishing that MVP goal (just barely), are not really up to my standards. On the other hand, had I paired my original game down to a MVP before I started, I would have finished that working game ahead of time. I could have then added to that framework with whatever time I had left. If I ran out of time before finishing a section, I could safely ditch it and still have a functioning game. A painful lesson, but one I won’t forget.
2.) Communicate expectations to your Beta-Testers. I had two people I knew from college play through the game and get back to me. One, tragically, treated the thing as some sort of game review (my fault for not articulating what I needed) and gave me generalizations about how he felt about it (sorta helpful), what he would have done with characters/plot himself (not helpful with the time left), and then mentioned encountering numerous spelling/grammatical errors and continuity errors while playing while not specifically naming a single one (Not remotely helpful. When pressed, he could no longer remember where he had seen each error. He hadn’t noted where these errors occurred while playing; he hadn’t been prompted to.). Sending a game file to someone asking them to play it and please give you some feedback isn’t adequate. Entirely my fault. The other individual did a better job, making note of needed changes, but got stuck partway through because I didn’t supply a walkthrough. Thoroughly communicate your needs to your betatesters and supply them with the tools and resources (map, walkthrough, etc) to do the job right. Also, leave enough time to implement any changes the beta-testers suggested. There were some great ideas for improvement that I sadly could not capitalize on.
3.) Identify any new functions or implementations early in your project. Create small test modules to wrap your head around working code for each new situation before committing to your MVP. You may realize that implementing that *.GIF file or tying the current system time into your project may be much more involved than originally expected. You don’t want this realization to occur very late in the project.
Thanks again,
-Pinkunz