Insight into mod development

So it’s been a little bit since my last post, and as I near the end of the last stretch of development of the Legacy arc of this project I find myself reflecting back over how far it’s come and how far I have come and I wanted to share a few points of insight I’ve learned along the way.

#1- Start small. A project of Legacy’s scope is far too big to start right off the bat and run with it, but I learned this the hard way. In doing so the pitfalls I faced were the “ever changing a growing” dilemma; which is to say that the project was always seen as “not finished” or a WIP, which is ultimately has been. There have been major milestones where the mod has been very stable for what it is and could be played through in all major capacities from start to end with little or no problems, but there was always more that was not yet done, not fully included or was just simply planned for the future.

#2- Have a vision for the “big picture” Even if you do not know ultimately what all your mod will entail, you should have a clear idea of what you want it to do and how you want to get there. Ultimately with a large project like Legacy you will end up with a lot more ideas as you go and gain a lot more skills while implementing things which will in turn give you more ideas. There are two methods of learning and modding: 1- Learn what tools you have and then put them to use creating something or 2- create an idea and learn how to implement it. Ultimately #2 is largely how I grew and developed the mod, and it can be more painful, especially since you will eventually find much more effective ways of doing things later down the road and will have to redo a lot of your work, so I would advocate for doing your research first and then putting it to work in your design, it will be much less headache.

#3- Don’t be afraid to cut out good ideas. Only include those ideas which will support the core principle of your mod, and cut down on the fluff so you can use that time to polish those core concepts that really matter to your mod. Also don’t be afraid to cut an idea that IS supportive to the core concept if the idea is holding you back, technically not feasible or is otherwise preventing you from completing the big picture. I’ve gotten lucky in that I have been able to include almost every idea I have set out to implement, but I still have had to make the hard call on some ideas and say “this doesn’t work or doesn’t fit here” and went ahead and cut it.

#4- Avoid rebranding. A large project may very well grow out of a smaller one, or will evolve to become something else entirely, but it’s always best if you can clearly define your project and stick with it. Legacy started as “Dragonborn Gallery” and was listed in the player house mod category briefly before moving to the collectables and treasure hunt category when it was relabeled as Legacy of the Dragonborn and then finally moved to quests and adventures instead. Another perfect example is Moonpath’s to Elswyre which started out as “Anvil Jungle Estate”. Nailing down a solid idea will save some confusion

#5 – Find a naming convention right away and stick to it. Having a Prefix on every form in your mod like DBM_ in Legacy is critical, but more importantly, find a sub-convention that works as well to help you categorize everything clearly. It will help you navigate much more easily. For instance in Legacy I had many vanilla resources which had special textures or shaders applied to them and instead of making them a DBM_ prefixed item, I used the Vanilla convention and added DBM at the end. Same with replicas so that I could see them all within the sorted context of their parent items. Do the same thing with scripts.

#6- Use vanilla scripts for very basic functions only. If it is critical that something function a certain way, make your own script, because there is no guarantee that the USKP or some other mod won’t alter the vanilla script, unless of course you design with those script changes already in mind.

#7- Document EVERYTHING. “You can lead a horse to water but you can’t force them to read the sticky post” is a quote I should have on my signature line. Ultimately people will still ask questions you have answered a million times before, but it’s easier ti just say “read the article” or “see the sticky on the comment thread” then to explain it all again, especially when a project gets huge. Take a breath, step back, and if needed, just ignore those questions you get a thousand times a day, and if you are documented well, someone else will jump on it and point it out for you

#8- Accept help. When a project gets so large that you cannot and in fact do not want to do everything yourself any longer, welcome the support of those willing to make patches, do trouble shooting, proofread, etc. But always keep a finger on the pulse of what is happening and chime in briefly when needed.

That’s it for now, gotta go pick up the little ones, I’ll post a second article at another time that continues this theme

Leave a comment