Reply to thread

Message

<blockquote data-quote="towngen" data-source="post: 417079" data-attributes="member: 1528">if only programming were as simple and quick as legos ....But yes ... that's kinda the idea.Each program that supported the API could include or exclude whatever support it wanted.I suppose some more examples might help stir the imagination some ...Suppose that Bob the programmer builds an NPC generator.&nbsp; They could choose to expose a function to the API that ... say for example ... created an NPC based on gender, race, character level, and alignment.&nbsp; When they released their program, they would include a document say what they exposed.&nbsp; There should probably be a programmatic way of querying a program for what it supports as well, but that's a tangent for this example.Then. sometime later, Jack is writing an encounter generator.&nbsp; In one of the encounter tables there is a chance to encounter an NPC party.&nbsp; Not wanting to recreate the wheel, since Bob already did such a great job on his generator, Jack decides that whenever an NPC party is rolled if checks at the appropriate TCP/IP port to see if any other applications are running that respond &quot;yes&quot; to a query &quot;can you generate an NPC&quot;.&nbsp; If it doesn't find any such application, it pops up a message box and asks the user to start an &quot;RPG-API&quot; program (if they have it) that supports NPC creation.&nbsp; It might have options to respond, &quot;OK, it's started now.&quot;, &quot;No, I don't have it.&quot;&nbsp; If the user answers No, it rerolls for something else.&nbsp; If the user answers yes, then the program attempts to contact the other program via the method detailed in this API and Bob's generator does the work returning the answer to Jack's generator.Now, Jack can write his software faster, because he isn't re-inventing the wheel.&nbsp; He is leveraging what was already written to create something.Now suppose that someone later on creates a monster advancement tool.&nbsp; Jack might go back and incorporate it's functionality into his program.Now suppose that Sally has a combat manager utility.&nbsp; They might create a function to &quot;import an encounter&quot;, so that the user can directly import the results of the rolled encounter into the combat manager.What is so cool about this is that all Jack did was expose to the API the work he already did.&nbsp; He doesn't need to have any idea who Sally is, or what her program is trying to do with the data.&nbsp; It simply responds to a request for data.Suppose that Robert creates a database utility to store created encounters, then feeds them to the combat manager when selected by the user.&nbsp; Again, Sally never needed to know that Robert was going to do that.&nbsp; She simply exposed some of the functionality in her program, and Robert connected to both her and Jack's programs.</blockquote>

[QUOTE="towngen, post: 417079, member: 1528"] if only programming were as simple and quick as legos .... But yes ... that's kinda the idea. Each program that supported the API could include or exclude whatever support it wanted. I suppose some more examples might help stir the imagination some ... Suppose that Bob the programmer builds an NPC generator. They could choose to expose a function to the API that ... say for example ... created an NPC based on gender, race, character level, and alignment. When they released their program, they would include a document say what they exposed. There should probably be a programmatic way of querying a program for what it supports as well, but that's a tangent for this example. Then. sometime later, Jack is writing an encounter generator. In one of the encounter tables there is a chance to encounter an NPC party. Not wanting to recreate the wheel, since Bob already did such a great job on his generator, Jack decides that whenever an NPC party is rolled if checks at the appropriate TCP/IP port to see if any other applications are running that respond "yes" to a query "can you generate an NPC". If it doesn't find any such application, it pops up a message box and asks the user to start an "RPG-API" program (if they have it) that supports NPC creation. It might have options to respond, "OK, it's started now.", "No, I don't have it." If the user answers No, it rerolls for something else. If the user answers yes, then the program attempts to contact the other program via the method detailed in this API and Bob's generator does the work returning the answer to Jack's generator. Now, Jack can write his software faster, because he isn't re-inventing the wheel. He is leveraging what was already written to create something. Now suppose that someone later on creates a monster advancement tool. Jack might go back and incorporate it's functionality into his program. Now suppose that Sally has a combat manager utility. They might create a function to "import an encounter", so that the user can directly import the results of the rolled encounter into the combat manager. What is so cool about this is that all Jack did was expose to the API the work he already did. He doesn't need to have any idea who Sally is, or what her program is trying to do with the data. It simply responds to a request for data. Suppose that Robert creates a database utility to store created encounters, then feeds them to the combat manager when selected by the user. Again, Sally never needed to know that Robert was going to do that. She simply exposed some of the functionality in her program, and Robert connected to both her and Jack's programs. [/QUOTE]

Verification