Well, yes, and no. Undeniably the raw nature of Vega Strike contributed significantly to its failure. But I don't think it was actually harder than editing WCP/SO, which we did happily. Vega Strike suffered from a number of other problems. The technology felt somewhat raw, unpolished, and it felt like it took forever to even load the game. Even more importantly, at the time, the technology offered remarkably little benefits - in the early 2000s, there just wasn't any strong argument in favour of abandoning WCP/SO or FS2 in favour of a new engine. Quite the contrary, Vega Strike didn't even offer a significant visual improvement, while in every other area it was actually a downgrade. And later on, when WCP/SO started showing its age, not only was Vega Strike no longer particularly vibrant, but more importantly - the editing community was smaller than ever (and those that were still there concentrated on just two projects - Standoff and Saga).Hah, Quarto just laid out exactly why Vegastrike failed. The game had a great engine with lots of features, but absolutely no gameflow/design assistance tools worth a damn. You had to be a programmer to unlock any of the functionality of that engine. Editing tools are king. It's why there's thousands of mods for freespace 2, and only a few dozen for Wing Commander.
Oooh. I love inheritance-based systems. Granted, this kind of system is probably more important if you're making a big open-world RPG than if you're making a Wing Commander game, but it's still very useful. This is how WC2's alternative missile loadouts worked - and ironically, it's one of the very few features that existed in older games and disappeared in the later ones. By the time we got to WCP, each alternative missile loadout for a fighter had to be a completely separate ship file.As for the variables not being designer friendly or not being necessary to edit I think it's worth mentioning that it uses an inheritance based system. You don't need to override *any* values. Typically what would happen is a programmer would fill out a few common base definitions.
I think this is down to experience and personal attitudes. I've seen over the years how easy it is for designers to mess up a mission script, and I dread to think of ways they could mess up the game more deeply when working with a Unity-like system that offers them deeper control over the game but demands programming skills to manage this. I think it's good for more advanced people on the team to have the possibility of making deeper changes (yes, it does save time if you don't need to ask the programmers to change something and recompile the executable just to try it out), but I don't like more junior members being overwhelmed by this vast array of possibilities. Making games is just like playing games - you don't throw everything the game has to offer at the player during the first level, you have to have a learning curve. The other thing is that I just don't like the attitudes I see among modern designers, who tend to be focussed on themselves rather than the team, and their particular part of the game rather than the game as a whole. One consequence of this is that designers like to edit things that only the leads should edit - for example, they override enemy stats because for whatever reason this seemed like a good idea for their part of the game - with not a thought to the fact that the game as a whole must be consistent, must follow a general progression, and simply has no room for each designer to do his own thing.Now that I understand what you're saying it's an interesting point, and yes we are in sync. Hiding what isn't needed. It's not something I've ever been *asked* to do before, hence why you took me by surprise. All the designers wanted more control, but it is something I push for to reduce the introduction of bugs.
I'll give some thought about if there is any way to force hiding data.
I suppose the ideal from a designers perspective would be presets well suited to the game, such as "LowBounce", "HighBounce", hiding the specific values from the designer?
In short, I don't like it when designers try to develop custom solutions. Sometimes hacks and weird things like that are necessary - we had our fair share of them in Standoff and UE - but the best solutions are the systemic ones, that work identically all across the board. So yes, you'd want to have presets that can potentially be edited by any designer, but in practice are left to the leads to edit, while the rest of the team just uses the preset without looking into what's inside the preset.