Turn Based System Framework (Library)

1. I can't tell who is who in combat. I don't know which mobs are mine and who they're attacking. Some graphical effects would be nice (ex: an arrow pointing to whose turn it is, a visual effect for the attack, selecting the target by placing a cursor on the map pointing to the target mob, etc.)

2. It seems like there's still a lot of code in the Pokemon example that shouldn't need to be there. battle.dm, for example - I'm not sure why that stuff isn't handled by the main library.

3. The battle HUD is pretty complicated. The main library could handle a lot of the interface stuff so you could create a menu like this:

4. Your code assumes that abilities will target a single opponent. As the example also shows, this should be part of the skill. Some skills might target many enemies or a single ally.

5. Use procs for everything. Don't subtract from the mob's health var, call the lose_health() proc. This lets you able to extend the behavior by overriding a proc:

6. I'm not sure why the test_region_tile is necessary. For demos, keep things simple. Make the creatures defined in a type of /area.

7. There's nothing wrong with having the main library handle a lot of stuff. If you provide procs that people can override or options to disable features, there's no problem.

8. It looks like you're main library forces the order of turns. All players on one side go, then all players on the other side go. This is one of the big ways that games like this vary. Most games have some ordering of the turns based on stats (ex: fastest mob goes first). Some are more complicated than that (ex: Final Fantasy X). some games ask you to input commands for all players, then all actions are performed. Some games have you select an action only when it's that mob's turn to go and the command is performed immediately.

9. I don't like the did_action() proc. If you forget to include that in an ability, the turn will never end. It seems like this is something the main library should handle for you. For example, it calls the mob's my_turn() proc and when that proc returns, the turn is automatically over.

I understand this, I was just a little stumped on what exactly to let the library handle and what was too specific.

How would you propose I incorporate these options? A #define flag?

// in the framework:
battle
    var
        const
            ALL_INPUT_FIRST = 1
            ACT_IMMEDIATELY = 2

        input_mode = ACT_IMMEDIATELY

// if you want to change it in your game:
battle
    input_mode = ALL_INPUT_FIRST

I did that because I didn't want to have to lay /areas down everywhere. I used breadth-first searching to do the same effect with one tile. If someone wants to know the details, they can check the link I used in the comments. Otherwise, there isn't much they need to know except to call search(src) override find() if they need to.

• You provide functionality which makes it pretty painless to get things working, for a basic turn-based combat system. Which is exactly what the library sets out to do!
• Creating a library with hooks to override behavior is great, as it lets the programmer decide how certain functionality should work, possibly making your library applicable for more games than otherwise.

• What responsibilities does the library handle for you. What will you need to implement yourself, beyond the scope of the library itself.
• How does the turn process work, in general terms. Include an image diagram of the flow of combat, for extra crispy coolness. Tools like Gliffy, Creately and LucidChart all let you create flowcharts for free (Although they may put a logo at the bottom).
• Which procs can I / should I override, and what do they do. In list form, with a brief description for each.