wasted potential

Here today, gone tomorrow

Category: Actionscript/AS3 Page 2 of 8

Pixi.js – HTML5 for Flash developers

By

On March 24, 2013

In Actionscript/AS3, Flash, Game Development, HTML/CSS, javascript, Uncategorized

pixi js Pixi.js is another javascript framework that attempts to recreate some of the features of Flash. It even replicates a lot of Flash components: MovieClip, Sprite, Stage, DisplayObject. It’s an impressive javascript library. You can download the source and some examples from github. I spent a little time hacking around on the examples and picking through the source code. Here’s a video introduction if you prefer that, or you can skip down to the text below the video…

Here’s a quick primer on Pixi.js:

It’s really comfortable for Flash/Actionscript developers. The folks who created Pixi.js are clearly very familiar with Flash and used a lot of Flash terminology in Pixi.js. It also feels like they worked hard to make it very easy to dig in and start creating cool stuff with minimal boilerplate code. I really appreciate that.

There is no built-in way to set a target frame rate in Pixi.js. Technically, there is no way to force a specific frame rate in javascript and it will only do the best it can, but Flash worked that way too and you could still give it an FPS target. The Pixi.js examples seem to rely on requestAnimationFrame() to run at 60 FPS. This is not reliable, so if you use Pixi.js, be sure to write some code to handle the rendering frame rate.

Pixi.js has a really clever renderer: It detects if your browser is WebGL enabled. If not, it falls back to an HTML5 canvas renderer. Not only is it cool that it handles this for you, but browsers with WebGL (Chrome, Safari) are hardware accelerated. This means that they can unload the rendering from the CPU to the GPU, making everything run much faster. Firefox also supposedly has WebGL capability, but from what I’ve read, the performance is questionable. The WebGL thing is going to be a big deal as it becomes more widespread. As usual, IE10 doesn’t support it, but it does have hardware accelerated canvas.

As a side note, the hardware acceleration is all based on your browser and hardware configuration. So, if you have a relatively new device and an updated browser, it just kicks in automatically. iPhones and iPads all support hardware acceleration and many Android devices do too. Obviously, how you handle older browsers is the challenge. In most cases, a less full-featured backup may need to be served up. In a few cases, the user may need to have hardware acceleration to run your game or app at a reasonable frame rate. A smart way to handle this is to check the frame rate of the game and alert a user if it drops below a minimum threshold.

So grab the Pixi.js code and start building some HTML5 goodness.

Why I Still Make Games in Flash/AS3 (for now)

By

On January 14, 2013

In Actionscript/AS3, Flash, Game Development, HTML/CSS, javascript, Uncategorized

As I look ahead to this year, I have several posts planned around game development in ActionScript 3 (Flash). So, I thought I should post a brief explanation about why I’m STILL developing games in AS3. After all, isn’t Flash dead? Aren’t we all living in a brave, new HTML5 world? Here are a few of the reasons why I’m developing in AS3:

actionscript vs javascriptAs of this post, HTML5 <canvas> support is still inconsistent across major browsers. Admittedly, the main issue is Internet Explorer, but they still have a HUGE market share and can’t be completely ignored. For most of our <canvas> projects at work, we still end up building a Flash backup. If you’re targeting desktop devices for your games, publishing to Flash gives you a bigger market share than HTML5 <canvas>.

HTML5 <audio> support is pitiful. In some browsers (*cough* Mobile Safari *cough*), it barely works at all. Then there are issues with preloading sounds so they are actually available when you need them.

Read More

A Flixel platformer game with source code.

By

On May 28, 2012

In Actionscript/AS3, Flash, Game Development

After my recent post about using Flashpunk to build a Flash game, I started working on a game project and quickly became frustrated with some of the shortcomings of Flashpunk. I found myself hacking the core Flashpunk engine so much that I thought I’d try Flixel and see if it worked better for me. I’m glad I did. Flixel has a lot of nice features built in that Flashpunk does not. After working with it a bit, I was able to hack together a small platformer in my free time over a few days. So, here are my thoughts on the Flixel and Flashpunk engines as well as the source code for my Flixel “game,” which is actually an interactive birthday card for my awesome wife.

First, click the image below to check out the Flixel game that I made last week (give it some time to load – there’s no preloader). You may need to click on the Flash stage to give the game focus.

I spent less than 15 hours on the whole thing and that includes coding the game, creating the artwork and even hand-coding the tilemap text file. The game has some issues, but I was rushing to get it done before my wife’s birthday and I’m pretty happy with how it turned out. Here are some things I would have changed if I had time:

  • Clean up the artwork. Most of the art was slapped together pretty quickly in photoshop and could use some serious polishing.
  • Add some sound effects
  • Optimize the graphics. Most of the screens use large bitmaps that should have been chopped up into smaller images.
  • Add a preloader

As for the eternal question of which is better Flixel or Flashpunk? Honestly, it’s a matter of personal preference, but I really prefer Flixel. If you want to build a basic platformer or top-down shooter, you could code the basic game in a day or two and spend more time building levels or creating graphics and sound. It just feels more fleshed out than Flashpunk to me.

My frustration at needing to hack the Flashpunk engine didn’t go away when I started using Flixel, however. The game that I’m trying to build requires me to hack the core of the Flixel engine too. The downside of Flixel is that the AS3 code in the Flixel engine is much more opaque than Flashpunk. Flashpunk’s code will be more familiar to most Actionscript developers, so it will feel more comfortable. In fact, I’m still working out some of the details of what I’m trying to do in Flixel and it is not as simple to tweak the Flixel engine as it was to modify Flashpunk.

As with Flashpunk, there aren’t many great tutorials for Flixel – the forums are very helpful.

Also like Flashpunk, Flixel has had a major revision at some point and a lot of the API was changed. If you are following a tutorial and the code isn’t working for you, it is probably for the older version of Flixel.

In case you missed it, you can download the source code for my Flixel game here. There is a lot of helpful code in there including how to set up scrolling, tilemaps, and collectibles. Feel free to take my code and build on it. I replaced the character sprite sheet because I want to use it again.

The music I used is “Many Happy Returns” by Tom7, used by permission. Click here to check out his other chiptunes – they’re great.

Augmented Reality Air Hockey – A Game Experiment

By

On March 20, 2012

In Actionscript/AS3, Flash, Flash 3D (Papervision, Five3D), Game Development

I was digging through some of my old files the other day and found this interesting game prototype from a few years ago, when Augmented Reality was the latest buzzword. I had seen some experiments with it, but I was curious to see if the AR Markers could be used as game controllers. Could you create a driving game where the AR Marker acted as the steering wheel? Or, could you even create multiplayer games that used multiple markers?

I started playing with the Transmote FlarManager and decided to try to create an air hockey simulation using 2 AR Markers and the APE physics engine for Flash. My game prototype can be seen in the video below.



This turned out to be a lot more challenging than I expected and I was pretty disappointed in the results. As you can see in the video, the performance of the Augmented Reality tracking is fairly weak. I also had to hack the physics engine quite a bit to get what I was looking for. Here’s the rundown of what I learned:

  • The Augmented reality tools are fairly clunky and require a lot of resources. That’s why most of the cool experiments you see use stationary AR Markers sitting on a tabletop. It’s too difficult to keep up with moving markers.
  • The Transmote FlarManager library tracks multiple markers, but it is not able to differentiate them. In other words, it can only tell that there are 2 markers on screen in my game. It can not tell which one is player 1 and which one is player 2. In this case, it really doesn’t matter. You score a point in air hockey when the puck lands in a goal – which player touched it last is unimportant. But, in many games, knowing which player acts on an object is crucial. I also tried the Squidder FLAR Actionscript library and had the same results.
  • APE (Actionscript Physics Engine) is a set of classes I have used before and I find it useful for simple physics-based games. The syntax makes a lot more sense than Box2D if you don’t know C++. But, for this game, I needed a Dragable Circle Particle, which is not a standard APE class. Luckily, someone smarter than me created one here. I adapted it and then created a FlarCircleParticle for my prototype.
  • This prototype has a lot of overhead. It uses the basic AR toolkit for Flash, the FlarManager, Papervision 3D, APE Physics, and more. So, on every frame, I’m capturing the webcam footage, trying to locate multiple AR Markers, using Papervision to calculate the positions of the players, and then running a physics simulation before drawing it to the screen. That’s a lot of work for Flash. For optimization, the Papervision probably needs to be removed and a 2D AR Marker locator needs to be created.

In essence, this experiment is a failure, which is why I never finished it. The FlarToolkit and FlarManager just aren’t capable of what I needed. I don’t consider it a waste of time, though. You need to be willing to take chances with game prototypes… and you need to be willing to give up on prototypes that just aren’t working. Very few great game ideas work perfectly on the first try, but an interesting failure can spawn a lot of great ideas.

If you want to try my prototype for yourself, download the markers and click here to test it out. The source code for this Prototype can be downloaded here. Feel free to take it and play with it. A word of warning: I built this several years ago and I hacked it together pretty quickly, so the code is a bit of a mess. If you are able to create anything cool with it, I’d love to know about it (and a shout out for wasted potential is always nice). Some links to resources you might need can be found below. Good Luck!

*Note that a lot of these actionscript libraries are no longer being maintained. They are the ones that I used when I originally built my prototype.

Page 2 of 8

Previous

Next

Powered by WordPress & Theme by Anders Norén