I've been enjoying watching my game's progress. Believe it or not, there were a few sprites that didn't make it in, and I intend to add them in an update to further polish the game. I've only got three ratings, 35 downloads, and no donations, but hey! I'm enjoying the process all the same! Just having something of mine out there is an immense accomplishment, because it proved to me and everyone else that I have what it take to not only write, but release a game. Sure, visual novels are more accessible than other genres, but who cares! I made a frigging video game! Speaking of not caring, you're not here to read me fangasming, you're here to find out how I screwed up in my journey. Some of these mistakes were honest, some of them I didn't see coming, and some were just plain silly. Hopefully, you'll both laugh and learn as you read. Making mistakes is a part of learning, and we should celebrate them just like we celebrate our wins!

Mistake 1 - Not having a definite deadline

So as you read in Post Mortem I, I wrote up a GDD that documented most of what I wanted to be in the game. What it DIDN'T document was when I wanted it released. Now this is fine! Jam projects fluctuate in their progress all of the time. What matters is a getting something out, BUT having a threshold of when I wanted it release would've helped as well. My initial idea was mid December. The deadline for Winter Jam was Jan 3rd, but I wanted to release my project while the jam was going on, not when it ended. Then it got pushed back a week to give my artists more time. No biggie! I wanted them to feel comfortable. Than it got pushed back again. And again… And it nearly didn't get released when it did because I was panicking about stuff being misplaced. Point is, a determined goal would've not only kept us on track, but would've sped up production. I've participated in the Spooktober Jam twice, and that one month deadline kept us on track. It's so easy to take days off when you have copious amounts of time. Not saying my teammates did it, I'm saying I myself did it. Even if the jam you're participating in isn't a competition, or has a set deadline, I highly encourage you to plot out a threshold of release. You can then vet out that threshold with your teammates, and all agree upon a day. I'm not saying pushing it back is unacceptable, but making this threshold will help you stay on task.

Mistake 2 - Not having a target audience

Okay so this is a lie. There was a target audience in mind, ME! Tears of the Mermaid takes place in my world, so I myself loved the game! And that's not the issue. No the issue was that I didn't know how to market it outside of mermaids and dark fantasy. It wasn't a romance, because the focus wasn't on Aurielle getting with Jory. It wasn't an otome, because there wasn't a second option, and you couldn't bone Orpheus. Both endings are tragic, but marketing it as a tragedy might've spoiled the game's endings. Ultimately, I decided to call it a tragic romance story. IndieOtome was nice enough to let me market the game, and the artstyle and mermaid tag caught attention. However, the game would've gotten more a following if I wrote it with a specific audience in mind. This is marketing 101, and a mistake many newer developers make. I've been brainstorming a future project whilst doing exercises to find its target audience. And let me tell you, it jump started my creativity! I'm not restricting myself to pleasing x person on twitter, that person I'm writing for actually gave me more ideas! Since I'm planning a lighthearted project to help people unwind, it's only natural that the main protagonist has characteristics the target audience would vibe with! And one of my regrets about this project is actually not making Orpheus romanceable. I could've easily made him the focus of the Desire ending. That and Otome is one of the most popular types of visual novels. I'm not saying you should sacrifice your creativity to appeal to trends, I'm suggesting you try to expand your passions and find people who would like them just like yourself. It isn't unheard of, and there's an audience for just about everything! Give it a shot in your next project, and see what happens! The Spooktober Jam's focus is on horror, so try appealing to that next time you enter.

Mistake 3 - Testing too late

By testing, I mean making sure the game works. So that meant troubleshooting, adjusting sprite placements, further edits, and so on. I should've hopped on this the moment the editing was finished, but I didn't wanna… Testing is one of the most mind numbing parts about game design for me. Oh no, Jory is at the left when he should be center. Oh no, this script bled through. Oh no…I want to die! This might've been burn out. When I began writing, I didn't take days off outside of thanksgiving. I couldn't, I had to get the script ready for the voice actors. So when I was done, I was done! And for a week, I wrote the lore entries. And I cornered myself when the deadline drew near so much so that I went on what I call a bender the day of release to get it ready. Yes I had a programmer, but I still had to fine tune everything. It was MY vision after all, and he had a lot going on near the end of production. Had I made a working build sooner, I could've recruited testers to help polish it further. I could've sent builds to streamers so that they could promote it. I robbed myself of a valuable learning experience because I didn't prioritize testing like I should've. I mean the lore entries were great, but they were an extra. And a working build might've allowed us to release the game sooner. But that wasn't the worst of it! Our game was supposed to have a trailer! One of my acquaintances offered to make me a short gameplay trailer for free since I assisted them with their last project. And with the build not being playable until the day of release, that went out the window! It might get a trailer later down the line, however it would've been much more ideal if we received one at launch. So next time, after the editing is done, I'm going straight into the testing phase. So many mistakes came from not doing so, and feedback before release can shift your game from good to great!

Mistake 4 - Writing Too Much

Last post mortem, I said that writing sprints were the method I used to pull off a 28k word draft in one week. It was a cool achievement, until I had to edit it. It took me a week to polish it, only for my editor to kindly inform me that they wouldn't hire me if I sent that draft to them. Editing your own work is like shaving your back, but more importantly, 28,000 words is way too much for a jam project. Did you know that this project was intended to be a fairy tale for OnceUponAJam? That went out the window once I broke 20k words… And what I forgot to consider, was that I could always make a definitive version of the game after the jam was over. It'd still be a free game, and it'd have all the bells and whistles I intended with no jam deadlines to dodge. It would've also been reason enough to make a steam page for the project and given people an incentive to play through it again. My editor warned me about being too ambitious, and they were right. Editing is the worst part of writing, so why make it longer? And that burnout I mentioned might've been avoided had I aimed for a smaller scope. And 28k words is roughly 2 hours of playtime. Not everyone will want to give that investment to a jam project. And since my audience for my next project is looking to unwind, I've set a limit to 12k words. That's still a lot, but enough to make the story I want to tell in a month's time. If you're a fanatical writer like myself, be very careful with your ambition. Having an ill defined scope kills so many projects.

Mistake 5 - Miscommunications

This is more or less a spectrum rather than a mistake. Miscommunications happen even when not behind a computer screen. And on top of that, I'm on the autism spectrum, so sometimes I misinterpret information, or don't provide enough direction. It happens. So I want to treat this section like a spectrum, and provide pointers that'll help cut down on miscommunication in your future projects. And if you have anything to add on, please let me know in the comments!

1. Do your directing in the server, not PMs - So when designing Jory, I didn't have a clear idea. My artist needed directions, so I opted to brainstorm with my Voice Actor director since Jory's design might've impacted the person we chose to voice him. Unfortunately, I forgot to relay our decision to the artist, and they had to scrap a design they were working on. So from then on, any discussions about the game were had in the channel, whilst personal or informal chats were kept to PMs. Doing so informed the entire team of our decisions, which influenced decisions they made. Sometimes, my lead programmer would pop in and give his feedback. And both artists played a big role in the creation of the marketing assets. While PMing is a direct way to get a hold of someone, it also hides the discussion from your team and makes you responsible for repeating them to anyone who asks. So from here on, I will only use PMs for personal matters and nothing else.
2. Directing + Multitasking = Kaboom - There were times where my artists would ask for feedback while I was preoccupied. With me trying to nip it in the bud, I'd give them feedback. This led to two problems. Either I didn't give enough direction, or I lost concentration in the task I was doing. This is not only a scheduling mistake, but a prioritization one as well. You'd be better off setting aside time to pursue specific tasks, rather than trying to take on everything at once. So after a few mistakes, I would tell the artist, "I will provide feedback in x hours", and left it there. They understood, no one was misled, and we hit our goal. That's all that matters.
3. Fear - How the hell did fear hurt my directing?! Well remember in the conclusion where I said that leading this project was scary? Well it was, and I had to direct people whose fields I knew nothing of. Namely, my sound composer. I didn't know what made a good OST. I didn't know how to direct a composer either. SO I'd push off directing for whatever reason, and progress got delayed. Eventually, I sat down and gave it my best shot. I posted references of soundtracks I liked, and did my best to describe what I liked about them. The composer happily educated me on stuff I was unsure of, and was patient. And you want to hear something funny? He nailed most of the tracks on his first attempt! So either he's really skilled, or my directing was better than I expected! Probably both! Regardless, you're bound to work with people whose field you know zero about, and you can't be knowledgeable about every nook and cranny of design. I've done freelance writing before, and I've had to educate people who weren't writers. It's completely natural! So don't make the same mistake I did!

Mistake 6 - Interpersonal Conflicts

Like miscommunications, conflicts happen. I like to think I did a good job working with my team, but there was one instance I regret. At one point, a miscommunication happened between me and one of my teammates. The teammate got frustrated with me, to which I then told them to not talk to me in that manner and the convo ended. The next day, I get a resignation from that teammate. So what did I wrong? Well setting the boundary was a good idea, but I did it in the server where everyone could see it. This is something I should've took to the PMs and deleted all trace of. Thankfully, the person resigned because their job was causing them too much stress to continue, not because of the disagreement. We left on good terms, and they were cooperative in making small adjustments to what they made when I asked. But as my programmer told me, its best to keep drama out of the open no matter the reason. And while this mistake didn't hurt anyone's feelings, it could've ended a lot worse. Making a project, even a fun one, is a lot of work. And without payment to feed dopamine, people can get antsy as the deadline draws closer. Please watch your stress, because one bad encounter can lose you a teammate.

Mistake 7 - Releasing the game's page before release

So...when marketing a game on Steam, it's a good idea to get your game's page up as soon as possible. Even if it doesn't look the best, it's still a call to action for your followers. Getting wishlists allows followers to contribute without paying, and Steam updates them once the game is released. It's a good strategy that any game designer should use to build up for release. So why is this listed as a mistake? Because I learned too late that Itch doesn't do wishlists. In fact, releasing my page early denied us a boost to newly released projects, so I actually shot myself in the foot! I don't know why wishlisting isn't a thing on itch, but if any mods happen to be reading this, please add it. It's hard to market a game when people don't have a page to look at. I don't want to pay $100 just to build hype...

Wrapping up, my teammates pointed out several typos and spacing issues in our game. After three rounds of editing, numerous test runs, me being an absolute stickler with my vision, and so on, there were still bugs. Minor bugs that didn't kill the build, but bugs nonetheless. This is why you recruit testers people, but even they might not have found them. Oh well, we're updating the game soon enough! Yes, development is STILL ongoing, and I might have plans for an "upgrade" depending upon our reception.

The next Devlog will cover these, so stay tuned! If you enjoyed the read, please leave a like, a comment, and follow my itch for more updates. Keep on rocking!