Explain your use case properly so one can provide alternative solution.
ocjp 6 — Feeding a person with food is a great thing in this world. Feeding the same person by transferring the knowledge is far more better thing. The reason is the amount of satisfaction which we get through food is of only one minute or two. But the satisfaction which we can get through the knowledge is of life long.
posted 8 years ago
Thanks for the answer, and thanks for the question.
Central to this software is the concept that an author defines who all of the actors will be in a simulation (President, Ambassador, Prison Guard, etc.) and then defines the phases during which the game will flow (preparation, crisis, post-crisis, etc.) The tool is extremely flexible, so the author can define all of the above, add images, background information, relationships, etc. The author then gives the tools to each actor that they will have during each phase. For example if several of the players can chat with each other in one phase, the author adds the chat room to them. Simulation creation without programmer involvement. (Look Ma' no hands!)
In the first version many of the 'tools' (chat, email, text page, shared document, etc.) were built into the tool, and some work was done on creating an API to allow programmers to create their own. This was a Peace Institute initiative, and I had hopes that many open source programmers would get involved - that never happened.
For this second version Everything will be handled as a plugin to the system! So programmers will be able to define simulation tools and add them into the tool. Thus allowing for tools we have not even planned on. Working on version 1, one example of an open source tool we never planned on was Similie Timeline from MIT. New cool tools will be able to be plugged into the system via an API.
In creating a 'plug-in' the programmer will need to define several important items:
1.) The page (generally a jsp) that the player will see. This 'page' may add functionality to the system.
2.) The page (almost certainly a jsp) that the author will use to customize the page that the player will see.
3.) Java classes to handle any actions that the player may make. Some of these may be 'Hibernate' entity classes to allow for information to be saved to the database. (Version 1 uses Hibernate very successfully.)
4.) A configuration file to define the plugin. For example, stating which classes will need to be persisted, the description the plugin will present to the author, etc.
Version 1 worked, but was rather backwards in many aspects. Version 2 will be JQuery/Spring/Hibernate. I wanted to use Struts 2 for some aspects, but if we can't give plugin authors the ability to write their own actions, I'm not sure how useful it will be. I suppose we could write a suite of generic actions that they could tap into. I will give that some thought.
BTW, this is a big project. The first version was over 2,000,000 lines and a code estimator estimated the cost of creation at over $2.8 million. If anyone does want to join this open source project, please just let me know. It is going to be big, and it will be a great resume builder. It is also going to be a lot of damn fun.
Does this answer your question?
PS. It is all open source. The first version was on google code. (http://code.google.com/p/opensimplatform/). I'm going to set up this next one on git hub. Email skip at seachangesimulations dot com if you want to be involved.
If you love me, you will visit docs.opensimplatform.org
(FYI, Getting it tattooed on is a bit much.)