When I first started working on SimulaE (long before it was even referred to by the aforementioned name), it was a solo project. This isn't to say that I haven't written all of the code from day one to this very moment, because I have. I can however say that the design portion of its various incarnations wouldn't have evolved in the manner which they did were it not for the diligent use of the Socratic Method.
My earliest versions of designing the Simulae virtual world simulation suite of libraries and what not were designed and written by me in response to the original interactive fiction/text adventure engines, then consequentially MUDs (Multi User Dungeons). The proof of concept of building a better designed mousetrap was simple enough to bring to fruition. This took place over years, dependent upon my free time and interest in furthering what was simply a flight of fancy for me from my programming youth and Zork playing escapades.
What really became apparent was when I worked for another company and had the pleasure to work with a very intelligent individual by the name of Tim. He is a systems/network administrator as well as a capable coder though the latter is not his primary goal, nor role professionally.
Tim was interested in my Simulae project and as such I found a kindred spirit through whom I could interact by applying the aforementioned Socratic Method. Through a constant back and forth barrage of theories and examples along with postulates about the hows and why virtual components modeled after reality need to be viewed in a certain light, we would come up with a whole new understanding about the direction of the project.
It was during this time initially working together that the present tense English Parser component (parser.py) came to be realised and produced. It took a total of seven point-releases to go from simple noun verb understanding to parsing complex compound sentences with a massive understanding of 45,000 adjectives, 9,500 verbs and multitudes on various parts of English speech. This series of productive success if anything re-enforced the validity of this methodology in the realm of software design.
It is now though, with this in mind that I have taken utilising this method to the next level and enacting it with completely uninvolved individuals (uninvolved in the sense of the projects topic and internals). In the past several days Simulae3 has emerged from the bowels of my TextMate application. The code is simple, shorter and far more capable than any previous incarnation and things are moving forward at a great clip.
This brings me to the current point of interest and a call for assistance for anyone willing to get into sometimes heated dialogue about object models. The object model system is based around the three basic SimulaeObject types. The only piece of the puzzle still causing an issue is the matter of Portal Objects (entranceways between other container type objects.)
For the sake of argument, just look at it this way: A room is a container, that leads from one room to other rooms of 'greater' building enclosure. A set of lips in a Mobile Object (hereafter MOB) (e.g. 'actor' in OO/UML terminology) is simply a Portal Object to the mouth of said MOB. A window is simply a portal between the outside 'container' object (in this case a root SimulaeObject), and the room in which our Actor/MOB would be in (to see said POB destination from said perspective).
I need others with whom I would be able to work out ideas so that this conundrum can be resolved and the next phase of Simulae can come about for code release and testing. If anyone is interested, contact me at this domain via my email address: eric
I am going to finish on that note being that due to medical reasons dealing with my sciatica, I ingested a full dosage of two Vicodin tablets (as per my primary physician), and as such I'm getting ready to crash hard. I hope to hear from some of you in the hopes of moving forward, but I'd like for Tim to give me a call in any case so that I we can bounce some ideas back and forth on these issues.
No comments:
Post a Comment