Caellian

What you're missing is planning. Before you write a single line of code, write down what you're intending to do. MOD DESCRIPTION: Max. 2 sentences that would capture attention of someone who's scrolling through a list of mods. What does the mod do? What differentiates it from other mods? MOD MECHANICS: Max. 3 mechanics that the FIRST version of the mod will add. Describe each in detail and how they interact with each other. If the third doesn't interact with first two mechanics, then it should be a separate mod or added later when you've got a better idea of how it could. MOD SYSTEMS: Describe systems the mechanics are built on. What are their characteristics. This is still MVP, so describe the bare minimum of what's needed to make the mechanics work. You can add to these once you're done with the first iteration. Then you implement ONLY that, nothing else. If you notice "ohh but it would be cool if..." while writing code, write it down and just do the bare minimum you need to get the systems and mechanics you described. When you're done, test and fix bugs. The only allowance you can give yourself to tack on more code is when you notice "ohh but that won't work", none of "would be nice" yet. After that's done you'll have a very mediocre mod and that's fine. You've collected a list of ideas on how it can be improved. You now get to choose which idea would improve the mod the most and implement ONLY that, writing down any extra ideas you get along the way. You rinse and repeat, feel free to use GH Issues or Jira to track the ideas, or just a simple txt file. If any of the ideas are more complicated to implement than what you can hold in your mind at once, then you need to break those down into smaller parts or high-level pseudo code which will give you a sense of how to incrementally implement them.

I don't think it should be a part of the same client. It should be a separate game you have to pay for. It's fine if both use the same core - code is supposed to be re-used and these games have extremely similar foundations. Separating VS out of its engine shouldn't really be that much work, the code is already pretty modular and it could be done relatively quickly. Having a separate game people pay for is a must IMO because that will help guide resource allocation and avoid issues like these, where people who paid for VS feel cheated because the money they gave towards VS went to another project, even though there's 80% overlap. I'm not sure how well Anego is doing financially, but I honestly feel having two separate income streams will help the studio decide where to put more of their efforts. I know literally everyone would like to get two games for the price of one, but 20€ is really not that much for a game like VS and HT are and having to pay for both will ensure the studio ACTUALLY has enough resources to double their development effort, even if they believe only 20% more work is needed for a separate game - those estimates are always off. Most of the differences between HT and VS are actually things that would benefit VS. Namely, HT gameplay shows more fleshed out animation system and a lot of animals with more nuanced interactions. HT requires addition of more procedurally generated content. There's large scale world editing tools that could work in VS well. The differences are mostly VS story content vs. HT story content - which is awkward because that's the part of VS that's most noticeably incomplete.