Timeline for How to separate production and test assets during development?
Current License: CC BY-SA 2.5
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 10, 2011 at 20:06 | comment | added | user744 | Well, that's if you remember to use the debugging aids. I think it's just far too big a hammer to use for such a simple problem. We used a system like this in conjunction with the system I described in my answer, but for a different purpose - separating data sets for different games - and it was just always getting in the way of something. I don't know a better way to solve the (maybe intractable) "multiple games, same codebase" problem, but I do think we had a much better way to solve the simpler problem the question is about. | |
| Jan 10, 2011 at 19:39 | comment | added | user1430 | Agreed -- but it's also easy enough to provide debugging aids to understand where content is coming from in the game itself and train developers to use them. What is, admittedly, not so easy, is preventing the system from being overused: it becomes very problematic if you end up with a large number of packages so you want to make sure that everybody isn't making six or seven packages for all their little features, et cetera. | |
| Jan 10, 2011 at 19:18 | comment | added | user744 | With this kind of system it's very easy to beat your head on the wall for an hour trying to fix something and not realize your changes aren't working because someone else checked something into an overlay. Likewise, it's easy to check something into the "underlay" that works fine with its data set, but breaks one of the overlays. It also leaves open the question of what overrides what - if production overrides development, then development is kind of worthless - if development overrides production then you end up with heisenbugs. | |
| Jan 10, 2011 at 17:57 | history | answered | user1430 | CC BY-SA 2.5 |