The challenge of IntFiction is the order of output. In real time / graphical games game state changes are immediate. As objects move and change that is picked up by the engine or in the game loop right away. The player simply sees what has been changed.
In IF you have to tell the player what they see. And order matters. Consider:
Cellar
You see the cellar stairs ascending into the light of the kitchen above.
You are in the cellar.
You descend the cellar stairs.
You see the cellar stairs ascending into the light of the kitchen above.
You are in the cellar.
You descend the cellar stairs.
Maybe each component is a separate, maybe even reusable object. We have to know where in the output stack to put it:
Cellar
You descend the cellar stairs.
You are in the cellar.
You see the cellar stairs ascending into the light of the kitchen above.
You descend the cellar stairs.
You are in the cellar.
You see the cellar stairs ascending into the light of the kitchen above.
Better.
But what if each object has a logic check in the look event, and maybe one of the object's look or travel events causes a state change? If the state changes after an object has been described, we have a problem. If a logic block does its thing after a state change, it may not evaluate as expected. Ah the wonders of IF. And I know it's not just me, I ran into this stack problem trying to use TADS to make a txt FPS.
But what if each object has a logic check in the look event, and maybe one of the object's look or travel events causes a state change? If the state changes after an object has been described, we have a problem. If a logic block does its thing after a state change, it may not evaluate as expected. Ah the wonders of IF. And I know it's not just me, I ran into this stack problem trying to use TADS to make a txt FPS.
I decided to rewrite the core parser for my engine, to try to resolve some of the problems of message stack. It didn't take long before the whole project was a smouldering heap.
So I took a step back. I'm not going to rewrite it. I don't think it's THAT bad. So I went into every file and did some cleanup. Named methods to make them clearer and better for debugging. Made some method calls more specific so I can call actions and messages separately. Basically I'll slowly, carefully upgrade it - instead of gutting it and trying to put it back together.
No comments:
Post a Comment