This project got off to an interesting start. Both of my groupmates were from Erin’s section, so I knew very little about them. Luckily they’re both programmers and they want me to be narrative designer, which means I can finally flex my writing muscles!
I’ve actually been meeting a lot of new people thanks to this prompt’s emphasis no narrative. Four other classmates serving as first-time narrative designers for other teams have already already seeked me out for advice fulfilling the position, so I feel good about my skillset specialty finally entering the program purview. On the other hand, at this early stage I’m the bottleneck because the programmers are forced to follow my pace. I had to nail down the plot/storyline/puzzles before they could implement them, and I probably cut it too close by only finishing that up Thursday night. That’s mostly why we didn’t have a Unity prototype to showcase for today’s playtest, but I’m glad the paper prototype I designed last night made up for it; the audience seemed to enjoy solving our opening puzzles using the map on the whiteboard and myself GMing their progress. Always nice when my old college job as a professional GM comes back into play.
The paper prototype our initial playtesters played.
It seems like every project I re-learn the same lesson about the importance of considering and incorporating feedback from other group members. When I first designed our game’s narrative, I wanted the crime to be something that wasn’t immediately recognizable as a crime, since I didn’t want the player guessing at suspects while the player character is the only person in the game. The player character was to be trapped in their apartment, which was on fire, and the twist was that he had started the fire to collect the renter’s insurance. My teammates were lukewarm to the premise, and suggested a plot influenced by (honestly, wholecloth stolen from) Memento, where the amnesiac player character followed ominous tattoos on his body hoping to discover who had killed his wife. It was confusing and contrived, and I initially wanted to just pull rank and insist we use my plot. Luckily, I had a talk with Kelsey, an alumni from last year, and she helped me realize that my teammates had valid points to make about the core elements of our plot, even if the exact narrative they suggested was unusable. My teammates were trying to convey that they didn’t find arson a particularly exciting crime, and they desired an edgier plot where the main character had more to hide. These were valid criticisms, and on the production end, incorporating their ideas gave me a chance to increase their investment in the project. In the past I’ve found that teammates work harder and feel happier about the final product if they can see the direct influence they’ve had in its creation. With this in mind, I crafted a new narrative that used murder and the themes my groupmates were looking for, but was a workable story we could actually deliver. My teammates are much happier, and it’s honestly a better storyline than the one I’d made before.
Chapter 5 talked about system dynamics, discussing how the scope of the game changes as it gets more complex. Not only do simpler games like Tic-Tac-Toe have fewer elements than larger games like Magic the Gathering, but the elements they share between each other (win condition, turns, limited playspace) can be larger in one than the other. This is extremely important to keep in mind as our timeframes and our group numbers increase, and it’s gotten me worried about the scope of our project. My original plan had a single room (the apartment that was on fire), but my teammates thought the narrative was too short and specifically requested at least three rooms. I’m worried they’re making the classic beginner’s mistake of thinking too big and dreaming up project roadmaps that are too large in scope. My usual philosophy is to assume that I’ll need to spend half of my development time on post-process bugfixing and addressing unforeseen setbacks, so I always think small. We only have three weeks total to complete this project, and having multiple rooms adds an entire dimension to the camera, inventory, and movement systems. It exponentially complicates everything we’ll need to implement. But I’ve brought up these concerns already and they insist they can finish three rooms within the timeframe. Since they know the programming side far better than I do, I guess I just have to trust them.
Aabicus Archives 