Smartfox Server Overall Architecture and Development Methodology
In the second of, what I hope to be, a series of posts on the topic of Smartfox, I want to talk about the overall design methodology that I have adopted and my reasoning behind it. Firstly, I would like to make this very open to comment. Please feel free to critique and / or share any of your own comments or ideas to this. Widgetizing this process and distilling it down to a series of best practices can be beneficial for the community as a whole, as has been demonstrated countless times in the open source world.
I have the privilege of working for one of the only companies (that I am aware of) in Tennessee that is actively engaged in the virtual world / fully interactive space. Early on, we evaluated several products for our latest interactive project (more details as soon as I can share them) and finally came to the conclusion that Smartfox was the most advanced at the time and, with continual improvements, could prove to be highly beneficial to work with (I can dive more into our decision here, if someone would like me to). My chief responsibility for this project is to be the technological glue that fits all of the myriad of pieces together that are required to get one of these things out the door (not to mention the development of all of our server side code in Java and site code in PHP). If you have ever been to sites like Club Penguin or Football Village, you may think that they are relatively simple applications that require little to no expertise in design and execution. This could not be further from the truth, as I have come to learn first hand. You have to be prepared to implement a solid methodology that emphasizes a large degree of transparency and communication between (ideally) design and development teams. You are required to architect an application that can scale very quickly while working within what may seem like unbelievable deadlines. This is not altogether uncommon with anything in the overall software development industry, particularly for web based applications. I would say that this is simply magnified by the complexity that is involved in your core offering (which, again, is largely a common challenge). As we began our discovery (next section), we found that there was a significant amount of complexity in some of our core requirements. With all of that said, let’s dive in to what has been implemented thus far during this project.
There was a significant amount of time spent on discovery in the first stages of development. This was mainly to draw up a working functional specification that the developers (myself and my teammates) could use to drive decisions on how a specific feature would be built and how the overall system architecture would be implemented. Furthermore, a significant amount of wire framing was down early on to, firstly, give the client an idea of what the product was going to look like and, secondly, to give our design team an idea of what they were going to be building. As an aside, I would say that before beginning any project of this magnitude, a functional specification represents the bare minimum in preparation, if you wish to be successful. Make your spec as feature complete as possible but realize that, being as agile as you can be (waterfall is for weenies), there will be changes, omissions, and additions. I decided early on that we would need a fairly beefy development server with which to test our product, so we decided on a Dell Poweredge 64-bit machine (knowing that, eventually, this would live in a managed environment).
Our feature needs and overall complexity in what we were going to accomplish (and, more importantly, the time restraints given to accomplish said features) required that we use the Smartfox extension interface to its fullest potential. I write our extensions in Java with the client side code being written by the rest of the development team in Actionscript 3 and designed by our very talented illustrators and animators in Flash CS4 (yes, we have all the new toys). I also decided to adopt an ORM in favor of the built in JDBC interface that comes, by default, with Smartfox (please see my earlier post to see how that is set up … not too terribly difficult). The main reason behind that decision was for one of code portability and readability which is, quite honestly, only a couple of reasons for choosing an ORM solution (who really wants to see SQL in their code anymore?). I, long ago, adopted Eclipse to be my IDE of choice for all of my open source projects (which mainly consists of PHP) mainly because of its support for code completion and debugging (the xdebug support really sold me … and given that its free, the irony is not lost on me in that statement). I was a long time VIM guy (and still am, to a large extent), but had to relegate myself to the realities of the world I live in which requires a good degree of productivity apart from the toys that I get to play with. Equally attractive with the Eclipse project (perhaps more so) is its support for the Java programming language. It has made development in Java a breeze allowing me to focus solely on the language semantics (and later , the Hibernate ORM) rather than the complexities of project construction (think ant vs. maven) and deployment (although a fair amount of thought was placed in that … more in a minute). Thanks to its excellent debugging tools, I was able to set up my environment (here) to debug my Java extensions real time. That, by far, has been the most indispensable tool. I chose MySQL for our database backed simply for its ubiquity and ease of use. I have a lot of experience with MySQL and am comfortable optimizing it for scalability. There are many different database products on the market today, both free and commercial. You would be right to do your research and find the product that is right for your project needs. Finally, we have a website component to the project (as is most often the case) for which PHP, Apache, and the Zend Framework (don’t hate) was chosen. We are employing a true pure LAMP stack here. I chose Centos 5 for the underlying OS mainly because that is what I am most comfortable with. Linux distribution availability and their sometimes religious following fall within the same realm of opinions and arm pits (as the old adage goes). Go with what you are comfortable with and are prepared to admin when the heat gets turned up. In keeping with the idea of continuous integration, I am employing the Xinc project to periodically run Phing scripts in the event that a change has been made to the Subversion repository (did I mention that you HAVE TO HAVE a version control system?). It is important to be able to support a simultaneous design and development workflow even down to the organization of your file system. At the same time, you don’t want to have a significant challenge in deployment. This is where Phing comes in. You can structure your packages and design files in ways that make sense for each respective team and simply write a script to bring the pieces together into a cohesive project. For example, we have a dev section in our repository. Inside there, we maintain our web, java, and as3 structures independently of one another (although, they have to play nice at some point). When the time comes to submit our new changes to the repository and we are ready for full site integration testing, Xinc will sense the change at the next build cycle and push that to where it will ultimately live in some public location that Apache can serve (of course, if you simply can’t wait, you can always run the build script manually).
This brings me to the conclusion of this particular post because as I write this, I am now realizing that there is a significant amount of information that I have left out concerning the real deep stuff that I want to talk about (mainly, the interplay between the client and server development). As a result, I am going to stop here and break the deeper stuff our into another post, or two. Please leave suggestions and / or feedback! What does your team employ to facilitate the development of your multiplayer games or interactive projects?