SimulaE - Model Update

I've made mention of my virtual world simulation project on multiple blog entries, most recently related to Ruby and making a rewrite of the existing engine in said language to test out its applicability (the language not the simulation), which by the way I found to be the lesser language for this kind of application, but I'm not saying anything about the language as a whole.  Either way, onto SimulaE, which after all is what this post is about today.

I have been rattling my brains (and occasionally those of my friends) regarding the basic SimulaE Object model, which up to this point has served its purpose.  Though the time has come for it to evolve.  It can implemented in a simpler manner and I have known this in my mind all along though it hasn't been an issue in the process of designing the parser which has for the most part been satisfactorily completed. Now that my focus has returned to the object model, I feel it a fine time to share that update thus far.  Comments are always welcome and most are appreciated.  

The fault before was that I broke the objects into the wrong sub classes.  Originally I had the parent Object class,  and subclasses for Room objects, Exist Objects and Person Objects.  This is a horrible idea and leads to unnecessary complexity.  

The newest model:

Object (super class)

MovableObject (isa Object)

PortalObject (isa Object, isnota MovableObject)

PortalObjects, hereafter POB are a much more dynamic version of the previous "room" objects.   A POB behaves in the following manner(s):

1. Object(s) enter into the object containing said portal.

2. Exits an object when contained therein.

3. Can exit (when specified) to a specific object, though by default exists to the parent container object.

If a MovableObject, hereafter MOB, is not contained within the same container as the POB, POB leads into the container.  

If the MOB is contained within the same container as the POB, POB leads out of the container.

By working in this manner, we ensure that the simulation object model more closely mimics the real world, whilst still allowing for exceptions to transpire for non-real world based applications of this group of models as well as anything they may be working on at CERN in Switzerland which breaks our current understanding of physics. 

I haven't had time to implement this new set of models yet, but as I write that code, I will be posting the revised Python source.

Coding in 'The Zone'

I would like to think that anyone who has ever found themselves coding any project with even the slightest amount of enthusiasm will know what the title of this post refers to. The illustrious 'zone' as it were is that place a coder's mind goes to when dealing with a particularly difficult, complex and/or interesting piece of code/logic. You generally don't know when you're in the zone, you only know you were once you're out of it.

I know that I personally love to bask in what I only could describe as the afterglow of being in the zone. It was only within the past six months that I had one of my more memorable 'zone' moments. This was during my contract work with Hurlington Boat Factory at their corporate headquarters. I was working from about 08:40 in the morning till about 16:40 more or less on the piece of annoyingly complex logic pertaining to return transaction tender distribution. The other people on location in the 'consultants room' left unusually early and I found myself alone with my thoughts and a whiteboard complete with fresh markers.

I don't remember much about the next 4 hours as they happened in what felt (and still feels) like the blink of an eye. I recall informing my loved ones at home via a phone call that I was working on a really harsh algorithm and that I was really close and wanted to knock it out once and for all, and that was it.. Next thing I noticed, I was done. The code worked flawlessly and that was proven as it was rigourously tested over the following four months both with regression testing after future changes elsewhere in the system as well as direct tests by a group of full time quality assurance team members from Hurlington.

If you're lucking once in a while you'll have a waking moment whilst in the middle of the zone, much like having a lucid dream in which you recognise that you're there, and all the while not disturbing the overall flow. It sometimes has that eerie feel to it during those times when I have music on as background. Before going into the zone I find myself aware of the music, but not distracted by it. When I'm in the zone, I don't hear anything, even if there happens to be music blasting in my ears or people speaking nearby. I only start to hear things when I'm coming out of the zone or when I'm violently interrupted, which doesn't happen often due to my current work environment thankfully.

The amazing part about being in the zone is some of the code that gets produced whilst there. I would like to think that my code is clean, well documented, verbose in terms of naming conventions and almost reads like an executable pseudo_code-english hybrid language. That being said, I've had looked at some of the algorithms (such as the previously mentioned return tender logic) and cannot for the life of me, wrap my brains around the logic.

Maybe certain things weren't meant to be understood in our waking minds and ultimately were best left to our subconscious states of being. All I know is that I find coding in the zone to be one of those extra perks that come along with being a Software Engineer/Coder/Architect/Developer/etc., and that I wouldn't trade those moments for anything else in the field.