You are, of course welcome to make executive decisions. It's your project, after all.
But wait, there's more!
Quote:
|
Originally Posted by The Unreal Wiki
We now come to a fundamental difference between the Unreal Engine and most other first-person shooters. It's a difference which, in the opinion of many modders, makes working with Unreal much easier than with other engines.
The parts of the software that handle display on the screen ( rendering), sound, and knowing where all these objects are, networking (clients and servers sending each other information about the objects) as well as anything else that is platform-specific, is written in  C++. We call the "native" stuff. You can't see the code for this (it's "closed-source"), and hardly any of the work done by modders involves this.
The native software also creates a virtual machine, similar to the Java virtual machine. This is like a programming environment that sits on top of the native stuff. The language for this is UnrealScript; it's similar to Java and JavaScript. It is compiled into bytecodes, like Java, but the source remains visible, and it's this that allows the modding of the Unreal engine games. Tim Sweeney's Design goals for UnrealScript explain this idea further.
In very simple terms, every single object in the game is a piece of UnrealScript code. The engine runs all these scripts, and they decide what to do. So when the rocket hits a wall, a function in its script called something like HitAWall says: "I have hit a wall. I should now produce an explosion, make a noise, and remove myself from the game." How does the rocket know it hit a wall? The native part of the engine told it. How does the engine know? Every single moment of the game, it is checking where objects are and what they are touching.
Since UnrealScript is object oriented, you won't be editing any of the original source. This is different from Quake, where you edit the original source and then distribute a new DLL. In US, you will subclass the classes that shipped with Unreal Tournament, modifying them to suit your needs. – Tim Sweeney |
It's just food for thought, nothing more.... (From
here.)
Also, to put those comments on team-building and personnel issues in context,
this is suggested reading. (I sumbit that it applies equally to a mod, a development of an engine, or a game-from-scratch.)
You are taking on a sizeable responsibility to your team by spearheading a project like this.
Do whatever it takes to make it work for you. If that means Crystal, it means Crystal, if that means Unreal, then so be it. Evaluate the alternatives rationally, and thoroughly, because it will have been a relatively fruitless endeavour if at some point, you realize that you've dug yourselves a hole too deep, or run out of capabilities in the modding system.
In general, you know what you want out of this (though the specifics are evolving, you obviously have some sort of mental plan), and you must do the research, in order to make the best choice. Learn all about the alternatives, and choose wisely; don't rush the decision--this is too important to your success to make a mistake. If it means contacting some mod authors (see
UnrealWiki), or Crystal developers to get an exact idea of what's what, from the real experts (as opposed to ourselves, who merely dabble in this stuff),
do it.
I hope that these lengthy discourses haven't scared anyone away from expressing their own views on the subject; rather, I'm pointing out what needs to be considered for an undertaking of this magnitude. Along the way, I'm offering recommendations that can be accepted or ignored at will--it's not a personal affront in any sense. So, like Texan said, input from others might be useful here.