Previously, I liked huge, complex stories. I loved constantly adding new plots, embracing ‘maximalism’. But the consequence was that I often ‘designed games’ without ever actually developing many. I often told my friends I was ‘making a game,’ but had no results to show for it. This time, I finally created a ‘game of my own,’ which gave me a huge sense of accomplishment. The moment I uploaded it to itch.io and shared it with friends, I felt all the recent all-nighters were worth it.
The pace of this class is really fast. Going from a raw prototype to a refined prototype showed me the truth: make it quickly, test it quickly, and iterate quickly. This model of sprint development and agile development didn’t increase my absolute productivity, but it taught me to distinguish what’s most important and to invest my limited productivity in those key areas. It was exhausting, but I loved it.
Reflecting on the entire process, I think this development had a problem of being ‘too tense at the beginning and end, and too relaxed in the middle.’ From 10/13 to 10/18, my energy was focused on story writing, especially the 48 hours from 10/13 to 10/15. I needed to release a ‘playable’ prototype in such a short time, and it had to be complete (because my game contains a trick, it’s difficult to divide into chapters). I remember late at night on 10/14, I was staring at my computer in despair. There was just too much to do, and I wanted to give up. But in the end, I persisted and made a lot of cuts, simplifying it as much as possible, and used the outline directly without any text polishing. I originally thought this would be too rough, but in reality, the game mechanic (fragmented narrative) gave these fragments a kind of magic. Players still experienced a story very similar to what I had intended. This taught me: trust the players, trust the game mechanics. If I have an idea, I should create its most crucial part as quickly as possible, and then continuously improve it through testing.
Another tense period was 10/24-10/29. Before this, I thought I had already completed the ‘detailed outline’ and ‘system framework,’ and that my progress was perhaps 60% done. But that wasn’t the case. Turning an outline into a full script, and turning a framework into an actual game experience, involves so much more work. This period drove me completely crazy; I put in at least 50 hours. I believe that ‘turning the framework into the game’ (both story and code) is the main body of game development, accounting for about 70% of the work. Because this stage is full of unpredictability. When developing features like special effects or music, I only needed to write technical documents and do basic tests. But when they were actually implemented in the game, many unforeseeable bugs appeared. In my future development processes, I will reserve more time for this stage.
Regarding game testing, I think the video from class made a lot of sense: a creator’s biggest challenge is that their ‘taste’ is already there, but they can’t create work that satisfies them. For me, during development, I could see many details I was unhappy with, and I fixed them one by one. Before I was satisfied, I was reluctant to give an ‘unfinished product’ to others for testing. Therefore, the testing period this time was tight (even though the sample size was sufficient). During the testing process, I found the problems were relatively focused (like the ‘Type A B’ guidance issue). After a few rounds of fixes, the collected suggestions for changes gradually ‘converged’. But if I develop a game again, I hope to balance ‘developer’s perfectionism’ with ‘active testing,’ and reserve as much time as possible for testing to get richer feedback and more opportunities for iteration.
