Subnautica has given me memories I shall never forget + Wiki-related advice pls?

Merivo · April 2018

First I'd like to say, Subnautica has been an awesome experience, and I'm so glad (and feel kind of privileged) to have seen the game develop over the last 3 years.
Here's one of my favourite screenshots I took while playing the game:

Secondly, I've been building my own game with a small indie team (I'm not going to plug, but it's my first serious project), and we've taken-to some of the development tools you guys are using. We are using trello to manage our tasks, and fandom as our wiki site. I now have an enormous respect for whoever keeps the subnautica wiki up-to-date, and regarding that I'd really like to ask some advice. I'm having a hard time keeping my own wiki up-to-date, and making sure there are no pages missing and that all the information is current. Whenever I decide to change the layout, I think I grow a few grey hairs hehe. How much of that work has been community-driven for subnautica? When stable releases came along, was the wiki updated all at once, or was it updated alongside the dev build? Did you have someone dedicated to managing it, or was it the responsibility of the whole team? If so, how was it kept consistent? These are the points I'm struggling with most.

I'm up for hearing wiki-related advice/info from anyone by the way, (I'm not really expecting the devs to reply to this, but on the off chance..). I mean any advice is good, but I would like to know how it was managed for Subnautica, since things like crafting went through so many revisions.

P.S. I've not had my fill of Subnautica yet, in-case anyone was wondering. This kinda reads like a goodbye note, but it's not :P

scifiwriterguy · April 2018

For your wiki, establish templates, make them such that they can be expanded if needed (modularity is key in any programming project at any level), and stick to those templates. It keeps things from getting unnecessarily messy as fans decide to add things on. Give them a framework to work from and they generally follow it. Don't give them guidance and, well, they'll each do their own thing.

Chart out what you plan to do. Not (just) in terms of production milestones, but rather don't make a very common game development mistake: building the game and then trying to cram a story into it. Figure out the narrative, the story you want to tell and the experience you want the gamers to have as you tell it. Trying to go the other way, making the story fit into what you've already created, can be like trying to kill a bear with a chopstick - you can do it, but it's going to be super hard. (Bonus point to anybody who got that reference.) Your writer(s) should be working right alongside you every step of the way. The net result is, as far as your wiki goes, a lot less chaos. When you keep whipsawing the plot around, that's when edits tend to get crazy. People try to make sense of what you're doing this week versus last, and then it all kinda goes sideways. If you know what you're doing and what the plan is, people will follow your lead; look like you're lost and someone will fill that gap.

Find some fans that seem motivated, write well, and have a high degree of maturity, then delegate the policing of the wiki to them. Monitor their work, but a wiki is a collaborative process, and so too is its maintenance. You have ultimate responsibility, but don't be afraid to delegate on the wiki. That saves you the daily grind of digging through changelogs. Keep an eye on them, but you won't have to obsess over them.

Don't be afraid to revise. Your game is a work in progress and is subject to change. If you're using a crafting system, you can use your designated delegated wiki minders to push updates like those: send them the changes as a list and it'll be the work of a few minutes to make most updates, so long as the necessary parts exist. Leave it to the broad community and the results will vary. Same goes for any other broad-level revisions, changes, additions, and removals. If you really do trust the people you have moderating your wiki, let them handle it. Very few people who accept a moderator position on a forum or wiki will really complain if a little extra lifting goes along with their shiny sheriff badge.

Now, insofar as your game dev goes, I'm going to give you a few basic pointers. Some are just good programming hygiene and practice, others are a little more art than science. Take or leave as you see fit.
1. Always keep old revisions. Of everything. It's a lot easier to go back to something that was working better if you still have its code tucked away in an archive. It's a similar rule as in modding: save a copy of your files, then make your changes. If you horse it up, you can restore from previous in a heartbeat rather than trying to find all the changes you made.
2. Yes, they're annoying, but code comments will save you a bucket of time, especially if you have more than one programmer.
3. Worry about cute and efficient later; get your code working first, then put on its makeup.
4. Detached backups. Cannot emphasize this enough. Make regular backups to storage devices that will be detached from your system as soon as you're done. Anything can happen to your system, so cover your assets. Detached backups are the safest option. Uneditable detached backups are best - burn files to a DVD and finalize it, and they'll stay there forever.
5. Get your writers to work early and for the love of St. Swithin listen to them. You have a vision for your game. The writer can make it believable. You're on the same side. Now, if you're lucky, you're handling the bulk of your writing duties and that will limit the number of arguments about it, but sooner or later you'll probably need a fill writer - writing flavor text that's good takes time. Cracked did a great article about this when it discussed game production sins to avoid.

Most importantly, though...dream. Go nuts. Do something stupid, crazy, insane, but follow whatever your passion is for your game. You know what's inside your head, so go for it. People will like it or they won't, but that's true of every game, format, formula, and genre. If you have a passion for the game you're making, the community will notice it and fall into it, too. Love the work you're doing and it'll reward you.

Good luck to you.

Merivo · April 2018

@scifiwriterguy

Thanks for all the advice!

I have a couple more questions regarding the wiki. Our game is 2.5D (2D made to look 3D), which makes me reluctant to put our art assets directly on the wiki in-case they get nicked. Do you think we should only provide shots of them in-game, so that there's a background and they're harder to steal, or watermark them or just not worry about that? Secondly, we intend to release our game in chapters, which reveal more story & content, but also new mechanics. Do you think those managing the wiki should be clued into what's coming in the next chapter? Perhaps just the game objects / new mechanics?

Regarding the game-dev advice: The story has been developing along-side the game (and the overarching plot is complete) so I think we're fine with regards to that. We are actually only a team of 4 (with a few extra helpful hands along the way), so we are pretty tight-knit as far as the development goes. I totally agree with your points and I always stress the freedom and peace of mind gained from detached backups. The only point I'd say I've been weak on is 2: commenting code, however I am very strict about architecture and naming conventions so that might be my saving grace.

Thanks again for all the advice. I generally live by the phrase 'work smart not hard', and you've given me some pointers for how to work smart, so thanks.

scifiwriterguy · April 2018

Whether an asset is in-game or on its own doesn't make a huge difference in terms of security; it's the work of a couple minutes to snip out any background that might be near whatever asset and put it effectively on its own again. If you release screenshots that have assets shown, you can protect yourself a little better (assets in situ show clear use, and if the shot is dated it establishes precedence). But really, if someone wants to plagiarize, they're going to, and there isn't a lot that can stop that. Subnautica was plagiarized by no fewer than two knock-off versions before its official release, and Flappy Bird has been recopied and cloned so many times it's suffering from Xerox poisoning. Watermarking is a good middle ground. Realistically, though, that's a question best directed to an IP lawyer.

You don't need to let out plot details early; that's how leaks happen. But for the wiki update side of things, just cluing them into new mechanics and objects should be enough. They should also be able to develop the page updates offline, then drop them into place when the new chapter drops. Coordination should help prevent confusion, particularly when you're changing mechanics or are releasing an object that you know everyone's going to be hot to get/use/have. But as long as whatever it is is already noted in your public Trello cards and dev diaries, there isn't much need for great secrecy. I'd just keep the plot elements under wraps. To that end, updates to plot pages on your wiki should be able to be handled by your writer. Once the detailed plot has been written, a synopsis is easy to grind out.

Naming conventions for variables, objects, and function calls save you lots of headaches. If you're planning to be modder-friendly, it'll also save you lots of grief on the backend. Comments are still useful, though, when you have complex interactions going on or unusual calls in the code - particularly if you're not finishing all of the changes in one sitting. Writing down the plan and frame of mind to start helps you execute that plan successfully rather than some mutant version fueled by too much caffeine and not enough sleep.