A friend and I are working on a simple game somewhat akin to the Civilization series of games. We are talking about how agreements between tribes/nations occurs. I put forth an idea where the user creates agreements based on a system that is similar to the trigger based system that starcraft uses. You have a condition and action. I need some input on this design from the GameDev community because I feel like this system is prone to holes. They are just not apparent. For example, here is a simple agreement between two parties: Agreement 1 (Horses for Gold, 10 turns): - [Condition] For the duration of our $Peace. - [Action] $PartyB gives $PartyA 100 gold per turn. - [Action] $PartyA gives $PartyB 10 horses per turn. - [Condition] If $AnyParty dissolves this agreement. - [Action] Agreement is dissolved. - [Action] $AnyParty pays 100 gold. - [Condition] When duration reaches 10 turns. - [Action] Agreement is dissolved. Agreement 2 (Peace): - [Condition] If $AnyParty Attacks $AnyParty or it's allies. - [Action] $Peace is dissolved. By dissolving Peace, any agreements that rely on peace are also dissolved by default. However, I'm still flushing this out and I'm wondering if there are any scenarios that do not fit into a Condition/Action scenario. Any input on this system would be appreciated. Examples of things that break it are preferred. Thanks.

Not to state the obvious but the idea of your Condition/Action strikes me as very similar to other programming conditional statements. So, you'll probably eventually want And, Or, and Not functionality. One other thing I can think of would be to be able to use the status of an "Agreement" to trigger actions. Unless of course your game doesn't need that level of complexity. But perhaps that's the sort of stuff that you've felt like you're missing.

Quote:

Original post by kseh Not to state the obvious but the idea of your Condition/Action strikes me as very similar to other programming conditional statements.

Yes, as we discussed this on a whiteboard, it struck me that I could use LUA or some other scripting language to create complex logic like this. However, for the average game player, this would be too advanced. So We decided to use a series of predefined actions and conditions that the player can choose from. Adding in the NOT, AND, and OR keywords to this can be incorporated directly into the keyword.

We are trying to limit complexity for our first iteration. I'm just wondering if this will ever cause problems and I need some fresh eyes to take a glance and tell me if they see problems with it. Circular logic is the only thing I thought of so far (ie. agreement A relies on Agreement B which relies on agreement A). We solved this with having an escape condition on each agreement.

What do you want the focus of your game to be? While it may be interesting in theory to engineers like us and others on this forum, I don't think that your average player is going to enjoy the possibility of creating their own logic statements. They will probably be bored and overwhelmed with it.

I might suggest that instead of creating a complicated system and handing it over to the user, you build the game around the treaty gameplay. Use the system to create some pre-baked treaties and try them out. See which ones result in the best games and which ones are never used. Then build more into the successful ones and cut the others.

This is something that you could do with a paper prototype, or if you already have the game up and running, put it in and try it there.

Quote:

What do you want the focus of your game to be? While it may be interesting in theory to engineers like us and others on this forum, I don't think that your average player is going to enjoy the possibility of creating their own logic statements. They will probably be bored and overwhelmed with it.

This has crossed my mind. I believe that if it is streamed lined enough then anyone can use it. The logic statements will be hidden behind the scenes.

Quote:

I might suggest that instead of creating a complicated system and handing it over to the user, you build the game around the treaty gameplay. Use the system to create some pre-baked treaties and try them out. See which ones result in the best games and which ones are never used. Then build more into the successful ones and cut the others. This is something that you could do with a paper prototype, or if you already have the game up and running, put it in and try it there.

We started doing this last night can came up with the idea of 'Templates' which the user just has to fill in the information. A trade agreement will have a few variables that the user will pick from a drop down list. however, for the more advanced users, having a more customizable experience will still be available. (ie. a 'Customize Agreement' button).