It was quite amusing to listen to the organizers talk about attendee behavior because it reminded me very much of the experiences I had running the Orlando .NET user group. I guess people don't really change, regardless of geographic location :-)
Even though I've been living and breathing XNA for the last few years ... I was reminded last night of how alien a concept game development is to many very competent developers. The concepts which seemed to need the most explaining were the mathematical aspects, and state management.
>In a world of pre-packaged controls, and silverlight behaviors for animation, it seemed that a lot of people had trouble grasping the concept of storing the state, which occurs separately from update, which occurs separately from the drawing. So I started thinking about how one might explain these concepts to your average day to day business application or systems developer.
Yep, I said it ... I think Model View Controller is a valid analogy that can be used to explain the way a real time game application works. Think about it:
- Model: In XNA demos, the "model" data usually goes into private class level fields of the Game class. This data is usually textures, 3d models, effects, audio, and position data (Matrices, Vectors). The next step that most game developers take is to abstract all that stuff out into sprite, actor, or entity classes.
- Controller: The Update method acts as the controller. It takes user input, or in-game "events" such as collision and facilitates the calculation of the new state based on that information. This is classic "controller" responsibility.
- View: The Draw method is clearly a "view" upon the current state of the model. In a well factored game, there are no calculations in the view. If you're drawing 2d, you iterate over your models, request their texture and position information, and draw it with the SpriteBatch. If 3d, iterate over the models (in the MVC sense), ask them for their Models and draw that.
Although the exact expression of "MVC" is not often used in the games industry, in the strictest sense, it is still a variation on the pattern. The concept could be very helpful to speakers and trainers who are teaching XNA to the uninitiated. If they can get the crowd over that initial impedance mismatch, then they can move on to more advanced topics faster, which would surely please the group.