

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer

What's a good architecture for Flash games? I've read that MVC is great, with symbols just used purely for views (set states, use the class to manage which state/frame to show).

I would presumably then stick all my code in one or more .AS files, use object-oriented programming, try to unit test whatever I can, and make my art and symbols purely view-state stuff with no code.

Has anyone tried this? On anything other than a small game? How do these big flash RPGs and MMORPGs architect their games?

share|improve this question
up vote 6 down vote accepted

Although MVC is a pattern that is widely used, I think it's not really appropriate for games. When developing games you'll also deal with sound, physics, networking etc. where do they belong to? Model, View or Controller?

You'll find that model and controller (sometimes even the view) are most often better combined in one class and/or that there are other patterns that are better suited for game development than MVC, for example the component pattern.

As a flash developer, I encourage you to separate your code from your assets though. If you're using an IDE like Flash Builder, there's no way around that anyways.

Also try to separate things that represent different layers of "information/logic", like sound, rendering, ai etc. to make these components reusable. You can leverage the flash event-system or use a signal-slot implementation to loosely couple these objects. Eg. The player class (or maybe even the collision-handler) dispatches a signal whenever the player collects a coin. By connecting the "collect-coin-signal" to the sound-class, the appropriate sound can be played without explicitly calling any sound-related code inside the player class. Of course this signal/event could also be connected to the keep-track-of-score-class etc. This architecture allows you to easily attach more components later on and/or swap them with different ones without rewriting huge portions of your existing code.

I think that most of the patterns commonly used for game development also apply when developing games in ActionScript. So just go ahead and look for some good game-development patterns and make use of them in your next Flash project.

Btw. I have never used Unit-Tests for a game, but maybe that's just me :)

share|improve this answer
+1 For component pattern, it makes so much sense for games! It's also hard for me to imagine unit testing games too, unless maybe you're developing a physics engine or something, making sure no whacked out values come out when you add/change something. – michael.bartnett Dec 23 '10 at 23:51
MVC works great in my games. Physics is model-layer. Sound is view layer. Networking is model layer. (Then again, I am 100% for automated testing everything that's easily testable, and MVC separates it nicely so that I only can't test the view easily.) – ashes999 Dec 24 '10 at 0:20

Look at the source code for Flixel and FlashPunk. They work similarly to XNA in that they have a main Game class which contains the setup code and maintains a state machine which will run the Update(); Render(); loop on a GameState object.

Your different "screens" (ie: Menu, Gameplay, post-gameplay high score screen, etc.) will inherit from GameState, and each has their own Update, Render loop, as well as containers of game entities such as sprites and sounds.

Flixel's method for changing states is really just a method called ChangeState() which takes the state class and creates an instance of it to use.

Here's a good XNA article that can provide a good overview of state management.

share|improve this answer
+1 FlashPunk looks awesome. Flixel is not my cup of tea, though. – ashes999 Mar 17 '11 at 15:11

Your Answer


