Oversoul Stress Tests
Hello Everyone – Sorry it has been quite a while since my last post. The last couple of months have been very busy with the development of Oversoul. This has been a long project with many challenges, but all of our hard work has paid off and we held a couple of public tests this week to see how well the game could handle a realistic load.
Fortunately, these tests have been a huge success so far. We have found and fixed most of the bugs that we have encountered and the server is running fast and stable! Needless to say, I am very pleased with the results and I am really looking forward to the game’s official release!
Oversoul has been quite a large project. It is actually three major projects in one:
1) Server: We have built our own server for Oversoul – none of AQWorlds’ server code has been reused. This was a huge undertaking, but now we have our own custom-built server software that will be reused in all of our future games.
2) Mage Game Framework: Over the past couple of years, I have been working on a game framework to help create games with higher framerates in flash. It is a little rough around the edges still, but I have made many improvements to it while working on Oversoul. It is all worthwhile when I see a lobby full of players running around at 60fps!
3) The Oversoul Game Itself – The Oversoul game client has had its own share of challenges – It is the biggest project that I have worked on so far – The game client has had to become extremely flexible to handle the various card effects and combinations. Oversoul is our first game that uses spritesheet animations – However, we have kept the content creation as simple as possible and Nulgath has been cranking out tons of characters!
The public alpha test is coming very soon now! After the results this stress test, we are confident that the game will be a success. The next step will be to work on the final features before release such as level ups, items and shops.
Thanks to everyone who particpated in the pre-alpha stress tests!
Actionscript 3 Tools – MonsterDebugger
I recently came across a really great tool for debugging Flash applications – It is called MonsterDebugger.
Overall it is a very helpful tool. It allows you change public variable values on the fly and features trace filtering and a tree listing for tracing lists such as Objects, Arrays, JSON, XML, etc… It also gives you a detailed list of all active display objects. It has a very simple API and also features a walkthrough minigame to help familiarize you with the features. It gives you the current frame rate as well as memory usage information. There is one one caveat. It reports memory usage for all flash applications currently running. So, if you have a bunch of flash games running in background tabs, don’t be surprised if your ram usage looks insanely high!
Incorporating MonsterDebugger into your projects is very easy. It has a very lightweight API that is easy to use. I had it integrated into some large projects within minutes and I have found myself using it more and more. Its trace output is much nicer and more organized than searching through Flash’s console output. I tend to use MonsterDebugger along side Flash’s console. I use Flash console to trace simple text messages and variable values. Then, I use MonsterDebugger to trace larger data structures such as Objects and Arrays. The expandable tree listing for Objects and arrays is very nice.
To integrate MonsterDebugger into your projects, just install the MonsterDebugger.air application and export it’s .SWC library to your project classpath. Then, this is all the code you need to get started:
/** initialize the debugger - Remove this code for Release */
MonsterDebugger.initialize(this);
/** Sample Trace Output to MonsterDebugger */
MonsterDebugger.trace(this, "Hello World!");
Note: You will need to have the MonsterDebugger air application running to see its trace output. Otherwise, nothing will happen.
I have found MonsterDebugger to be a huge help on my projects. Maybe you will too! It is definitely worth checking out!
Derp Sensation
When Thyton and I created the Derp Song for the AQW April Fool’s release last year, little did we know that it would become an internet sensation! Somebody actually made a 10 hour long version and put it on youtube… What’s even more surprising is that over a million people have watched it!
Needless to say, that was one of the funniest recording sessions I have ever done. It was actually difficult to belt out those “derps” through all of our laughter. For those who are interested, Thyton provided the brilliant bassline and I did the higher pitched melody part. The gigantic breath at the end is classic. Thyton is a comic genius!
So, go to Heromart and download the song today! (You may have to scroll down the page to find the link – Search the page text for “Derp”) While you’re at it, you should download the Cookie Song too 😉
Seriously, Adobe, are you serious?!
How exactly this is supposed to “…encourage the kind of innovation and experimentation that often helps to spark inspired and inventive games…!” is beyond me.
I find it difficult to understand why Adobe would want to do this. This decision seems driven by pure greed… or… Is the Flash platform hurting so much that this is the only strategy for survival?
My initial reaction is to think that this will hurt Flash platform overall and Adobe will start hemorrhaging developers left and right. It is a shame, because IMO, Flash was just starting to get interesting again with Stage3D and Alchemy. It has really become a polished product since the Flash Player 11 release. It is truly no joke that you are able to create console-quality games in the browser. Nothing else even comes close (in the realm of browser plugins). But to put all of that cost onto developers backs could drive away small and independent developers, making only the largest game publishers able to afford to make Flash Games. That might actually might be their intention. It seems like Adobe is trying to get people to look at Flash Player more seriously as a “real professional” platform. They might even be purposefully trying to cut the fat and drive away those who would develop shoddy flash applications and give the platform an undeserved bad reputation.
Another spin on this is that with new publishing platforms such as Unity. Adobe is a losing a market for Flash publishing. They want to leverage some profits from those using different publishing platforms since they are losing potential customers who would have normally purchased licenses for the Adobe Flash CS suite. Instead, content creators will develop 3D content with applications such as Unity, Maya, etc… and not from Flash. Of course, Flex has enabled developers to publish .swfs without Flash for years now. 
Only time will tell. This could be the best thing that ever happened to Flash… or the worst. One thing is for sure… it seems to be the most “Evil”. 😛
Note:
These new fees apparently do not apply to AIR apps, so anyone developing mobile or desktop AIR apps that take advantage of Stage3D and Alchemy should be fine… for now. Also, the use of Stage3D or Alchemy individually do not require the fees. Fees apply specifically the use of Alchemy2 and Stage3d together. For more info read Adobe’s blog about it.
Flash Player Mobile is Dead… Long Live Adobe!
Since November 2011 last year, there has been a lot of talk about Flash’s death at the hands of Apple. When Adobe announced that it will no longer be developing Flash Player for mobile devices, everyone immediately assumed that this signified the end of Flex/Flash for mobile devices.
The other part of Adobe’s announcement was relatively unhyped. They promised further development of the Adobe AIR platform for mobile devices. AIR 3.2 is currently in pre-release RC status and it is looking very good so far! Adobe has added more native application support as well as stage3D support to the mobile version of AIR. This has huge potential especially for gaming.
I recently came across this blog posting demonstrating AIR’s new 3D support for devices:
Five AIR 3.2 Stage3D Mobile Demos That Will Knock Your Socks Off
This looks extremely promising! Curious, I immediately downloaded the RC version of AIR 3.2 from Adobe Labs and then proceeded to port my Starling Framework Test to my Nexus One android dev phone. Everything worked as expected and the framerate was very smooth. It does appear to me that Flex/AIR is still a very capable mobile platform. Also, the Flex SDK is open-sourced do there is little to no cost to develop Flash and AIR applications with it.
As of late 2011, Adobe recently donated Flex to the Apache Foundation in what appears to be community-friendly exit strategy while they shift their focus to HTML5 solutions. While the implications of this move indicate that Adobe is moving away from Flex/Flash. It certainly does not signify the death’s of those platforms. It could be the best or the worst thing to happen to Flex. It remains to be seen. It all depends on Adobe’s dedication to contributing to the development of the Flex platform.
Here is a link to Adobe’s “Roadmap for the Flash Runtimes” whitepaper:
http://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html
Inside, it mentions that they perceive Flash as the gaming console of the web. It also mentions their future plans for the web Flash Player and the next permutation of Actionscript. It is actually an interesting read, if you’re into that kind of thing.
So, while Flash Player for mobile devices is dead. It looks (to me) like AIR is very much alive… for now.
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:
BoxBreaker – Free Game Source Code
Last July, I taught myself how to program in Lua by creating a physics-based breakout clone called “BoxBreaker.” I used an open-source game engine called Love2d to create it. This was a learning project that I slapped together over a few weekends. My goal was learn Lua and to create a game that I could actually play on my Debian Linux PowerPC system. Love2d just happened to be one of the few game engine options that fulfilled my needs and was actually compatible with my hardware. The Love2d community was also very helpful and active and some members actually contributed code snippets and game levels.
I produced this game using only free and open source tools on my Debian machine. I used Emacs as my code editor, GIMP for the graphics, and zynaddsubfx to create the soundfx.
Anyway, I made BoxBreaker available on Github for anyone who is interested. Admittedly, this is not the best code that I have ever written. My Lua skills have improved a lot since this project, but it helped me to learn and I hope that it can help someone else learn too.
Overall, I think the game actually turned out to be pretty fun and since Love2d is available on Windows, Mac and Linux, it is cross-platform as well! 😛
Here is a link to the project:
Boxbreaker on Github.
Note: BoxBreaker was a personal learning project and is unrelated to my work with Artix Entertainment, LLC.
Ominous theme – Imminent War in Bloodtusk
Sample Clip Here: Ominous Theme
This is one of my personal favorites. Bloodtusk was a really fun zone for me and it resulted in some of my favorite compositions in AQWorlds. This theme is a slow building theme. It is a repeated theme that layers more and more harmony parts as it repeats. Overall all it is a very simple piece, but as the harmony builds, it becomes richer and fuller. I am particularly fond of the choral arrangement that comes in at the end of the piece. This song has the dubious honor of having made my mother cry real tears (she’s very emotional about music).
Software used:
FL Studio Producer Edition
Sonivox Muse
Ominous Theme by Artix Entertainment, LLC is licensed under a Creative Commons Attribution-NonCommercial 3.0 Unported License.
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!
Warlic's Tower 