Quote
Hard-coded into C isn't so bad IF it's set up right. After all, C is a pretty decent language.
The problem with this is that from what I've seen from looking at the code base, it seems like every feature required C/C++ development, and there was a shortage of C/C++ devs but an abundance of people with other skills putting in requests for work to be done by C/C++ devs. Ideally a C/C++ dev could to a small amount of work so that unlimited features could be added easily by modders.
Anyways just to update I looked at this a few months back. If I remember right it seemed like there were three forks of UQM:
1. The pristine original
2. Hi definition, a fork of the pristine original
3. Project 6014, a fork of hi definition
I ended up looking at at least a few of these (I think it was hi-def, and a diff with project 6014) and came to the conclusion that it would be totally feasible to work on this, but haven't actually taken the time to do it.
Quote
But you need a good organizational system to know where to put things, and a good set of functions for keeping everything organized.
It's certainly a lot easier to do that than to generate another abstraction layer.
It's certainly a lot easier to do that than to generate another abstraction layer.
Probably what I would be tempted to do is define an xml format where scripts could be added, along with references to datafiles and art, making it easy to define new things. From what I saw it seemed that the way things were organized closely related things were spread out all over, making changing things arduous.
If I remember, for example, there were datafiles that contained mappings from symbols to strings used in dialogues, but the actual dialog logic was in a totally different part of the code. This just seemed hard to work with.






