What happens to game enemies once they leave the screen?
This is a question that has been buzzing at my ear for about a year, and I’ve recently found an answer.
It’s one thing to create a bunch of on-screen enemies and make them interact with the player, but to make the game more challenging and enjoyable, they really ought to have their own view of the game world, independent of the player’s screen.
This means duplicating the collision detection and the scrolling engine in virtual terms, for each enemy.
For my object based game engine, there’s quite a lot of processing that needs to be done each frame just for collision detection and scrolling, so the idea of duplicating those processes for each and every enemy seemed very daunting, and I wouldn’t have approached it in AS2 at all.
Hey, AS3 is 10 times faster right, so…
2 Player Split Screen with MVC
First thing was to make a multi-view system by implementing an MVC design pattern throughout the engine. This means there’s only one World state (known as the Model), which is basically just a load of maps built from WorldObjects like platforms and obstacles. Then for each player a distinct View is created that is responsible for performing collision detection for the player and scrolling the map around the screen (or rather the screen around the map).
This wasn’t too hard to implement really, it took a weekend to rebuild the foundation of the engine, with the biggest challenge being the management of communication between the state of every WorldObject and it’s visual counterpart in the View (a WorldObjectDisplay).
Even this was quite straightforward – when an object is flagged as part of the player’s view, a WorldObjectDisplay is created with a reference to the WorldObject, then the WorldObjectDisplay adds a listener to the WorldObject and just waits for updateDisplay messages. The WorldObject knows nothing of its (any number of) displays; it just looks after it’s own business and dispatches an event when something interesting happens. Pretty easy!
With this implemented, it was just a simple case of:
var player = new Player(“P1”);
player.createView(0, 0, 400, 400); // x, y, width, height
var player2 = new Player(“P2”);
player2.createView(400, 0, 400, 400); // x, y, width, height
and hey presto there’s a split screen game:
Persistent AI with Virtual View
The hard stuff required for persistent AI is covered by having a multi-view system using MVC. All that remains is to create an AbstractView class that doesn’t have any code responsible for moving actual MovieClips around, and doesn’t bother with managing a player’s input, it just keeps a track of the position within the map and collision detection with any WorldObject’s coordinates.
Then it’s just a case of subclassing one of these virtual views for an enemy and sticking some simple A.I. into the enemy class:
These enemy worms will collide with the terrain, but they’ll be doing it virtually, and will continue to collide outside of the player’s view.
The worms don’t exist visually in their own view at all, they only exist visually when the player encounters them.
Schrodinger’s Worms yo!