Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(5 edits) (+2)

Love on the Peacock Express: A Fairly Smooth Ride

Producer Postmortem

Hey friends! My name is J, and I'm the producer on Peacock Express. This is one of the first projects I've worked on as a producer, and I wanted to compile a list of strategies that I think worked as well as ways that I would improve a team's process in the future. I think the majority of things that went right in this project could be attributed to the entire team's hard work and effort, as well as smart scope. Although we maybe have been a little more comfortable with one more week for deadline, the game's development was fairly smooth with generally few complications

What went right

Before I go into what went well, it's good to remember that when something goes right you generally take it for granted. (I took a lot of things for granted on this project.)

On the team

Experienced leads who knew multiple areas

Working with leads who are professionals in their respective areas is awesome. Working with leads who are professionals in their areas but also understand other leads' areas is incredibly awesome. All of the leads had some spread experience with visual novels and often made sure to keep other aspects of development in mind. For example, Queenie (art director) had an understanding of how to make imagemaps for renpy. In another instance, Ivory (lead writer) explained that in an inconsistency between art and writing, revising writing was easier than revising art.

Discord had useful surprises

Using a discord server for a team project was an easy decision, but I actually learned some new things on this project. For example, you can set up Github webhooks--when anyone pushes to the repo it spits out a discord message in the #programming channel, giving me helpful notifs when I'm working at the same time as our other programmer. When I was setting up roles for artists, writers, and programmers, I thought I'd try something new and include roles for pronouns. As people joined the server, they were given all of their roles such as artist, writer, programmer, etc. as well as an "add pronouns" role. This role sat above pronoun tags like "she/her" and "they/them". Team members could choose to add as many pronouns as they liked. This was a pretty unobtrusive and accessible way to communicate pronouns to teammates.

On the process

Trello is good......... actually

If you're already familiar with why Trello Is Usually Good, Actually, skip this paragraph. We tracked the current status of art (sprites, backgrounds) and development (particles, bugs, scripts) using trello boards with the kanban method. Kanban's core workflow involves separating tasks into lists of "To do", "Doing", and "Done", but you can customize it for your art pipeline. This helped the team (art director + me especially) to see the current progress of every asset. How many more sprites needed to be assigned to artists? Do we have enough artists free for CGs? Which interactive screens still need to be put into the game? Unlike gdrive or 20 email threads or a groupchat or GOD FORBID 20 dms, trello gave us immediate insight into the project's overall status.

We also had artists attaching final assets to cards instead of uploading to drive which saved going between sites trying to be sure that the two aligned. I think this also needs an additional disclaimer: On a larger project it would be worth teaching your artists how to put their assets into the project with source control. For something fairly small with a manageable number of assets (which usually weren't too large in filesize), this worked fine.

Also despite what artists tell you....... they CAN learn trello (ok they may hate it for a month but it's fine).

We prioritized what the game needed to ship

Even though we managed to finish all of our planned features for release, we made sure that our highest priority assets— backgrounds, character sprites, and script made it into game builds first.

On the game

The game was really well scoped

I have never typed that sentence before in my life. We estimated the game's length and amount of assets in the design stage and created a timeline to ensure high priority tasks were completed in the first month. In addition, we created core game systems in preproduction (although these would be later streamlined to fit the length of the game).

Dream Daddy created a market (that already existed tbh)

While I didn't play Dream Daddy, I was definitely among the people thinking, dang, how about a mom version though? Our game is not exactly a mirror of Dream Daddy, but we hoped to create a game with content that appealed to wlw and queer people in a similar vein. The game's concept, close enough to "mom version of Dream Daddy", helped it spread through social media and by word of mouth. I think our timing gave us enough space to let Dream Daddy breathe but was still fresh in people's interests. (Though I also believe that there's still an opportunity for a Mom Dating Sim....... Yuri Game Jam 2018 maybe???)

We had a deadline

One of the top killers for small + independent game projects is no hard deadlines. I saw an opportunity in Yuri Game Jam to take advantage of a hard deadline to prevent this project from dragging out into an eternal dev limbo. Even if the game needed tweaks or polish when it was submitted, we would at least have some kind of alpha product.

Visual novels are (generally) low risk

Like most other dating sims submitted to this jam, LotPE was made in Ren'py which streamlined development. Not having to worry about bugs in a bunch of complex custom systems made shipping the game a lot less risky than other types of games.

What could have been better

On the team

Ask people how to best reach them

Our communication channels were actually mostly done right... except when people missed emails. Or didn't sign up for discord. I don't know what the best communication method is or should be, but I think going forward it would be a good idea to ask people what channel they can be can reached fastest.

On the process

Gdrive doc organization sux (OR: Make documents and resources as accessible as possible)

Despite Literally Every Project I've been on using gdrive... I actually hate using it. You're probably thinking--what the hell is there to even hate about drive? It's google. It's the most inoffensive file management site ever. You just make folders and put your docs in those folders.

And yet... literally any time wants the design doc we go digging through chat history for links. We make a directory for design docs with the best of intentions. And then someone makes a doc that isn't in the folder. And then someone makes another directory for the next stage. And then somehow we lose to each of these. When I go to drive I have to switch accounts, dig through a tree of 20 subfolders (that take like 5 seconds to load each), and it's enough that I just don't do it (ever).

Trello file limits also suck

Here's the obvious solution that we did end up using: gdrive links........... attached to trello cards. The accessibility of trello with the file limits of gdrive.

Leave time for testing

I don't think I've been on an independent project that had adequate testing, but it's worth bringing up again with emphasis. We released the first build with a fatal crash in the save/load system that we didn't catch because particles were finished the few days before the deadline.

Lock systems in preproduction if possible

This is a part two of the above note, but it's worth reiterating that it's important to implement and test features/systems in  your game as soon as possible. This leaves time to tweak and fix bugs.