Blog Archives
Oversoul Update- Rolith’s Spellserver
You may already be familiar with Oversoul’s Mage graphics Engine. There is another major component to Oversoul that we are working on called “Spellserver”. Spellserver is being developed by Rolith. It is a fast and lightweight multiplayer socket server developed in C#. We will be using Spellserver to handle multiplayer functionality in Oversoul.
Spellserver is a huge undertaking and I have a ton of respect for Rolith for doing undertaking this massive task. One of the huge benefits to developing our our socket server is that we will be able to handle more simultaneous connections at one time and it should be very lightweight and affordable compared to some of the more fully-featured enterprise solutions.
Spellserver is being developed parallel to Oversoul and we have just gotten to the point where we can start merging the two projects together. This is a very critical stage in the development of Oversoul – because once we hook all of this up – it will be very interesting to see what breaks! So far, login and walkaround is working flawlessly. Right now we have started porting the battle logic to the server. So far things are going slowly but smoothly!
Nulgath’s conceptual Oversoul preview – Estimated release Summer 2012:
Mage Engine Introduction
If you have seen the most recent Oversoul videos, then you may have noticed a “Powered by Mage Engine” logo in the intro of the movie. I have been getting a lot of questions about this lately.
The early beginnings of the Mage engine started last April when I took on the project to port the minigame, Fat Panda to the iPhone and Android. That project was our first experience with mobile development and it was a huge learning experience.
Our games have always used Movieclips as the main content type. With Movieclips, you can have hundreds of frames of animation smoothly tweened by flash – All of our animators are extremely proficient animating Movieclips and they enabled us to crank out content extremely fast for all of our major games. The problem is… vector art, which is what most of our Movieclip assets are comprised of is incredibly slow. Every line and fill gets redrawn on every frame – Not so bad when you are making browser-based games for relatively modern systems – but it is a completely different game on mobile. In mobile games, you need to use bitmap graphics that can get cached in memory and drawn instantly to the screen. I remember running a test and finding that just putting a vector-art button on a screen full of bitmaps caused a 50% decrease in framerate! It became very clear that we needed to make some major content pipeline changes if we ever wanted to make any Flash games for phones.
You can increase movieclip performance by embedding static bitmaps inside movieclips, but even then, most of our animations are hundreds of frames – some characters in our games comprise of literally thousands of frames – Thousands of frames of embedded bitmaps would be incredibly large and would quickly eat all of our filezize limitations on phones. The nice thing about vector art is that it is extremely small because none of the bitmap data is stored, it just contains the data that the system needs to redraw the image at run time.
So, to address some of these issues, I came up with a way to convert animated movieclips into bitmap sequences at runtime. I called this process “baking movieclips”. It was a major performance increase and we were able to finally use movieclips for mobile applications. Anyone who has actually played Fat Panda might notice that it says “baking pandas” at the start of the game. This is essentially what is happening. The biggest drawback to using “baked” clips is that is very memory intensive, so you can’t have thousands of frames of animation without blowing up your phone! Memory management is also a big concern – because you have to make sure that you are properly disposing of the bitmap data before all of your ram is gone.
Mage had its beginnings in those baked movieclips. It is ultimately a collection of classes that I have compiled over the last several months to ease the headaches of game programming. It is very similar to Flashpunk or Flixel – although it is still very much in its infancy as a full game engine
Mage has several graphic Entity classes including Baked Movieclips, spritesheets, static bitmaps, gamestates and normal movieclips and it handles proper cleanup of those assets. It also has AudioMixer capabilities. It has Camera and Display classes and some handy functions for importing rectangles from Spritesheet Packer xml files and tiled maps from the editor, Tiled. There is also some very rudimentary Box2D support in Mage.
Here is a link to an early Mage test utilizing Box2D Physics, spritesheets and Camera fucntionality:
Mage Prototype Test
Oversoul will be using the Mage engine to improve performance by baking certain things like backgrounds and interface elements. It will also be utilizing Mage’s Gamestate, Audiomixer and Camera functionality. Some of the more experimental aspects of Mage such as box2d and tiled support will not be used in Oversoul. We will still be using Movieclips for heavily animated assets. Nulgath’s has really been set loose on this one and is cranking out literally tons of animation! It is very exciting!
Actionscript 3 Tip: One Event Listener to Rule them All!
If you have ever coded anything in Actionscript 3, then you will be very familiar with code that looks something like this:
/** Add an event listener for every button... */
button1.addEventListener(MouseEvent.MOUSE_DOWN, button1Pressed, false, 0, true);
button2.addEventListener(MouseEvent.MOUSE_DOWN, button2Pressed, false, 0, true);
button3.addEventListener(MouseEvent.MOUSE_DOWN, button3Pressed, false, 0, true);
/* now here are the event handlers for all of those buttons */
private function button1Pressed(e:Event)
{
trace("Button 1 Pressed");
}
private function button1Pressed(e:Event)
{
trace("Button 2 Pressed");
}
private function button1Pressed(e:Event)
{
trace("Button 3 Pressed");
}
It can get very tedious to add and remove all of those event listeners! Especially when you have a lot of buttons on the screen! You can alleviate a lot of this pain by using the event.target property of the event class.
One way to simplify things is to put all of your buttons into a movieclip and then add a single event listener to that movieclip. Then, just look at the event.target.name to find out which specific button is being pressed. Each button in the movieclip should have a unique instance name for this to work.
Now your code would look something like this:
/** Add the button event handler to the buttons' parent clip. */
buttonsClip.addEventListener(MouseEvent.MOUSE_DOWN, handleButtons, false, 0, true);
/** Button Handler */
private function handleButtons(e:Event)
{
/** e.target is the actual button that is being pressed. */
trace(e.target.name);
}
This is a nice clean way to handle button events without having tons event listeners. When you have tons of buttons all over the place in a flash application, it can be very easy to forget to remove all of them and can lead to memory leaks as orphaned event listeners tend to like to hang around and prevent garbage collection from clearing them. This way, you only have to worry about one listener.
It is often more helpful to see some code in action. So, here is a link to this example as a FlashDevelop project.
I hope this was helpful!
Experimenting with the Starling Framework
I am about to try something I have never done. I have decided to check out Starling. It is a game framework for Flash that renders 2D images on Flash’s new Stage3D. The advantage to rendering on the 3D stage is that it allows you to take full advantage of hardware GPU acceleration in your 2D games. So anyway, lets learn about this new framework together, shall we?
First, we need to get the latest version of Adobe’s Flex SDK and Flash Player 11 or higher. I highly recommend using FlashDevelop, since it automatically downloads and installs the SDK for you. You can get the latest version of FlashDevelop here. Then of course, you will need to get the Starling source code. You can get Starling here. Just download it and unzip it into the folder of your choice.
Now in FlashDevelop: Create a new AS3Project.
Now that you have your project set up, go to
Project –> Properties –> Classpaths –> Add Classpath –>
Then, select the folder where you unzipped the Starling framework and browse to the starling/src directory. Your Starling pathi will look something like this: D:\path to Starling\starling\src – Note you must point to the starling src folder or else FlashDevelop will not be able to find any Starling classes.
Next we initialize Starling with our Main.as Class
package
{
import flash.display.Sprite;
import starling.core.Starling;
/** Define SWF properties */
[SWF(width="800", height="600", frameRate="60", backgroundColor="#3f3f3f")]
public class Main extends Sprite
{
/** Declare a variable for Starling */
private var _starling:Starling;
public function Main()
{
/** Initialize Startling with the Game class and current stage. */
_starling = new Starling(Game, stage);
/** start it up! */
_starling.start();
}
}
}
Now, Starling initializes and our Game class is automatically instantiated – Game.as (or whatever you want to call it) is were your main game code goes:
Game.as
package
{
/** Import the clases we will need to use -
* Note : that you must import starling classes instead of flash classes!
* */
import starling.display.Stage;
import starling.events.Event;
import starling.core.Starling;
import starling.display.Image;
import starling.display.Sprite;
import starling.text.TextField;
import starling.textures.Texture;
public class Game extends Sprite
{
/** Stage Width */
public static const STAGE_WIDTH:Number = 800;
/** Stage Height */
public static const STAGE_HEIGHT:Number = 600;
/** Embed an image for logo Class */
[Embed (source = "Logo.png")]
private var _logo:Class;
/** Define Starling texture from the logo image */
private var _texture:Texture = Texture.fromBitmap(new _logo());
/** Create a Starling Image DisplayObject out of the texture */
private var _bmp:Image = new Image(_texture);
/** Movement Speed along x axis */
private var _xSpeed:Number = 10;
/** Movement Speed along y axis */
private var _ySpeed:Number = 10;
/** Constructor */
public function Game()
{
/* add the image to the Starling 3D Stage */
addChild(_bmp);
/* set bmp start coordinates: Centered */
_bmp.x = STAGE_WIDTH/2 - _bmp.width / 2;
_bmp.y = STAGE_HEIGHT / 2 - _bmp.height / 2;
/* Enter frame Event for main game loop */
addEventListener(Event.ENTER_FRAME, loop);
}
/* This function is run on every frame. It Bounces the Bmp around the screen
* As you can see - once you get Starling all set up, it's DisplayObject Classes are very similar to Flash's
* */
private function loop(e:Event):void {
_bmp.x += _xSpeed;
_bmp.y += _ySpeed;
if ( (_bmp.x > STAGE_WIDTH - _bmp.width && _xSpeed > 1) || (_bmp.x < 0 && _xSpeed STAGE_HEIGHT - _bmp.height && _ySpeed > 1) || (_bmp.y < 0 && _ySpeed < 0 ) )
{
_ySpeed *= -1;
}
}
}
}
As you can see the code is pretty similar to the code you would use with “normal” Actionscript classes. The most important thing to keep in mind when using the Starling framework is that you need to import the starling.display.* classes instead of the usual flash.display.* classes. Also – bitmap data must be mapped to a texture bfore it can be drawn on a Stage3d object.
Here is the picture asset used in this example:
Here is a link to see the results of this test – Flash Player 11 or higher required for Stage3D functionality:
I hope you learned something! I certainly did. This was my first experiment with using Stage3D and Starling in Flash!
It is definitely an exciting time for Adobe Flash as it is becoming a more and more powerful game platform! Hardware accelerated 3D in the browser opens up huge possibilities! The Starling framework enables developers to easily utilize hardware acceleration in their 2d projects in a way that is familiar to them. The Starling display objects behave almost exactly the same as their flash counterparts. The biggest difference is that developers will need to learn about Starling’s “Textures” and “Texture Atlases”.
If you would like to learn more about Starling, there is a nice video tutorial here:
haXe – Initial Impressions
HaXe sounds too good to be true. It is a cross-platform language that can compile to Flash, HTML5, Javascript, Android, iOS, webOS, and cpp binaries for Windows, Macintosh, and Linux platforms. But is it any good? I first heard about haxe about 3 years ago when I noticed it was an available option in FlashDevelop. I thought it was neat, but I didn’t really see much of a point at the time. Especially since all of my projects were Actionscript.
I recently took a second look at this language and I must say I am impressed. To test performance, I did a barebones port of my flash2D game engine, Mage*, and ran some framerate tests of the various platforms. The results were surprising:
HaxeMage Test: 100 Animated Spritesheets running around on a panning background:
- Flash – 59 – 61fps!
- Cpp – 56 – 61 fps
- html5 – 43 – 51fps
- Android Nexus One – 27 – 30fps
- iOS – (haven’t had a chance to get this build working yet)
The Flash version is the overall winner, which was not surprising since the Mage engine is a flash project to begin with – There is a copypixels draw in the main display class that is likely causing the slightly slower performance in the other builds. All other builds are quite promising though with overall playable framrates throughout. The Nexus One build performed very well, considering that this phone is a few years old and not the fastest… Watching 100 big sprites running around at smooth framerates is very refreshing.
One interesting quirk that I noticed was that the html5 version was not able to show the character flipped – when the character hits the edge of the screen, he flips left or right depending on which direction he should be travelling. On the html5 version, he always stays looking in the same direction. This leads me to believe that html5 cannot do flash-style matrix transformations on bitmap data. I will have to research this further. Other than that, the html5 build delivered very respectable performance.
Here are links to the Flash and Html5 tests for those of you who are interested:
The spawn limit on these tests is 1000 characters – At 1000 spawns – the performance gap between Flash and Html5 widens. On my system flash still maintains a solid 60fps – while html5 drops to around 18fps. Still, this is not bad for html5 – which can’t really compete with Flash for gaming performance.
After the results of these tests, I will be highly considering using HaXe for my future flash projects. The ability to easily publish to several platforms from the same code-base makes HaXe a very powerful tool for any Flash developer!
*Mage will be featured in my future game project for Artix Entertainment.
Warlic's Tower 