dev diary #7

Not sure what to say about this project. I kinda suspected, from the moment the team insisted we make multiple rooms, we were gonna run out of time and the project would disappoint. But I’d thought that about the last project and Tyler blew me out of the water by creating a great game. I think the main difference is that Tyler and I had a much simpler scope and I created all the assets in-house, leading to a very quick initial prototype that had unity in its sprite artwork. Tyler and I were done with the core game within the first 48 hours, and the rest was playtesting, bugfixing, and adding additional features. This is a stark contrast to this 3-person project, where the core game is barely being finished on time and we’re likely going to have no playtesting whatsoever. I’ve played the game and it’s pretty unremarkable. I can tell programming put a lot of work into it, but almost every element is unpolished and the final project feels like a crude alpha. This will likely be the first project I won’t be adding to my itch.io account.

It’s tough, because I feel like I pulled my weight. I had the script finished with two weeks to go, and all the inventory icons finished with a week left. I should have had the voicelines recorded sooner, but I couldn’t record them until programming finished creating the map, coding the puzzles and sent me a list of minor changes (like changing the plastic shed to wood or removing the shower since they couldn’t find a free asset). Ultimately, I think our workpace was insufficient for the amount of time we had to create the project. We should have stuck to a single room. We could have finished it well within the timeframe, and started playtesting/debugging after that. Maybe I should have played more of a “project manager” role and just flatout told people what to do and how we’re going to do it. I really wanted to just work comfortably on content creation and trust that the programmers would handle their sphere, but I have this suspicion that my decision in some part led to the game’s failure.

Chapter 7 was all about prototyping, one of my favorite elements of game design but not one particularly relevant to this dev diary since we’re putting the finishing touches on our game. The lectures were more pertinent, especially Monday’s which discussed linearity vs engagement. Game developers have to juggle a delicate balance between utilizing “what works” and also creating a unique signature for their game to stand out. I would say this is another element where our game falls short. The Unity store assets plainly telegraph their origin, and the gameplay is pedantic by design; I’d hoped that the writing quality, voiceover narration, and storyline would carry the plot instead of the puzzles/gameplay. But in practise the gameplay is so unpolished, and the assets so minimalist that the game seems to entirely disagree with the narration in most parts. When the player character obtains a brick and says, “One of the bricks was loose in Wernicke’s wall” while he is quite clearly standing in front of a wooden picket fence, it’s impossible to take the story seriously.

Speaking of other projects, I had a blast voice-acting for Aylin’s and Will’s games. I’ve always wanted to bolster my voice-acting portfolio, so it’s great to have three new titles under my belt within three weeks, and I think most of the class knows by this point that I’m very interested in voice-acting for future projects. Also, C++ is going better than ever now that there are dedicated student tutors who are available most days of the week. I’ve finally completed Poker and plan to begin Breakout next week. It’s nice to be on schedule again.

inventory sketched.jpg

Pictured: inventory icons. Pretty pleased how these turned out considering I made them using a bunch of royalty-free stock art and an online filter. I was going for the ‘hand-drawn’ feel, because the premise is that the character is sketching in his journal, but I also needed them to look photorealistic due to the game’s artstyle.
Also, since all I ever seen to include are screenshots, thought I’d throw in one of the 69 voicelines I recorded for the game’s narration. This is heard on an in-game answering machine, revealing who came to Wernicke’s house and murdered him last night.

dev diary #6

Prompt: Write about the week’s lecture and readings as they relate to your project 
– Write about this week’s industry guest speakers (if any)
-Write a description of your progress (both positive and negative) on your current project
– Must include at least one piece of media:
GIF, link to video, screenshot, sketch, etc.

This week’s reading was on the genesis of new ideas and the conceptualization of those ideas into a playable prototype. I confess we don’t have a lot of that, we’re making a pretty bog-standard point-and-click adventure game using inventory and password puzzles. Last dev diary I talked for a bit about how our game’s concept changed direction due to what the other teammates wanted to see in it; this week, that concept mostly just shrank to accommodate the looming deadline and projections on what we can realistically complete assuming everyone works at their current pace. I’ve had to remove a few different puzzle styles (physics puzzles and item-combination puzzles specifically) because I couldn’t realistically see us incorporating those mechanics by the end of next week. I’ve also spent a lot more time on the writing to make up for that, since it’s now the primary thing carrying the gameplay. To that end, the “Business/Cost Restrictions” column on page 182 was certainly the most relevant game design element to our work this week.

I’m kinda nervous about this project’s prospects. We’ve basically set things up so that I’m in charge of narrative and they’re in charge of programming. I’ve written/edited the entire script, descriptions for the inventory items, and sketched out the rough layout of the map. Now I’m locating sprites for the inventory items, and later I’m going to record all the lines for the main character’s voiceover during gameplay. I’m worried for two reasons (1) both of my groupmates seem to be okay with how much I’m dictating how this story is going to pan out, but this had made it almost impossible for me to incorporate their ideas into the storyline. In the past, I’ve always used other teammates’ ideas as an easy way to get them invested in the project, but even with prodding, Neither Nathan nor Eric seem to want to suggest anything, and are completely fine with whatever I come up with. But that leads to (2), I’m worried we aren’t completing the prototype fast enough. We’ve barely got a house rendered, zero completed puzzles, any only a few token item descriptions inserted into certain items. I can only hope that the project only looks barely started due to my lack of programming perspective, and they’ve actually completed all the hard back-end stuff so the remaining front-end elements will take less than a week. Neither of them seem worried and they assure me that we’re within expected timeframes, so I guess I’ll just keep doing my job and ensuring they have everything they need to do theirs. But I can’t but wonder if I’ve failed to setup enough investment on their part, and that’s leading to them working slower than they might if they saw their ideas more plainly visible in the story. I’m also worried that our pace isn’t leaving any room for playtesting. I have an unfortunate suspicion that we’re not going to have any time for anyone to play the ‘finished’ game until the day of the deadline. But since I’m not programming, and I’m ahead of schedule on my end, I’m not sure what I can do about that.

As the school year ticks along, I’m also spending more time thinking about the upcoming Greenlight pitch. Everybody I’ve talked to in the class already know what they’re going to pitch and are now in the development phase, but none of my ideas seem baked enough to really pitch. Part of it is my history of solo development and my inclination to avoid using anyone else’s assets. I always think small; I make sure the scope is limited enough that a single person can write, illustrate, animate, program, and debug the entire game from conception to completion. It’s surprisingly difficult to drop those filters and broaden my scope up to a team of 5-7 developers (with a third party art team) working for an entire quarter. I have project ideas that I’ve never made because they’re too large for one person, and I logically should be pitching one of those, but they’re all online multi-player and I was cautioned to avoid that genre. As per Erin’s suggestion, I’m going to sketch out a few of those online multiplayer ideas, figure out what design elements I like the most, and see if I can create a single-player idea that uses some of them.

26b4d38ac484802aedc2809184e7ba8b.png

Layout mockups of the map and its puzzles. Every single tag has a narrated description the player will hear in game when they click on it.

New Game! Zone Out

Zone Out isn’t the sort of game I normally make, but it’s also my first duo project!

83132e7bd2b1036cf0eded5250c326bb

We were assigned an emotion, and our task was to create a game that conveyed that emotion. Can you guess what our emotion was?

Programming and sound design by pat. Sprites and level design by aabicus. Special thanks to MJ, Erin, and our playtesters at UCSC Silicon Valley!

dev diary #5

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.

outdoor blocknig.png

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.