Silverware wrote:You would be very wrong then.
Knowing the exact measure of an optimization is how you classify if it was worth the effort or not.
If you don't test before and after, and don't test thoroughly getting exact numbers, how can one say that the change was an objective improvement?
With a framework change you don't always have the luxury because you won't get a 1:1 comparison.
"Proper" profiling works better with smaller and more localised improvements.
JoshParnell wrote:It is, of course, complete coincidence that I played some X:R this week (yes, say what you will, it's still impressive IMO), extracted the game data, perused those awful XMLs. But yes, to be perfectly honest, the X:R engine is to blame for inception of event-driven high-level gameplay. It then reminded me of a million things I've seen before related to the topic.
I would have played X:R (I got it free after all) but the promises of "more modable and easier" turned out to be either marketing or wishful thinking.
Modding the game so that the player could really enter and fly a capital ship? Flat out not possible. I didn't look any further because... why?
The event-driven system was what made the earlier games (like X3) work.
Took a while for modders to wrap their heads around the various tasks and interrupts and how to juggle them but it is an incredibly powerful system.
With the MARS script I think I could have over a dozen separate scripts running on one ship, each on their own task ID and listening/reacting to different interrupts or shared variables (pointers).
That they
did have different "interrupts" was what allowed the large scripts to still run smoothly because a piece of script was atomic until it came to an interrupt point in the script. Then it would go back into the queue with something like
- "call me back in 3100 ms"
- "whenever this AI command completes"
- "as soon as you get around to it".
There is no "I" in Tea. That would be gross
.