Thank you, we're very honored to receive such high praise! It makes all the hard work feel worth it!

Going through the YouTube videos will provide a bit of insight, but most of the videos are just explaining mechanics or features (which you obviously already know about from playing the game). There are a few videos that go a bit more in depth about the process, like the ones discussing the character creator, or the very first videos showing off early prototypes etc. The videos might be useful when figuring out the general work process in terms of what we implemented when and why. Other than that, we don't think there's any one spot to go to in terms of learning more about the development. We have mostly relied on our own experiences and skills, learning the rest as we go, so we don't really have any learning resources or similar to point at either.

That being said, we can offer some general advice. We would say it's important to avoid feature creep. Almost all of the features in the game were decided at the start of development. Those that weren't were (most of the time) not very demanding to add. Since the game was already large in the planning stages, making it even bigger through more characters, buildings, mechanics, etc. would have made it impossible for just two people to make. So having a clear vision of what you want to do from the start will save you a lot of headache and lost work down the line.

Speaking of the game being large, it didn't feel that big in the planning stages, but once we started working on it, it felt almost endless. One cause of that sensation was the fact that it was almost impossible to see the progress being made, since there's no way to see an overview of all the events in the game. That sometimes made it feel like we didn't do anything, since it wasn't clearly visible in the game. Of course, we always made progress, but since it was locked behind the Main Event-button or characters' reputation etc, it looked like nothing was being done. So one tip is to have some way - even if it's just for yourself - to see that actual progress is being made if there's a lot of writing involved. Just checking things off on a checklist wasn't particularly motivating for us, but it might work for other people. The best way is of course to have the progress show up in the game during the development, somehow.

The reason we managed to complete the game, in spite of its size, was a combination of knowing our strengths as creative people from the start and work discipline. We made plans for two weeks at a time and completed the tasks we had planned for during those weeks, even if it meant working more than we would have preferred. That was generally very stressful and for quite a while, we didn't have very good work-life-balance. But the reality is that a game of this size takes time, and if we didn't have good work discipline, it wouldn't be anywhere near finished now, especially not with only two developers.

But the most important tip of all is to not make something of this size unless you're absolutely certain that you can handle all of the writing. Make sure that it's a size you can manage based on your skills and experiences. It's easy to assume that a game that has a lot of dialogue is easy to make, since it's "just writing", but it gets very demanding for a game of this size. We were both pretty confident that we could see it through to the end since we know ourselves very well, in terms of prior experiences, but it was still a struggle for quite some time. Writing for a game is also quite different to writing a novel (which our lead developer has a lot of prior experience with (without having published anything, I should add)), but that part was thankfully not a problem for either of us. Still, when writing, we had to keep everything besides the actual written words in mind too - the setting, character expressions, sound effects, gameplay mechanics like reputation and resources, etc. So writing for a game is a bit more similar to writing a play, like Shakespeare's, than writing a novel. At the same time, it might not be like writing a play either, depending on what the game is like, so it's good to get a feel for what the writing is going to look like pretty early on in development. Try to adjust the writing so that it makes it both fast to write and fast to implement.

And also, a big key point to the freedom and choices-matter-aspect of Mistwinter Bay is the fact that it has a very small main story. The main story is what the player makes it in combination with all the main events that shake things up so that not everything goes according to plan and to space character stories out a bit. Since that was the plan from the start, we could make most of the choices pretty impactful from the get-go. So if you're after a lot of freedom, it might be a good idea to consider keeping the main story pretty small. Main stories do tend to be pretty linear, after all, and that's not always easy to combine with having choices matter.

That's about what we can think about in terms of general advice for now! We hope we've provided at least some insight and that you can make the game you want to make, one day (hopefully without as much stress as we had at times). Best of luck!

Thank you so much for this really thoughtful reply! It really put a lot of things into perspective, especially in terms of the general flow of creating a game like Mistwinter Bay. I was aware of just how much writing goes into a game like this (frankly it's staggering), and I feel like getting it written will pose a challenge, but the tougher challenge is getting it organized. I really like the tactic you both used with the general formula for meeting the characters and getting to know them. (an informal meeting at the inn before they're hired, then for the 1 heart event you get to meet them formally at the estate. Then you include the 2 hearts event where you get some more info about their job and get to see them unwind a little at the inn, which moves nicely into getting their real personal info and a unique interaction on the street that reveals their personality and usually sets up the hook for their personal quest. The personal quests themselves are beautifully done and worked well with every single character! I felt like none of them fell especially flat and using some logic applied with a couple well placed hints that can be interpreted from the reading made them all feel very fun and unique! Then of course the adorable 4 heart events where you guys usually get flirty in the park after resolving the climax of their stories. Then the heartfelt 5 star events (a few of which made me teary eyed. Lynx's actually made me cancel my plans for who I was going to marry originally and made me switch to her). I feel like organizing them in this way and making them formulaic was great for the organization, and I would love to use something similar in the future, since I never felt as if it took away from any of the narrative, even though I could see the pattern.

I have a couple more questions in regards to the technical aspects of the game, what programs did you use to not only design the game itself, but where did you write all the dialogue and events to keep them organized? I can imagine myself writing them in a disgustingly large series of documents kept in folders, which are kept in more folders. That feels a little bit like I'd be making it too hard on myself, so I'd love to hear what you both used.

It's great that you enjoyed the formula of the hangouts! As you suspect, it did help quite a lot to have a general theme for each hangout, since it meant we could write even on the days when inspiration wasn't on top (a hangout's theme + a character description worked wonders, even though they're such simple concepts). It was also easy to compare certain hangouts to each other (for example, two characters' second hangout) to get inspiration from what had been done before. At the same time, we were never too strict with sticking to the formula for a specific numbered hangout if a character's story demanded it.

We made the game logically and story-wise with three things: the game engine (Gamemaker Studio 2), Hacknplan (a website for organizing projects. It's specifically designed for making games and we find it especially useful for large projects) and just a regular word processing program. We wrote the dialogue directly as code in the word processing program so that we could get spellcheck, but avoid long and tedious implementation once in the game engine. In the dialogue document, we also wrote comments on character expressions, sound effects, when to change background, when to change reputation/resources and how much, etc (all as actual programming comments, of course). Then we copy-pasted the dialogue from the document into the game engine and added all the mechanics related to each piece of dialogue. We kept track of all the dialogue we had written and still had to write in Hacknplan, along with all other tasks related to the development.

Now, we'd like to add that Gamemaker Studio 2 is a great engine in general, it's easy to learn (it has good documentation, a helpful community and its own programming language that's pretty forgiving) and it is specifically made for 2D games. But it's not meant for games of this size or with such high graphics resolution (most games made in the engine are pixelart, which shows in terms of optimization and things like that). We were also stuck on a version of it that didn't have some nice features, like actually being able to see particle effects in an editor instead of being forced to launch the game to check them out. Or more importantly, a UI-editor (every button, every piece of UI, had to be made manually (most of it through code), which is not great in such a UI-heavy game). We also used a visual novel add-on that was easy to get into and had most of the features you could want (that add-on is a reason why we wrote the dialogue as code from the start), but it didn't always work with us towards the later half of development, as our knowledge and the complexity of the game grew alongside a need for optimization. If we had started over again, we would've taken the time to make our own dialogue system from the start. We had to work around it a lot of the time, which isn't great.

As for organizing all the writing, we were arguably not very good at that. We have 20-or-so documents with all of the dialogue. It's grouped by hangout number, large or small main event, character endings, etc. with all of the events that fall under said category being in the same document. We used links inside of the document to quickly navigate to wherever we wanted from a table of contents, but each document is still pretty large (especially those related to main events or personal quests). The reasons it worked for us without getting confusing is a) that we're pretty used to navigating large documents (we're pretty old school when it comes to writing, mostly just wanting to be able to put words on a paper and get it spellchecked) and b) we implemented things in the game shortly after we had finished writing them. The game project itself was much more organized, with folders in folders and key words naming them. That's really the only way to keep a project of this size organized. As daunting as that may be, it's probably the best approach for writing as well - especially if the exact naming conventions are used both for the text documents and whatever represents the text in the game ("objects", as they're called in Gamemaker). In other words, your documents in folders in folders might very well be the best approach in the long run.

We also did a bit of disposition at the start of whatever we wrote (someone's first hangout, or a main event, for example). It was just a regular table that you can make in every word processing program, where every square represented a piece of the story. By using a table, we could easily mark out where a story would branch through options or sending out characters, as well as plan out mechanics beforehand, such as having a character move out or gain reputation. It was basically a flowchart or dialogue tree meant just for writing the specific event (we didn't really use the table once the writing was finished). Such planning could be made in other programs, but we found this to be the fastest way that was also very close to the document itself. Most of the time, we just put the table right before the code for a specific event in the text document. Later in development, we moved the tables over to a separate document, so that crosschecking it would get easier (which it obviously wasn't when it was in the same document as the dialogue, since it meant having to scroll up to it all the time).

We hope that explains things!

P.S: Just a disclaimer that we have no association with either Gamemaker Studio 2 or Hacknplan through anything other than using their products.