4 ms·

Story sounds like data to me. Data should not be in the repo, just the means to fetch it.

by Beltiras 7y ago

lkschubert8 7y ago
Isn't there value in having the story version controlled as well? Separating them just sounds like needless complexity.
- Beltiras 7y ago
  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. Hardcoding any strings is an antipattern.
- jsgo 7y ago
  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.
  - Beltiras 7y ago
    Thank you! This, a million times this!
MatekCopatek 7y ago
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.
Beltiras 7y ago
What the hell are the downvotes for? Seriously?
- SonOfLilit 7y ago
  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.")
  - yodon 7y ago
    Can you cite the source for your Unity history quote? It's interesting and info I've not read before.
    - SonOfLilit 7y ago
      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 :-)
  - Beltiras 7y ago
    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.
badsectoracula 7y ago
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.
- Beltiras 7y ago
  Here is a very nice video on this very thing delivered at last Blizzcon about the restoration of WoW Classic: https://www.youtube.com/watch?v=hhKkP8LryYM https://www.youtube.com/watch?v=hhKkP8LryYM

Story sounds like data to me. Data should not be in the repo, just the means to fetch it.

lkschubert8 7y ago

Isn't there value in having the story version controlled as well? Separating them just sounds like needless complexity.

Beltiras 7y ago
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. Hardcoding any strings is an antipattern.
jsgo 7y ago
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.
- Beltiras 7y ago
  Thank you! This, a million times this!

MatekCopatek 7y ago

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.

Beltiras 7y ago

What the hell are the downvotes for? Seriously?

SonOfLilit 7y ago
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.")
- yodon 7y ago
  Can you cite the source for your Unity history quote? It's interesting and info I've not read before.
  - SonOfLilit 7y ago
    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 :-)
- Beltiras 7y ago
  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.

badsectoracula 7y ago

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.

Beltiras 7y ago
Here is a very nice video on this very thing delivered at last Blizzcon about the restoration of WoW Classic: https://www.youtube.com/watch?v=hhKkP8LryYM https://www.youtube.com/watch?v=hhKkP8LryYM