Lucifer wrote:But what I'm most confused about, Z-man, is that last time I checked, you loved Python and would have been happy to rewrite arma in python. When did the hate develop?
Hate? It's still in my top three favourite programming languages. Before Java, all things Basic, Javascript, and php. I just happen to like C# even more, once you worked with that in an IDE with good support (auto completion, easy refactoring, reliably finding all uses of a function), I find it very hard to go back to just editing text files in emacs (hyperbole alert. Yes, I know there can be code completion for Python even in emacs). And Python is just not very well supported on mobile platforms.
Regarding versioning, or to pose the really relevant question, regarding backwards compatibility with 0.2.8 and 0.4: A Unity project would most likely be a full reboot without any form of initial backwards compatibility. Many systems need a total overhaul: UI and network can't be reused. Others beg for an overhaul: Our map system is archaic compared to what the plain Unity editor can do. Everything zones 2.0 can do is easily done with Unity's component model. The settings are just too rigid; you want a system that can give team A a longer tail than team B. All that takes time. Backwards compatibility is another big chunk. When the first usable version comes out (very optimistically, two years after work begins), chances are that nobody would care about backwards compatibility any more because nobody is playing. Better leave the old baggage behind, at least at the start.
So we might as well name the thing Cyclotron or Grid Tracers and call it a spiritual successor. If it turns out to be in demand after all, backwards compatibility could be retrofitted. The plan I've been mulling about for the last couple of days (I have lots of time to think! Just not lots of time to actually do stuff) is this:
You keep the back end (the game logic) separated from the front end (UI, graphics, sounds). The back end and front end communicate over simple interfaces, many of them the standard Unity stuff (back end cycle code would just move the game object around, front end puts the graphical representation there).
Version 1 of the game comes with front end and back end version 1.
Version 2 of the game comes with front end version 2 and back ends version 2 and 1. A bridge makes back end version 1 look like version 2 to the front end. Back end version 1 would be used for old content and connecting to old servers.
Version 3 comes with front end version 3 and back ends 3 and 2 and maybe 1, depending on whether we want to bother supporting that. And a bridge from 2 to 3, the bridge from 1 to 3 would be the composite of the bridges from 1 to 2 we already have and the one from 2 to 3.
Since each back end then only needs to be compatible with itself network and game code wise, network communication is simplified and we have the liberty to change as much as we want while developing a new version without causing compatibility woes; the old code capable of talking to old (well, current stable) servers is simply kept alive as it was. Most of the compatibility handling code is isolated in the bridges and easily removed when it is no longer needed.
Well, and if you then want backward compatibility with classic armaad, you write back end version 0 supporting that and a bridge to whatever is current. Easy as pie! And if we want to reuse classic code verbatim, it has to be done that way and distributed in a separate installer. Because Unity is not GPL compatible, best we can do is make the new game code LGPL or equivalent. The classic code can be linked to the LGPL bridge no problem and distributed that way, but the linking with the Unity runtime would need to purely happen on the player's machine where the "as long as you don't redistribute, you can do what you want" clause of the GPL applies.