Let’s get started!

The Client

The client we’re going to build is a fairly primitive one. It will connect to ElectroServer, spawn a knight player avatar and display anyone else that is connected as a black wizard. As players move around the area, their position will be broadcast across all connected clients and updated appropriately.

PushButton Engine lets the developer declare which objects they’d to use via an XML file (typically referred to as a ‘level file’). For the application developers among you, it will feel a lot like some of the Inversion of Control solutions that are available today. We’ll create one file that will declare common entities that are relevant across various game states and another that represents the primary game mode.

Defining the Game

File: /ESPBEDemo-client/assets/levels/common.xml

<?xml version="1.0" encoding="utf-8"?>

<!-- Define all the entities that will be used across game modes. -->

<things version="1">

    <!-- We need a spatial manager entity component to keep track of entities
    that have a spatial component and thus require a position be set. Like our
    soon-to-be-created avatars. -->
    <entity name="spatialManager">
        <component type="com.pblabs.rendering2D.BasicSpatialManager2D" name="manager" />
    </entity>

    <!-- Create a display object scene that will do the rendering for us. -->
    <entity name="scene">
        <component type="com.pblabs.rendering2D.DisplayObjectScene" name="scene">
            <!-- Assign it a name -->
            <sceneViewName>sceneView</sceneViewName>
            <!-- and set the scene position. -->
            <position>
                <x>-400</x>
                <y>-300</y>
            </position>
        </component>
    </entity>

    <!-- Now add these two entities to a group so they can be instantiated conveniently. -->
    <group name="common">
        <objectReference name="spatialManager" />
        <objectReference name="scene" />
      </group>

</things>

We now have a spatial manager to handle the positioning of objects on the screen and a scene to render them to. Now let’s define the object we’ll need when our main game mode (or level) is loaded.

File: /ESPBEDemo-client/assets/levels/game.xml

<?xml version="1.0" encoding="utf-8"?>

<!-- Define all the objects that need to be available when this level is loaded -->
<things version="1">

    <!-- Create the player avatar. -->
    <template name="player">
        <!-- Create a sprite renderer to render the player avatar -->
        <component type="com.pblabs.rendering2D.SpriteRenderer" name="sprite">
            <!-- Tell the sprite on what scene it should be rendered.
            (The 'scene' entity we created in common.xml.) -->
            <scene entityName="scene" componentName="scene"/>
            <!-- Define the location of the image file. -->
            <fileName>../assets/images/player.png</fileName>
            <!-- Assign the layer index. -->
            <layerIndex>1</layerIndex>
            <!-- Define where this sprite should be rendered. -->
            <positionProperty>@spatial.position</positionProperty>
        </component>
        <!-- This component allows the entity to be positioned on the screen. -->
        <component type="com.pblabs.rendering2D.SimpleSpatialComponent" name="spatial">
            <!-- Make sure it knows where the spatial manager is (from common.xml). -->
            <spatialManager entityName="spatialManager" />
            <!-- And how large it should be. -->
            <size>
                <x>48</x>
                <y>48</y>
            </size>
        </component>
        <!-- Add a keyboard input component to accept user input. -->
        <component type="com.philperon.espbedemo.components.KeyboardInput" name="keyboardInput">
            <!-- Assign W, A, S and D for player movement. -->
            <inputMap childType="com.pblabs.engine.core.InputKey">
                <up>W</up>
                <down>S</down>
                <left>A</left>
                <right>D</right>
            </inputMap>
        </component>
        <!-- Add a controller component to deal with how user input should be handled. -->
        <component type="com.philperon.espbedemo.components.PlayerController" name="controller">
            <keyboardInput componentName="keyboardInput" />
            <spatial componentName="spatial" />
        </component>
    </template>

    <!-- Create the opponent avatar. -->
    <template name="opponent">
        <!-- Similar setup to that shown above. -->
        <component type="com.pblabs.rendering2D.SpriteRenderer" name="sprite">
            <scene entityName="scene" componentName="scene"/>
            <fileName>../assets/images/opponent.png</fileName>
            <layerIndex>1</layerIndex>
            <positionProperty>@mover.position</positionProperty>
        </component>
        <!-- Add a component to handle interpolated movement based on position
        updates from the server. -->
        <component type="com.pblabs.rendering2D.Interpolated2DMoverComponent" name="mover">
            <!-- How many degrees should be of the goal position before movement begins. -->
            <movementHeadingThreshold>360</movementHeadingThreshold>
            <!-- Assign the spatial manager. -->
            <spatialManager entityName="spatialManager" />
            <!-- Tweak the movement speed slightly to give it a more natural look. -->
            <nudge>1.2</nudge>
            <!-- Like the player avatar, define the size. -->
            <size>
                <x>48</x>
                <y>48</y>
            </size>
        </component>
    </template>

</things>

The game.xml file really starts to illustrate how powerful PushButton Engine can be once you wrap your head around a composition-style architecture. By writing small components that have a single primary duty, you can reuse them again and again in an unlimited number of entities. Game assembly then becomes a simple matter of defining the “recipe” that makes your game unique. It also opens up opportunities for game designers to have a hand in game development with only a limited knowledge of ActionScript.

Another group of items being referenced are the actual assets themselves. For this demonstration this includes the .xml level files and .png game graphics. We’ll place these in a group so they can be embedded and easily handled when the game initializes.

File: /ESPBEDemo-client/src/com/philperon/espbedemo/Resources.as

package com.philperon.espbedemo
{
    import com.pblabs.engine.PBE;
    import com.pblabs.engine.resource.ImageResource;
    import com.pblabs.engine.resource.ResourceBundle;
    import com.pblabs.engine.resource.XMLResource;

    import flash.display.Bitmap;
    import flash.utils.ByteArray;

    // Create a new resouce bundle to handle loading and registering
    // embedded resources.
    public class Resources extends ResourceBundle
    {
        // Add the level files we'll need.
        [Embed(source="../assets/levels/common.xml", mimeType="application/octet-stream")]
        public var Common:Class;

        [Embed(source="../assets/levels/game.xml", mimeType="application/octet-stream")]
        public var Game:Class;

        // And the graphics used to represent the game.
        [Embed(source="../assets/images/background.png")]
        public var BackgroundPNG:Class;

        [Embed(source="../assets/images/player.png")]
        public var PlayerPNG:Class;

        [Embed(source="../assets/images/opponent.png")]
        public var OpponentPNG:Class;

        public function Resources()
        {
            // When this class is instantiated, tell the resource manager to register the resources listed above.
            PBE.resourceManager.registerEmbeddedResource("../assets/levels/common.xml", XMLResource, new Common() as ByteArray);
            PBE.resourceManager.registerEmbeddedResource("../assets/levels/game.xml", XMLResource, new Game() as ByteArray);
            PBE.resourceManager.registerEmbeddedResource("../assets/images/background.png", ImageResource, new BackgroundPNG() as Bitmap);
            PBE.resourceManager.registerEmbeddedResource("../assets/images/player.png", ImageResource, new PlayerPNG() as Bitmap);
            PBE.resourceManager.registerEmbeddedResource("../assets/images/opponent.png", ImageResource, new OpponentPNG() as Bitmap);
        }
    }
}

Now we have all the assets we’ll need to display our game. It’s time to start filling in some of the actual game logic that typically resides inside components. If you recall, we referenced a component to handle keyboard input and another to deal with how that input should be handled. Let’s start with our KeyboardInput component.

File: /ESPBEDemo-client/src/com/philperon/espbedemo/components/KeyboardInput.as

package com.philperon.espbedemo.components
{
    import com.pblabs.engine.core.InputMap;
    import com.pblabs.engine.entity.EntityComponent;

    // A component that handles keyboard input!
    public class KeyboardInput extends EntityComponent
    {
        // Define some variables to store keyboard input values.
        public var up:Number = 0.0;
        public var down:Number = 0.0;
        public var left:Number = 0.0;
        public var right:Number = 0.0;

        // getter and setter for the InputMap class that does the
        // real work here.
        public function get inputMap():InputMap
        {
            return _inputMap;
        }

        public function set inputMap(map:InputMap):void
        {
            // Store the input map in a private variable...
            _inputMap = map;

            // ...and map the actions we defined in game.xml to
            // the handlers.
            if (_inputMap != null)
            {
                _inputMap.mapActionToHandler("up", upHandler);
                _inputMap.mapActionToHandler("down", downHandler);
                _inputMap.mapActionToHandler("left", leftHandler);
                _inputMap.mapActionToHandler("right", rightHandler);
            }
        }

        // Finally, set up the handlers themselves.
        private function upHandler(value:Number):void
        {
            up = value;
        }

        private function downHandler(value:Number):void
        {
            down = value;
        }

        private function leftHandler(value:Number):void
        {
            left = value;
        }

        private function rightHandler(value:Number):void
        {
            right = value;
        }

        private var _inputMap:InputMap;
    }
}

The game can now respond to keyboard input. We’re getting close to the core of our demo but need some way to ensure all these great resources make it on to the display list. For this purpose, we’ll use a subclass of BaseScreen that will be registered with a screen manager once we dive into the main game class.

File: /ESPBEDemo-client/src/com/philperon/espbedemo/GameScreen.as

package com.philperon.espbedemo
{
    import com.pblabs.engine.PBE;
    import com.pblabs.engine.debug.Logger;
    import com.pblabs.engine.resource.ImageResource;
    import com.pblabs.rendering2D.ui.SceneView;
    import com.pblabs.screens.BaseScreen;

    // Create a new screen class that will be registered with the
    // screen manager.
    public class GameScreen extends BaseScreen
    {
        // Declare a scene variable so we have something to actually
        // draw to.
        public var sceneView:SceneView;

        public function GameScreen()
        {
            super();

            // Create the scene view to match the same size as the .swf
            // and add to the display list.
            sceneView = new SceneView();
            sceneView.name = "sceneView";
            sceneView.width = 800;
            sceneView.height = 600;
            addChild(sceneView);

            // Request that a background image be loaded on to the screen.
            // Pass in handlers to deal with a success or failure.
            PBE.resourceManager.load("../assets/images/background.png", ImageResource, imageLoadSuccessHandler, imageLoadFailedHandler);
        }

        // Once the image is loaded, send the bitmap data into a fill on
        // the Graphics instance of this display object.
        private function imageLoadSuccessHandler(imageResource:ImageResource):void
        {
            cacheAsBitmap = true;
            graphics.clear();
            graphics.beginBitmapFill(imageResource.image.bitmapData);
            graphics.drawRect(0, 0, imageResource.image.bitmapData.width, imageResource.image.bitmapData.height);
            graphics.endFill();
        }

        private function imageLoadFailedHandler(imageResource:ImageResource):void
        {
            Logger.print(this, "Failed to load image '" + imageResource.filename + "'");
        }
    }
}

We’re getting close. It’s time to wire up the PlayerController we added to the player entity in the game.xml file. This will contain all the logic needed to control the player’s avatar including sending the position updates to ElectroServer. Here we go…

File: /ESPBEDemo-client/src/com/philperon/espbedemo/components/PlayerController.as

package com.philperon.espbedemo.components
{
    import com.electrotank.electroserver4.ElectroServer;
    import com.electrotank.electroserver4.esobject.EsObject;
    import com.electrotank.electroserver4.message.request.PluginRequest;
    import com.pblabs.engine.PBE;
    import com.pblabs.engine.components.TickedComponent;
    import com.pblabs.rendering2D.SimpleSpatialComponent;

    import flash.geom.Point;

    // This represents the core logic for a player avatar.
    // It extends TickedComponent so we have access to game ticks.
    public class PlayerController extends TickedComponent
    {
        // Set how fast we'd like the player to move.
        public static const SPEED:uint = 100;

        // Declare a variable to hold the ElectroServer connection.
        public var connection:ElectroServer;
        // Make sure the player knows the current room and zone ids.
        public var currentRoomID:Number;
        public var currentZoneID:Number;
        // Create a handle to the KeyboardInput component we just created.
        public var keyboardInput:KeyboardInput;
        // As mentioned earlier, the spatial component manages position.
        public var spatial:SimpleSpatialComponent;
        // And of course, every player has a name.
        public var username:String;

        // The position buffer will ensure we're not sending updates if
        // the player hasn't moved.
        private var _positionBuffer:Point = new Point();

        public function PlayerController()
        {
            super();
        }

        // The onTick method that gets called every game tick.
        override public function onTick(deltaTime:Number):void
        {
            // Set the x and y velocity based on the keyboard input registered
            // from the KeyboardInput component.
            spatial.velocity.x = (keyboardInput.right - keyboardInput.left) * PlayerController.SPEED;
            spatial.velocity.y = (keyboardInput.down - keyboardInput.up) * PlayerController.SPEED;

            // Bounds check the player's movement. (Ideally, this would also be
            // enforced on the server but I'm trying to keep things as
            // simple as possible.)
            if(spatial.position.x < 0 && spatial.velocity.x < 0 ||
                spatial.position.x > 800 && spatial.velocity.x > 0)
                spatial.velocity.x = 0;

            if(spatial.position.y < 0 && spatial.velocity.y < 0 ||
                spatial.position.y > 600 && spatial.velocity.y > 0)
                spatial.velocity.y = 0;
        }

        // This fires when this component is added to an entity.
        override protected function onAdd():void
        {
            super.onAdd();
            // Schedule a position update task with the process manager.
            PBE.processManager.schedule(200, this, sendPosition);
        }

        // The function that's called when the task we just scheduled is due.
        public function sendPosition():void
        {
            // Check to make sure we've actually moved.
            if((spatial.x != _positionBuffer.x) || (spatial.y != _positionBuffer.y))
            {
                // If we have moved, create a new request to be sent back to the server
                var pr:PluginRequest = new PluginRequest();
                // Set the plugin name as well as the room and zone id
                // that we created in Part 1 of this tutorial.
                pr.setPluginName("GamePlugin");
                pr.setRoomId(currentRoomID);
                pr.setZoneId(currentZoneID);

                // Create an EsObject that will act as our message payload.
                var pos:EsObject = new EsObject();
                // Set the opcode (also found in Part 1)
                pos.setInteger("opcode", ESPBEDemo.STATE_UPDATE);
                // Make sure the server knows who it's coming from...
                pos.setString("name", username);
                // ...and what we're changing.
                pos.setNumber("x", spatial.x);
                pos.setNumber("y", spatial.y);
                // Add the payload to our plugin request.
                pr.setEsObject(pos);
                // Now send it on it's way.
                connection.send(pr);                

                // Push our current position into the buffer.
                _positionBuffer.x = spatial.x;
                _positionBuffer.y = spatial.y;
            }
            // Finally, schedule this task to run again.
            PBE.processManager.schedule(200, this, sendPosition);
        }
    }
}

All the support classes are finished. Now to focus on the main game class that will set up the server connection and start our client.

A Series of Events

Much of what we’ll be looking at within our main game class is driven by events. Both PushButton Engine and the ElectroServer AS3 API expose events that help you drive your game logic. For a large project you may not want to bundle all your handlers in one place, but we do so here to make it easier to follow how the logic flows from game initialization, server connection and finally gameplay.

File: /ESPBEDemo-client/src/ESPBEDemo.as

package
{
    import com.electrotank.electroserver4.ElectroServer;
    import com.electrotank.electroserver4.entities.Protocol;
    import com.electrotank.electroserver4.entities.SearchCriteria;
    import com.electrotank.electroserver4.entities.UserVariable;
    import com.electrotank.electroserver4.esobject.EsObject;
    import com.electrotank.electroserver4.message.MessageType;
    import com.electrotank.electroserver4.message.event.ConnectionEvent;
    import com.electrotank.electroserver4.message.event.PluginMessageEvent;
    import com.electrotank.electroserver4.message.request.LoginRequest;
    import com.electrotank.electroserver4.message.request.PluginRequest;
    import com.electrotank.electroserver4.message.request.QuickJoinGameRequest;
    import com.electrotank.electroserver4.message.response.CreateOrJoinGameResponse;
    import com.electrotank.electroserver4.message.response.LoginResponse;
    import com.pblabs.engine.PBE;
    import com.pblabs.engine.core.TemplateManager;
    import com.pblabs.engine.entity.IEntity;
    import com.pblabs.engine.entity.PropertyReference;
    import com.pblabs.rendering2D.*;
    import com.pblabs.rendering2D.spritesheet.SpriteSheetComponent;
    import com.philperon.espbedemo.*;
    import com.philperon.espbedemo.components.*;

    import flash.display.Sprite;
    import flash.display.StageScaleMode;
    import flash.events.Event;
    import flash.geom.Point;

    // Set up our swf configuration
    [SWF(width="800", height="600", frameRate="60", backgroundColor="0x000000")]
    public class ESPBEDemo extends Sprite
    {
        // Define our game protocol here. This reflects the same values we set in
        // part one.
        public static const PLAYER_INIT:int = 1;
        public static const OPPONENT_ENTERED:int = 2;
        public static const STATE_UPDATE:int = 3;
        public static const PLAYER_LEFT:int = 4;

        // declare variable for the ElectroServer connection.
        private var _es:ElectroServer;
        // The room and zone ids.
        private var _roomID:Number = -1;
        private var _zoneID:Number = -1;
        // General properties on users.
        private var _userProps:EsObject;
        // The player name
        private var _name:String;
        // And a collection to hold opponents objects.
        private var _opponents:Object = {};
        // This will hold the type of game we're assigned to.
        private var _gameType:String;

        public function ESPBEDemo()
        {
            // Set the scale mode.
            stage.scaleMode = StageScaleMode.SHOW_ALL;

            // Register classes that we reference in our level files here.
            // This is so the compiler knows to include them.
            PBE.registerType(DisplayObjectRenderer);
            PBE.registerType(DisplayObjectScene);
            PBE.registerType(Interpolated2DMoverComponent);
            PBE.registerType(SimpleSpatialComponent);
            PBE.registerType(SpriteSheetComponent);
            PBE.registerType(SpriteRenderer);
            PBE.registerType(PlayerController);
            PBE.registerType(KeyboardInput);

            // Start PushButton Engine.
            PBE.startup(this);

            // Add our resources.
            PBE.addResources(new Resources());

            // And register the game screen we created earlier.
            PBE.screenManager.registerScreen("game", new GameScreen());

            // Set up a loaded handler so that we know when our common.xml file is ready to go.
            PBE.templateManager.addEventListener(TemplateManager.LOADED_EVENT, loadedHandler);
            PBE.templateManager.loadFile("../assets/levels/common.xml");
        }

        // The loadedHandler fires once the common.xml level file is loaded.
        private function loadedHandler(event:Event):void
        {
            // Clean up the listener.
            PBE.templateManager.removeEventListener(TemplateManager.LOADED_EVENT, loadedHandler);

            // Instantiate the "common" group we defined in common.xml. This ensures
            // the spatial manager and scene are ready and available.
            PBE.templateManager.instantiateGroup("common");

            // Now it's time to start the ElectroServer connection process.
            _es = new ElectroServer();
            // Set the protocol to binary for best performance.
            _es.setProtocol(Protocol.BINARY);
            // Wire up our listeners for connection...
            _es.addEventListener(MessageType.ConnectionEvent, "onConnectionEvent", this);
            // ...login response...
            _es.addEventListener(MessageType.LoginResponse, "onLoginResponse", this);
            // ...game joins...
            _es.addEventListener(MessageType.CreateOrJoinGameResponse, "onCreateOrJoinGameResponse", this);
            // ...and finally, general plugin messages.
            _es.addEventListener(MessageType.PluginMessageEvent, "onPluginMessageEvent", this);
            // Now, create the connection to the server.
            //(This assumes you're running the server locally.)
            _es.createConnection("127.0.0.1", 9899);
        }

        // Handle the connection response from the server.
        public function onConnectionEvent(event:ConnectionEvent):void
        {
            // If the connection is accepted...
            if (event.getAccepted()) {
                // ...generate a user name.
                _name = "user"+Math.round(10000*Math.random());
                // Create and send a login request to the server.
                var loginRequest:LoginRequest = new LoginRequest();
                loginRequest.setUserName(_name);
                _es.send(loginRequest);
            // Otherwise, throw an error.
            } else {
                throw new Error("Connection failed: " + event.getEsError().getDescription());
            }
        }

        // This handles our login response from the server.
        public function onLoginResponse(event:LoginResponse):void
        {
            // Create a new search criteria instance. This is used
            // inside a join game request below.
            var criteria:SearchCriteria = new SearchCriteria();
            // Set the game type to match the name we defined in part one of the tutorial.
            criteria.setGameType("game");

            // Grab the first user variable sent from the server.
            var uservar:UserVariable = event.getUserVariables()[0];
            // Extract the EsObject value from the user variable.
            var esobj:EsObject = uservar.getValue();
            // Make sure we're looking at "gameType".
            if(esobj.doesPropertyExist("gameType"))
            {
                // ElectroServer 4 is not yet capable of adding a player to a game automatically
                // so we'll request it from the client side.
                //
                // Grab the game type.
                var mode:String = esobj.getString("gameType");
                // And create a new join game request.
                var request:QuickJoinGameRequest = new QuickJoinGameRequest();
                // Set the game type we just grabbed.
                request.setGameType(mode);
                // As well as the zone name.
                request.setZoneName(mode + "Zone");
                // Finally, set the criteria and send the request back to the server.
                request.setSearchCriteria(criteria);
                _es.send(request);
            }
        }

        // When a game request response arrives from the server, enter this handler.
        public function onCreateOrJoinGameResponse(event:CreateOrJoinGameResponse):void
        {
            // Check to see if we've successfully joined.
            if(event.getSuccessful() == true)
            {
                // Make sure we have a "type".
                if(event.getGameDetails().doesPropertyExist("type"))
                {
                    // And set that here.
                    _gameType = event.getGameDetails().getString("type");

                    // Store a local reference to the room and zone id.
                    _roomID = event.getRoomId();
                    _zoneID = event.getZoneId();

                    // Tack a listener on to the TemplateManager to notify us when the next file is loaded.
                    PBE.templateManager.addEventListener(TemplateManager.LOADED_EVENT, gameLoadedHandler);
                    // Request that our game.xml file that defines our game is loaded.
                    PBE.templateManager.loadFile("../assets/levels/" + _gameType + ".xml");
                }
            }
            // Otherwise, throw an error.
            else
            {
                throw new Error("Could not join game: " + event.getEsError().getDescription());
            }
        }

        // Jump in this handler once we've loaded our client game assets and are ready to begin.
        private function gameLoadedHandler(event:Event):void
        {
            // Head off to the screen we registered above in the constructor.
            PBE.screenManager.goto(_gameType);

            // Grab the player EsObject that was stored in the _userProps variable. (We'll find
            // out how _userProps got defined below.)
            var player:EsObject = _userProps.getEsObject("player");
            // And get the initial x and y location of the player. We do this now because
            // we finally are able to do something about it; Render it on-screen.
            var spawnPoint:Point = new Point(player.getNumber("x"), player.getNumber("y"));
            // Create a list of opponents that are already in-game.
            var opponentList:Array = _userProps.getEsObjectArray("playerlist");

            // Iterate over each opponent in the list.
            for(var i:uint = 0; i < opponentList.length; i++)
            {
                // Access each opponent EsObject
                var oppObj:EsObject = EsObject(opponentList[i]);
                // Get it's name.
                var name:String = oppObj.getString("name");
                // And if the name exists...
                if(name != _name)
                {
                    // ...extract the current position...
                    var p:Point = new Point(oppObj.getNumber("x"), oppObj.getNumber("y"));
                    // ...and request that a new opponent avatar be spawned.
                    spawnOpponent(name, p);
                }
            }

            // Finally, don't forget to spawn the player's avatar.
            spawnPlayer(spawnPoint);
        }

        // Define what happens when an opponent avatar is created.
        private function spawnOpponent(name:String, spawnPoint:Point):void
        {
            // Based on the name, create a new entity passing in all the parameters
            // it needs to work properly.
            //
            // "opponent" is the name we gave to the template in game.xml. The "@" symbols
            // mean we're accessing a component of the entity template.
            _opponents[name] = PBE.makeEntity("opponent", {
                "@mover.initialPosition":spawnPoint,
                "@mover.translationSpeed":100,
                "@controller.currentRoomID":_roomID,
                "@controller.currentZoneID":_zoneID,
                "@controller.username":name
            });
        }

        // Define what happens when a player avatar is created.
        private function spawnPlayer(spawnPoint:Point):void
        {
            // As mentioned above, create a new entity based on the "player"
            // template we defined in game.xml.
            PBE.makeEntity("player", {
                "@spatial.position":spawnPoint,
                "@controller.connection":_es,
                "@controller.currentRoomID":_roomID,
                "@controller.currentZoneID":_zoneID,
                "@controller.username":_name
            });
        }

        // Define a handler to deal with messages coming in from the plugin.
        public function onPluginMessageEvent(event:PluginMessageEvent):void
        {
            // Get the EsObject from the event object.
            var eso:EsObject = event.getEsObject();
            // Grab the opcode.
            var opcode:int = eso.getInteger("opcode");
            // Set up some shared variables.
            var player:EsObject;
            var name:String = "";

            // switch over the opcode being passed in.
            switch(opcode)
            {
                // When the player was first logged in, we received this message
                // from the server. If you were wondering, this is how _userProps
                // was defined.
                case PLAYER_INIT:
                    _userProps = eso;
                    break;
                // Each time an opponent enters, grab the player object and name and
                // spawn a new opponent avatar.
                case OPPONENT_ENTERED:
                    player = eso.getEsObject("player");
                    name = player.getString("name");
                    if(name != _name)
                        spawnOpponent(name, new Point(player.getNumber("x"), player.getNumber("y")));
                    break;
                // The only state updates we're handling in this demo are position updates.
                // When they arrive, move the corresponding opponent.
                case STATE_UPDATE:
                    name = eso.getString("name");
                    if(name != _name)
                        moveOpponent(name, eso.getNumber("x"), eso.getNumber("y"));
                    break;
                // When a player leaves, request that they be removed from the game.
                case PLAYER_LEFT:
                    name = eso.getString("name");
                    removePlayerFromList(name);
                    break;
                // Die if we don't recognize an opcode.
                default:
                    throw new Error("Unknown opcode: " + opcode);
            }
        }

        // Defines what takes place when the server tells us a player has left.
        private function removePlayerFromList(name:String):void
        {
            // Grab the entity reference to the player...
            var player:IEntity = _opponents[name];
            // ...and destroy it.
            player.destroy();
            // Finally, remove it from the collection.
            delete _opponents[name];
        }

        // Handles moving the opponent avatar on the screen.
        private function moveOpponent(username:String, moveX:Number, moveY:Number):void
        {
            // Grab the entity reference.
            var entity:IEntity = _opponents[username];
            // If it's not null, set a new goal position for the interpolated mover component.
            if(entity != null)
            {
                entity.setProperty(new PropertyReference("@mover.goalPosition"), new Point(moveX, moveY));
            }
        }
    }
}

That’s it! Make sure the server is started and fire up your newly created client. Click inside the swf and remember to use W, A, S and D (or whatever you chose to set inside the KeyboardInput component) and watch your avatar move. Now open up another browser window and point to the same location to see what happens when another client connects. You may want to play a bit with the “nudge” property of the Interpolated2DMoverComponent to get it feeling right but regardless, you’re off and running!

Next Steps

We covered a lot of ground in this tutorial and you may be wondering what the heck to do next. If you struggled a bit with some of the server-side stuff we covered in part one, I’d head over to the ElectroServer forums or wiki and start looking at some of the great tutorials and references they’ve set up there. If you’d like to dive deeper into PushButton Engine, the forums are an excellent place to start learning as well as the docs and awesome IRC channel, #pbengine. Finally, if you’re ready to dig deeper into the world of multiplayer games, I’d urge you to start looking at some pieces that will be integral once you begin creating a production-grade system. Check out articles and tutorials for things like clock/time synchronization, dead reckoning, area of interest management, object state distribution and persistence. If you’re feeling especially brave, check out how we handle custom game protocol management using the Gliese Framework for RedDwarf

If you’ve come this far, thank you. I appreciate your time and your visit. Now go make a great game!

You can download the source code covered in this post here.

When deciding on which server technology to use it’s quite a different story. The list of viable options is much shorter. Scalability, maintainability, extensibility and price all come to mind when shopping around for the right product. The RedDwarf server (formerly Project Darkstar) is tempting due to it’s cost (free) but developers who are interested in simply writing their game code may become discouraged due to it’s steep learning curve. Enter, ElectroServer. When I recently started exploring ElectroTank’s flagship product, I was hooked on it’s highly-polished API and how dead-simple it was to get up and running. Couple that experience with it’s potential to scale to hundreds of thousands of simultaneous users and it’s difficult to find a better option.

Goals

The goal of this tutorial is not to have you up and running with a full-blown, ready to ship product. Instead, the focus is on just how little you have to do to get something started. I hope it will help illustrate how powerful the combination of PushButton Engine and ElectroServer can be. Although introductory in nature, I believe you’ll see the incredible value merging these two great technologies can provide.

Prerequisites

I’m assuming you’re comfortable moving around an IDE or text editor, have some fairly advanced ActionScript skills, some Java experience and generally aren’t afraid to get your hands dirty. If you’ve never used ElectroServer or PushButton Engine, I would urge you at least check out their respective starter lessons to get you up to speed.

The Server

Before a client application can start a game, it needs something to connect to. ElectroServer is built on a plugin architecture which allows developers to easily extend it’s core functionality. Plugins can be scoped to the server, a room or a player. In this example, we’ll focus on server initialization, user login and finally the game logic itself. Let’s start digging into some code!

Initialization

Our first plugin is scoped to the server and is in charge of configuring the primary game plugin.

File: /ESPBEDemo-server/src/com/philperon/espbedemo/plugins/InitPlugin.java

package com.philperon.espbedemo.plugins;

import com.electrotank.electroserver4.extensions.Plugin;
import com.electrotank.electroserver4.extensions.PluginLifeCycle;
import com.electrotank.electroserver4.extensions.api.PluginApi;
import com.electrotank.electroserver4.extensions.api.value.EsObject;
import com.electrotank.electroserver4.extensions.api.value.EsObjectRO;
import com.electrotank.electroserver4.extensions.api.value.ExtensionComponentConfiguration;
import com.electrotank.electroserver4.extensions.api.value.GameConfiguration;
import com.electrotank.electroserver4.extensions.api.value.RoomConfiguration;

// This is the plugin that gets everything started.
public class InitPlugin implements Plugin, PluginLifeCycle {

    // Define a private handle to the plugin api (used in the getter/setter below)
    private PluginApi api;

    // init is called when the object based on this class is instantiated.
    @Override
    public void init(EsObjectRO esObj) {

        // Create the plugin variable that will contain the plugin.
        ExtensionComponentConfiguration plugin = new ExtensionComponentConfiguration();

        // Define which extension the plugin will be associated with.
        plugin.setExtensionName("ESPBEDemo");
        // Set the handle which is how the plugin will be accessed when instantiated in a room.
        plugin.setHandle("GamePlugin");
        // Set the name that will be used to label this plugin in the Extension.xml file.
        plugin.setName("GamePlugin");

        // Create the room configuration for the room that will host the plugin.
        RoomConfiguration roomConfig = new RoomConfiguration();
        // Set the user connection limit.
        roomConfig.setCapacity(25);
        // Now add the plugin to the room configuration.
        roomConfig.addPlugin(plugin);

        // Create an ElectroServer object that will contain extra details that should be relayed to the user.
        EsObject gameDetails = new EsObject();
        // Set the type so that the client knows how to request access after it connects.
        gameDetails.setString("type", "game");

        // Create a new game configuration instance.
        GameConfiguration gameConfig = new GameConfiguration();
        // Add the game details.
        gameConfig.setInitialGameDetails(gameDetails);
        // Add the room configuration we defined above to the game config object.
        gameConfig.setRoomConfiguration(roomConfig);
        // We're not interested in listening for room list updates in this demonstration...
        gameConfig.setReceivingRoomListUpdates(false);
        // ...or room variable updates.
        gameConfig.setReceivingRoomVariableUpdates(false);
        // Make sure we receive user list updates...
        gameConfig.setReceivingUserListUpdates(true);
        // ...as well as user variable updates.
        gameConfig.setReceivingUserVariableUpdates(true);
        // We're not interested in video events.
        gameConfig.setReceivingVideoEvents(false);
        // Finally, register our "game" using the game configuration object we just created.
        getApi().registerGameConfiguration("game", gameConfig);
    }

    @Override
    public PluginApi getApi() {
        return api;
    }

    @Override
    public void setApi(PluginApi api) {
        this.api = api;
    }

    @Override
    public void destroy() {
        // Clean up any loose ends.
    }

}

That wraps up the initialization process. Before jumping into the game plugin, we’ll need to think about how user logins are handled.

Accepting User Logins

Event Handlers are another way the ElectroServer API allows you to extend functionality. At this point, the server is aware of the game plugin but we need some way to send this information to a connected client. This is where the LoginEventHandler comes into play.

File: /ESPBEDemo-server/src/com/philperon/espbedemo/handlers/LoginEventHandler.java

package com.philperon.espbedemo.handlers;

import com.electrotank.electroserver4.extensions.BaseLoginEventHandler;
import com.electrotank.electroserver4.extensions.ChainAction;
import com.electrotank.electroserver4.extensions.LoginContext;
import com.electrotank.electroserver4.extensions.api.value.EsObject;

// Like the other event handlers, there are base classes you extend to get started quickly.
public class LoginEventHandler extends BaseLoginEventHandler {

    // This method fires after a player logs in.
    public ChainAction executeLogin(LoginContext login) {

        // Create a new EsObject to hold values that will soon be passed to the client.
        EsObject uservars = new EsObject();

        // Set a gameType value to the name of our plugin, "game".
        uservars.setString("gameType", "game");

        // Add the user variables to the login context.
        login.addUserVariable("uservars", uservars);

        // And let the server know that all is well.
        return ChainAction.OkAndContinue;
    }
}

Now, any time a user logs in, they will be sent the information they need to request access to the game. Ideally, the server would insert a player automatically but because that functionality is not yet available in the current version of ElectroServer, we’ll deal with that later on in the client code.

Writing the Game Plugin

Now to our server-side game code! The objective here is to listen for various player action events such as entering and exiting the game as well as moving around the game world.

File: /ESPBEDemo-server/src/com/philperon/espbedemo/plugins/GamePlugin.java

package com.philperon.espbedemo.plugins;

import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;

import com.electrotank.electroserver4.extensions.BasePlugin;
import com.electrotank.electroserver4.extensions.ChainAction;
import com.electrotank.electroserver4.extensions.api.value.EsObject;
import com.electrotank.electroserver4.extensions.api.value.EsObjectRO;
import com.electrotank.electroserver4.extensions.api.value.UserEnterContext;

// Extend the BasePlugin class to take advantage of the user events it exposes.
public class GamePlugin extends BasePlugin {

    // Define our game protocol...
    // Player enters
    private static final int PLAYER_INIT = 1;
    // Opponent enters
    private static final int OPPONENT_ENTERED = 2;
    // Player state changes
    private static final int STATE_UPDATE = 3;
    // Player leaves
    private static final int PLAYER_LEFT = 4;

    // Create a thread-safe map to store players currently in-game.
    private ConcurrentMap<String,EsObject> playerMap = new ConcurrentHashMap<String,EsObject>(25);

    // When the game initializes, turn on message queueing.
    @Override
    public void init(EsObjectRO esObj) {
        // This will send packaged messages five times per second.
        getApi().startQueue(200);
    }

    // Define what happens when a player enters the game.
    @Override
    public ChainAction userEnter(UserEnterContext context) {

        // Grab the user's name.
        String name = context.getUserName();

        // Create a new EsObject that will represent a player.
        // We're only concerned with their name and position in this demonstration.
        EsObject player = new EsObject();
        // Add their name.
        player.setString("name", name);
        // And their starting position.
        player.setNumber("x", 400);
        player.setNumber("y", 300);

        // Add the player to the room's player map.
        playerMap.put(name, player);

        // Create a EsObject to represent a new player message.
        EsObject uservars = new EsObject();
        // Add the opcode that represents a new player being initialized.
        uservars.setInteger("opcode", PLAYER_INIT);
        // Add the player object defined above.
        uservars.setEsObject("player", player);
        // Send the player list along so opponents can be properly rendered on the client.
        uservars.setEsObjectArray("playerlist", (EsObject[]) playerMap.values().toArray(new EsObject[playerMap.size()]));
        // And send the message privately to the user.
        getApi().sendPluginMessageToUser(context.getUserName(), uservars);

        // Now, define another player object for others to process.
        EsObject userObj = new EsObject();
        // Add the opcode for new opponents entering.
        userObj.setInteger("opcode", OPPONENT_ENTERED);
        // Add the player object.
        userObj.setEsObject("player", player);
        // And send the message to everyone in the room.
        getApi().sendPluginMessageToRoom(getApi().getZoneId(), getApi().getRoomId(), userObj);

        return ChainAction.OkAndContinue;
    }

    // Define what happens when a player leaves the game.
    @Override
    public void userExit(String name) {
        // Create a new message object.
        EsObject eso = new EsObject();
        // Add the opcode that represents a player leaving.
        eso.setInteger("opcode", PLAYER_LEFT);
        // Remove the player from the player map and add the name to the message.
        eso.setString("name", playerMap.remove(name).getString("name"));
        // Now, send the message to the room notifying everyone that the player has left.
        getApi().sendPluginMessageToRoom(getApi().getZoneId(), getApi().getRoomId(), eso);
    }

    // Define what happens when a player sends a message to the room.
    @Override
    public void request(String userName, EsObjectRO requestParameters) {
        // If the user's message carries an opcode, process it.
        if(requestParameters.variableExists("opcode")) {
            // If the opcode represents a state update, update it here.
            if(requestParameters.getInteger("opcode") == STATE_UPDATE) {
                // Grab a handle of the player from the player map using it's name as a key.
                EsObject player = playerMap.get(userName);
                // And set it's new position.
                player.setNumber("x", requestParameters.getNumber("x"));
                player.setNumber("y", requestParameters.getNumber("y"));
            }
            // Finally, add the state update message to the message queue to be sent to
            // everyone in the room during the next 200ms cycle.
            getApi().sendQueuedPluginMessageToRoom(userName, requestParameters);
        }
    }

    // Clean up if and when the game plugin (room) is removed.
    @Override
    public void destroy() {
        getApi().stopQueue();
    }
}

A quick note regarding message queueing. Due to limitations of the Flash Player and general good practice when designing a multi-player game, you don’t want to send a high number of messages per second. By wrapping up various messages per packet, the Flash Player remains happy and you still have enough information to render other players on the client adequately enough. I suggest 200 milliseconds per package here, but others might say that between 250 and 500 milliseconds is enough for anything outside a fast-twitch, action game. It really depends on your situation.

Deployment

Deploying a new ElectroServer is a snap. Simply define an extension.xml file, drop the relevant files in the server’s extension folder, restart the server and activate them. The Extension.xml file for this demonstration looks like this.

File: /ESPBEDemo-server/src/extension.xml

<?xml version="1.0" encoding="utf-8" ?>
<Extension>

    <!-- The name of our extension -->
    <Name>ESPBEDemo</Name>

    <!-- Define all event handlers here. -->
    <EventHandlers>
        <LoginHandlers>

            <!-- Our login handler goes here. -->
            <LoginHandler>

                <!-- Define the name of the handle that will be used to access it -->
                <Handle>LoginEventHandler</Handle>

                <!-- Define the type. We've been using Java but ActionScript 1 is also an option -->
                <Type>Java</Type>

                <!-- Set the path to the actual login event handler class. -->
                <Path>com.philperon.espbedemo.handlers.LoginEventHandler</Path>

                </LoginHandler>
        </LoginHandlers>
    </EventHandlers>

    <!-- Define all plugins here -->
    <Plugins>

        <!-- First, the initialization plugin -->
        <Plugin>
            <Handle>InitPlugin</Handle>
            <Type>Java</Type>
            <Path>com.philperon.espbedemo.plugins.InitPlugin</Path>
        </Plugin>

        <!-- And then the game plugin -->
        <Plugin>
            <Handle>GamePlugin</Handle>
            <Type>Java</Type>
            <Path>com.philperon.espbedemo.plugins.GamePlugin</Path>
        </Plugin>

</Plugins>
</Extension>

Create two directories in [your electroserver install directory]/server/extenstions/ called, “ESPBEDemo” and “classes”. Copy the extension.xml file to the root of that directory and move the fully pathed .class files from your java project folder inside “classes”. When you’re finished you should have a structure that looks like this:

$EXTENSION_DIR/ESPBEDemo/extension.xml
$EXTENSION_DIR/ESPBEDemo/classes/com/philperon/espbedemo/handlers/LoginEventHandler.class
$EXTENSION_DIR/ESPBEDemo/classes/com/philperon/espbedemo/plugins/InitPlugin.class
$EXTENSION_DIR/ESPBEDemo/classes/com/philperon/espbedemo/plugins/GamePlugin.class

Now restart the server and activate the server level components, LoginEventHandler and InitPlugin by selecting “Extensions” from the top navigation bar in the ElectroServer admin interface and then, “Create New Server-level Component” on the left side of the page.

Extension name should be the same as you created above (ESPBEDemo) and the name and handle fields should be “InitPlugin”. Once that’s saved, do the same for the LoginEventHandler.

Now restart ElectroServer. When it initializes, you should see something close to the following:

Log back into the administration tool and check the extensions. If you expand the ESPBEDemo extension, it should look like this:

Congrats! You’ve successfully built and deployed a Java extension for ElectroServer!

In part two, we’ll build the PBE client and connect it all together. Stay tuned!

You can download the source code covered in this post here.

For more information on all things ElectroServer, check out their wiki or visit their forums.

This leads me to something I thought a lot about when I wasn’t coding my game. Quality. I may not be able to work on this as much as I’d like, but I certainly won’t push anything out too soon just for the sake of getting it done. That would cheapen my efforts and my time spent building this simple, little game is much too precious for that. If I can’t release this and be proud of it, I won’t release it at all.

In keeping with the theme of quality, I want to mention a few things that distracted me (in a good way) from writing code for S’troidz. These are folks that I have a massive amount of respect for and whether they realize it or not, continue to inspire and motivate me.

The guys at Gaming Your Way rock. They just released an incredible Asteroids-style shooter called, CronusX. This game is extremely well polished and really raises the bar on my favorite flash game genre… shooters.

Richard Davey’s site, PhotonStorm has been one of my favorites for a long time. Richard along with Christian Corti released Flod, a module (.mod) replay library. This is a huge accomplishment. To get an idea of how this can effect the flash game movement, I was able to insert a five minute song with only an additional 130KB added to the file size. Yeah. 130. [pause for applause]

Ben Garney is the man. Or borg. I’m not certain as I have reason to believe he never really sleeps. Besides guiding development of PushButton Engine, working on Grunts (PBLabs WiP), tearing up the forums and staying in touch with people on IRC he managed to start a video series that offer quicktalks covering a wide range of features available with PBE.

Finally, I have to mention Danc from The Lost Garden. He recently published part 2 of his “Flash Love Letter” series and it really is a must-read for anyone interested in flash game development.

There are many others I’d like to add but these are the folks who really charged me up over this past week when I was pretty bummed I couldn’t fit more quality into S’troidz!

OK, here we go…

S’troidz! r7 Changelog

• Started implementation of final alien type.
• Extended powerup duration. Enjoy the carnage.

S'troidz! Controls

The next two weeks are jammed full of work and familial obligations. Therefore I won’t be doing much (or any) coding on S’troidz! I will however be leisurely exploring sound effects and art in an effort to hone in on what this thing should look and sound like.

Thanks for stopping by!

OK, in the interest of time (which is very short) here’s the latest change log and release of S’troidz!

S’troidz! r6 Changelog

• Added Hyperspace Jumps
• Added Shields
• Tweaked difficulty progression to add more s’troidz sooner
• Fixed Power Up “value not a function” bug
• Bonus points no longer countdown when there are only s’troid core left on the screen
• Many other misc. bug fixes

S'troidz! Controls

I skipped out on adding the final alien type so I’d like to start work on that for r7. I’m also interested in adding interstitials between waves that will eventually act as place holders for things like stats and whatnot. The elephant in the room is the latest, greatest PushButton Engine revision that conforms to Adobe’s coding standards. If time allows, I’ll start moving the S’troidz! codebase on top of it. Otherwise, it’ll be the first thing I tackle in week 8.

Stay tuned!

OK, so what’s new in S’troidz! r5? Let’s see!

Because of my busy schedule, I thought I’d go ahead and spend a boat load of cash on advertising now in hopes of building up some early hype. In fact, I hired one of the more prestigious ad design experts around and am quite pleased with the results:

WTF?!

The folks at Evony better LOOK OUT!

The other two tantalizing items you’ll notice this week are a new alien bomber and a core attractor power up.

The alien bomber is the third of four total alien types that make up the family of baddies in S’troidz! The bomber either drops from the top or rises from the bottom of the screen and (you guessed it) drops a bomb in it’s wake. Be sure and stay clear of the explosion as it destroys you instantly.

So as not to just make the game more difficult, I’ve added a core attractor power up. Cores are harvested from smaller s’troidz and once you’ve collected enough of them, a new life is granted. The attractor greatly increases the velocity by which the cores move toward your ship, quickly boosting your count and helping you get the most out of the bonus points available.

OK, enough yappin’. Play DISCREETLY on your browser NOW!

S’troidz! r5 Changelog

• Added Bomber Alien.
• Added Core Attractor Power Up.
• Fixed a nasty alien movement bug.
• Started work on game difficulty progression.

S'troidz! Controls

The big item up for development this week is the obligatory hyperspace! Once that’s complete, I’m going to try and nail down a better form of gameplay progression and finally lay the groundwork for the last alien type. (Martijn, if you’re reading this… I’m sorry but no high scores next week. )

Finally, to anyone who (like me) works full time on other things yet still wants to be a productive game developer, let me offer you this piece of advice:

Get something done.

Even if it’s something small like tweaking a game value, play-testing or doing a sanity check on your design. You may not be as productive as you’d like but don’t brush aside an opportunity to get something done… even if it seems trite.

Thanks for stopping by!

Forcing players to move often is fine provided you give them a vehicle to do so that’s easy and most importantly, fun. Unfortunately, a zero-drag ship tasked with collecting many items in a short period of time is not. It felt like trying to collect marbles on an ice rink. And we all know what that means: marbles + ice rink = not fun. So with a few taps on the keyboard I added something that would solve my problem and also completely change the style of the game. Friction. You’ll notice now that moving the ship feels more like maneuvering a drift car. This makes it easier to collect power ups, s’troid core and in my opinion, makes it more fun.

Also worth noting is the Loot Controller component I wrote to support any ’stuff’ that could potentially drop from killing baddies. It’s pretty basic in it’s current form. Internally, the loot controller rolls against a table that returns the manager in charge of creating the loot you ‘won’. The biggest problem with my implementation is that it relies completely on my Spawn-family of classes. This makes sharing the component (which was my hope) difficult should someone else have their own way of spawning game objects. Frankly, creating loot and spawner components fit for public consumption merits it’s own development timeline. Needless to say, it’s out of scope for the S’troidz! project.

OK, up and at ‘em!

S’troidz! r4 Changelog

• Implemented Loot Table Component
• Created S’troid Core Spawner and Sprites
• 50 S’troid Core collected grants a new life.
• Created Increased Fire Power, Power-Up
• Various bug fixes with just a hint of refactoring

S'troidz! Controls

I have a lot of non-game related work and traveling to do over the next dev cycle and thus won’t be releasing a new version of S’troidz! next week. Once my schedule clears up, I’ll start work on a new alien type and if time allows, another power up.

Thanks for visiting!

When I first started tying game objects together I used events exclusively. Having just started using PBE, I wasn’t interested in changing the tools I was comfortable with. What I didn’t expect was how events would behave when you start dispatching, handling and responding to many of them several times per second. The results were sketchy. Inconsistent. The worst case scenario is that an event never reaches the handler. Unfortunately for me, this happened way too often. Shoving aside a list of items I wanted to address this week, I decided to rewrite the communication layer using function pointers instead.

The results were fantastic. It’s precise, reliable and direct. The downside is that I lose the convenience behind using events. For a relatively simple game like S’troidz! it’s not too gnarly having to manage it all yourself but in the future, I’ll probably want to design a more formal system. Don’t get me wrong, I’m still using events for other, less timely things but if it’s super critical, time sensitive and/or needs to happen in a serial fashion, I’ll stick with callbacks. OK, moving on…

Explosions! If refactoring a bunch of code was for me, adding explosions was for the player. It’s almost silly how something like this can add so much value to a game. Maybe I’m just being juvenile but it really is more fun when you can blow crap up.

Speaking of blowing crap up, why don’t you give it a shot?

S’troidz! r3 Changelog

• S’troidz no longer spawn on top of your ship.
• Explosions!
• Adjusted flight pattern of the ‘Waver’ alien. (If you’ve been hanging out in the center of the screen, you may want to think about moving.)
• A few other minor bug fixes.

S'troidz! Controls

This week I plan on wrapping up last week’s tasks which included creation of a loot table and power-ups. If I can rip threw those, I might begin work on the next alien type.

Let me know if anything breaks or just plain sucks.

S’troidz! r2 Changelog

• Added a logo.
• Added a preloader.
• Removed mouse cursor when the game starts.
• Fixed focus so that you no longer have to click the game twice to start playing.
• Added another alien! (clear 6 waves to meet him)
• Improved fonts.
• Added labels to scoreboard.
• Linear game difficulty adjustment.
• New hero ship!
• New missle sprites for hero and aliens.
• Increased large S’troid speed slightly.
• More bugs!

Note: I’ve been testing Flex 4 builds of PBE and S’troidz! which target Flash Player 10.

S'troidz! Controls

I hope you enjoyed this week’s release of S’troidz! Up next is design and development of a “loot table” component that will allow for things like power-ups. I also need to suck it up and deal with some annoying gameplay issues. Finally, if there’s time I’d like to also start work on explosion sprites and maybe even sound.

As always your comments and criticisms are greatly appreciated.

• Created dev artwork for first alien (Slider) and projectiles.
• Wrote Slider controller PBE component.
• Wrote Slider missle controller PBE component
• Wired up all collision detection for Slider/Ship and Slider missle/Ship interaction.
• Increased the ship rotation speed (slightly).
• Fixed a bug inside my random number from range utility function.
• Cleaned up some unused spatial properties.
• Implemented a ’safe period’ that occurs when a ship spawns (there’s no visual cue yet and you’re still fair game after a new wave).
• Tweaked the game balancing a bit. Things get gnarly pretty quickly.

OK, here we go…

S'troidz! Controls

Please share with me any bugs you find or thoughts about gameplay. Even in this raw form, that sort of feedback forces me to shift my perspective and ultimately has a positive affect on development. Have something you’d like to see in a future build? Let me know! I have a pretty clear design in place but if your request is on the list I have no problems bumping up the priority.

One last bit… releasing on Fridays doesn’t make a lot of sense for a number of reasons. Going forward, all new revisions will be deployed on Tuesdays instead. The next one will add another alien craft (fun!), some refactoring and if time permits, start work on designing a PBE “Loot Table” component that will allow for power-ups to drop from s’troidz. I’m also thinking it’s about time I add some dev art for explosions as well.

So much to do! Thanks for visiting and above all else, thanks for playing!

First let me tell you quickly why I’ve chosen this format to develop my first game…

I practice a type of Agile development at my “real job” where projects are broken down into sprints, cycles or whatever-you-want-to-call-them and releases are built at the end of each. Requirements drive these cycles and business folks get to choose what they’d like to see next. This empowers them to decide what’s most important and allows developers to show and share their work quickly and efficiently. The beauty is that you have a working “thing” every development period.

Moving on…

After creating what’s essentially a skeleton PushButton Engine project, I lifted some art from the interweb (I’ll totally give it back) and fleshed out the sprite sheets I’d need for the ship avatar and of course, the S’troidz!. The nice thing about using a framework like PBE is that once the project was setup, I only had to write a controller to deal with motion and collision. Input, rendering, spatial logic and other goodies are done for you. I spent about 12 seconds creating missiles in Graphics Gale which gave me all the assets I needed to move around the game screen and shoot stuff.

The next block of development was dedicated to object spawning and collision detection crap. The latter was a pain in the neck. I wrote a class a while back that I wanted to use but it flaked out way too often. Then I tried the PixelPerfectCollisionDetection class but that kept throwing runtime errors due to null object references (and I liked that one too ). Finally, I settled on yet another class that seems to be working well so far. (I haven’t played with Corey O’Neil’s Collision Detection Kit yet but it looks pretty solid.)

By the end of this period I had finished a family of Spawn classes that instantiate game objects based on things like collision detection. This allows me to easily create smaller chunks of S’troidz! when a large one was hit for example.

Now for the final development block where I spent most of my time writing countdown components, text render components and my own version of Dynamic Game Balancing.

The countdown component worked out really well. It’s amazing how handy this is for various game actions. PBE gives you a simple method to call functions in the future but I needed a few more bells and whistles. Once complete I was able to hook up the scoreboard, life counter and bonus point text rendering components. S’troidz! rewards fast play and the combination of countdown and bonus point render components makes it easy for the player to know how they’re doing.

Most recently, the game balancing piece was activated which relieves me of having to pre-package gameplay that accomodates 2 or 3 difficulty levels.

That brings us to today’s demo! Please keep a few things in mind:

• Expect bugs.
• Expect S’troidz! to spawn right on top of your ship killing you instantly.
• Expect it to be either really hard or really easy while I fine tune the balancing.
• Expect a slight delay while the game resources load after pressing the start button. I’m experiencing an old embedded resource issue again.
• No fonts are being embedded so if you see a grey box with no text, click it and the game will begin.

Ok, I’ll shut up.

(NOTE: If you have trouble viewing it below you can view the swf directly here)

S'troidz! Controls

If you’ve gotten this far it wasn’t so awful as to push you immediately from the page. That being said, I know it probably wasn’t a blast either. Good, bad or indifferent I’d love to hear your thoughts.

That wraps up week zero. The next dev cycle will focus on the installation of alien crafts and if I have time, implement a period of invulnerability for player ships that respawn after being destroyed.

Thanks so much for visiting. S’troidz! will be back next week!