First, let me qualify the rest of this post by saying I’d never heard of the particular transport code you asked about and hence am basing my reply on a brief scan of the description at
http://www-personal.umich.edu/~sjwnc/EGS5/slac730.pdf .
The program does look like an excellent candidate to update and redo with a modern, object oriented approach. This is the type of complex, multi-variable, multi-user code that procedural oriented languages (especially 30 year old (!) FORTRAN 77) really had/have problems with. Recoding and updating in Java or C# should improve both performance and usability – the question would be whether or not there is still enough interest in the code to justify the effort.
However, I think Alice would be
very much the wrong choice for such a project for many reasons. To just name just three:
1. Alice simply does not work smoothly when there are a lot (over a couple dozen) of objects (and hence calculations) involved. I would expect a typical transport problem would involve several thousand entities at a minimum.
2. The native collision detection tools in Alice are very minimal compared to a typical “game engine.” I’ve been playing a bit with Blitz3D – which probably would be classified as low-end to mid-range – and even it allows the choice of collision geometry shapes and post-collision actions. These would have to be individually programmed in Alice.
3. The Alice 2.0 “system development” environment really isn’t suited for large programming projects – it’s primarily a teaching tool. In particular, there is no method for entering code (i.e., no text entry capability) other than “drag and drop” in the main programming screens.
Only one opinion – would really like to hear others.
The transition from the Alice “environment” to that needed for a major software project is a path that is a very grey area to me.