Data definitely belong in the repository, not only because you want to version your assets too, but also because chances are your code at time T is also meant to work with your data at the same time T - so you don't even attempt to do stuff like trying to figure out when some bug was introduced with current data (that could cause or hide the bug or your older code not even working with the current data).
You could try to put your data in some other repository, but since you are versioning that data anyway, that introduces additional pointless complexity and besides the code is useless without the data to work with - so just stick them together and be done with it. If your VCS cannot handle that, instead of having it dictate your workflow towards an inferior solution, change your VCS.
At least as far as games are concerned, data and code are interwoven and any other approach is guaranteed to either fail or produce unnecessary and easily avoidable complications.
I certainly wouldn't fault them for putting the story under source control/versioning or even the location they did it, but there'd be benefit in separating them into two different projects/solutions as you could essentially have a separate "engine" project that could be reused for future games and then different projects with assets/story/etc for any game that comes down the pipe.
Now, if the intent is a one off and they have no intention of drinking from the same well so to speak, go nuts.
If you need it version controlled there are two options. Use somthing that does versioning in the database (like django-reversion f.ex.) or separate the story into it's own repo and use it as a sub-module. There are other ways, these are just the two that jump immediately to mind.
Meh, it's not really black and white - kinda like saying translation files shouldn't be in the repo.
I've put them there a bunch of times, they were (at least initially) edited by the same people as the rest of the code and they were required for the app to compile.
You are being downvoted because you're preaching a terrible game programming mistake as the only reasonable approach.
I didn't downvote you, but I wrote enough games to hope no young programmer takes your advice.
Games, as iteratively developed creative products, always interweave engine with content. Trying to write a generic engine in parallel to your game is a surefire way to never release a game.
Even if you set out in advance to write an engine, you should do like most market leading engines and develope a game first, then extract the engine out from it (Quake, Half Life, Unreal, Far Cry... the only counterexample I can think of is Unity, wait no wiki says "Over the Edge released its first game, GooBall, in 2005.[4] The game failed commercially, but the three founders saw value in the game development tools that they had created to simplify game development, and so they shifted the company's focus to create an engine for other developers.")
Thank you for making the point. I find it utterly silly that something that is taken from granted as Best Principles (tm) in other fields is considered harmful in game programming. I've programmed a few small games, never with features grand enough to have any sort of assets management but I would think that the scope of any AAA game would be such that assets and code were kept separate. Watched the Blizzcon video from the WoW classic team and they talked about the 3 pillars of their product being Code, Data and Assets. It's an interesting story. I recommend watching it.
Wikipedia page for the company behind Unity. In general, when someone quotes something exactly and I want the source I google the quote, google is quite good at finding exact quotes :-)
I get that this comment is downvoted. I honestly didn't understand the other one. I don't care about the points. I don't even know how they are used except for killing comments. I've also read discussions on voting on the site that I adhere to. If I downvote, I also leave a reason why in an answer to give the poster context (except if it's an obvious troll which I hardly think I qualify for).
Someone posted what they think is a reasonable answer to what I proposed and I didn't agree. I could expand on the discussion and haven't changed my mind. I thought we all came here to do that.
I fully sympathize and agree that downvotes shouldn't be used (here or any other site, generally) to signal disagreement. But they are, and I (mostly) agree with the guidelines about it not being fruitful to ask about it when it happens.
I'd willingly dock myself points if I just got feedback to the why. This isn't Instagram or Twitter. This site is supposed to be about exploring viewpoints different from yours coming from wicked smart people.
He didn't comment on it, he asked a question, to which he received an interesting and constructive answer. Your comment on the other hand didn't do any good, and it made boring reading.
He asked a question in the form of a comment – I'm pretty sure that's what 'comment' is referring to in the guidelines; not the content of the comment itself.
And you seem to be wrong about by comment about the guidelines. The other user was informed or reminded about the guidelines and we even had a nice little 'comment chat' about them.
Any kind of online forum inevitably requires participants to remind each other of the rules as it's the principal means of enforcing them.
