MadMathLabs

One of the requests from the OpenRPG community was to structure the software with the Model, View, Controller structure. At the time I admitted I was not very familiar with the structure and that from what I *do* know of the MVC structure Pious Paladin acted ‘similar’. And it does, but it’s not exactly an MVC. I don’t need to go over the way docks and gears work again, suffice it to say gears act similar to controllers, docks act similar to views.

That is not what I doing with the map though. Remember that in OpenRPG the map has really been a glorified web page. It parses XML data and if you are not aware XHTML is a  family of XML. I’ve been peeking into MVCs because I want to do some of my own coding in Joomla! … and I feel the need to be honest. I don’t like the way Joomla! structures their MVCs. So many folders …. gah! But that didn’t stop me from learning what I can.

So where is this blog post even going? The map. After I made the massive map change that allowed massive maps to be created, I decided that I broke the software enough that it is time to restructure the map code to something more extensible. And after some though and internal pestering I decided the MVC structure would be best. Mine is probably not the most accurate MVC .. but I am strong enough to admit my failings.

If you look at the current map_gear you will see the first light of the MVC. The MapTable, MapPage, and MapGuide classes work as an MVC. And … as I’ve said via twitter a few times, I am working on the unseen / unsent policy. I thought the best way to accomplish this was to create a new MVC structure wherein there is a Controller (GameMapController), the Model (GameMap), and the views. Each layer will get it’s own view … even sublayers, and they will be based on the ViewClass class.

This is going to allow for a lot of new use later on, but most importantly the acquisition of data will be much more organized. Everytime a new person enters the room the map will build the data to send. Right now there are few restrictions, but later on I plan on having client specific data. When I think of client specific data I’m thinking of a shock horror game where everything is dark and the clients can only “see” what their miniatures can “see”.

Pretty cool, huh? What’s not cool is the volume of crap I’ve created after the map change. g_g … Sorry. I am working on that. Which is exactly what I am doing after this sentence.