Skip to content
Jan 7 11

Simulating Fluids in Flash

by pixelpracht

A thread in the FGL forums got me interested in the simulation of fluids. Of course this topic has seen quite extensive coverage in academic papers but getting it to work in the limitted environment of Flash provides some intersting challenges. Interesting enough for me to give it a try over my christmas break.

I loosely followed a paper Particle-based Viscoelastic Fluid Simulation to implement a sandbox application that simulates and renders a small blob of fluid and allows you to tinker with various parameters. Click the image below and give it a try!

The fluid is represented as a set of ~400 particles that interact with their neighbours and such seem to form a coherent entity.

For rendering I use an oldschool approach: Each particle is represented as a metaball. For a given pixel the force function of every metaball is evaluated, summed up and the final sum is compared with a threshold value to decide whether the pixel is inside or outside of the fluid.

To be able to do that in realtime I precalculate the values that a forcefunction yields for pixels within a relevant range of the particles center as a Bitmap.
Fluid Rendering - Illustration #1
These tiny images (about 40×40 pixels) are rendered at the position of the particle with additive blendmode.
Fluid Rendering - Illustration #2
Now I can decide with a single lookup in the resulting Bitmap if a pixel belongs to the surface or not. That evaluation step is done by a pixel bender shader and instead of just working with a boolean state (inside or outside) I sample a gradient based on the accumulated force value.
Fluid Rendering - Illustration #3
This approach allows me to achieve a variety of styles in the visual appearance of the simulated fluid by just using different gradients.

This technique would unfold it’s real potential if you could use hardware acceleration to accumulate the field functions because that’s a bottle neck in the current implementation.

Not sure if that stuff has any practical relevance, anyway. But the SWF is only 32kb big so people that are into demos (32k, 64k) could maybe make something fancy out of it. :) Here’s the source code released under the MIT license.

Sep 30 10

Developing and Selling Rune Hunt

by pixelpracht

I started experimenting with real time shadows in Flash in fall 2009. At the same time I took notice of the Flixel framework and all the cool retro games that people made with it. Why not make a game of my own that combines pixel graphics with dynamic light and shadows?

At the 14th December 2009 I created a thread in the Flixel forums with a mission statement:

The setup is classic: a hero in a dungeon full of treasure, traps and NPC of questionable attitude. The twist is that I’m limiting the player’s view to what his avatar is seeing. Top-down-ego-perspective so to speak. I hope it’s making exploring the dungeon more interesting and the enemies more scary if you don’t see all the stuff long before it becomes relevant/dangerous.

It’s been the beginning of an interesting journey…

read more…

Sep 24 10

Rune Hunt Released

by pixelpracht

Hungry eyes watch from the shadows. The flickering light of a butterfly is all that keeps them at bay. Run for your live – and sanity!

Finally, after almost a year of working on it, I have finished Rune Hunt!

Well, technically it’s been finished a couple of weeks ago. But I tried to find a portal that would sponsor the game. The basic idea of sponsorship is that you include links and logos of a flash game portal in your game before you spread it. The branding means traffic for the sponsor and that traffic is what they essentially pay you for. The other great thing besides money is that the sponsoring portal has an interest in getting your game played and will help spreading it – for example by featuring it on the front page. So you get money, exposure and retain full creative control. Cool stuff!

So in the last weeks I’ve spend quite a while on flashgamelicense.com and learned a great deal about how the market around free flash games works. The website is basically an agent that brings developers and sponsors together. Sponsors can bid on your games, after a while you pick the best offer and pay a comission to FGL. The process of trying to license my own game was nerve-wrecking but fun and in the end pretty successful. Huge thanks to ArmorGames for the generous sponsorship!

But enough of that for now. Go and play the game allready! ;)

Jul 6 10

Drawing API Memory-Leak in Flash 10.1

by pixelpracht

When trying Rune Hunt in the new 10.1 version of the Flash Player I noticed a HUGE performance drop. In the old player it would take about 27ms on my system (debug build) to update the game’s state and render the next frame. In Flash Player 10.1 this changed: The time it took to calculate a frame started fluctuating and increased to 48ms on average.

A member of the Flash Player Engineering team replied to my inquiry about known performance issues:

General actionscript performance is not any slower in 10.1 than 10.0 from our testing, it must be something particular in your code which exhibits the problem. Do you have a reproducable test code or a url you can point us at?

So I tried to isolate and reproduce my problems. It seems that my problems are caused by a Memory Leak in the Drawing API. I wrote a simple test application to illustrate the issue and hopefully find a work-around.

//... there`s a buffer as rendertarget and a flare
private var _flare:BitmapData = null;
private var _buffer:BitmapData = null;

//each frame I render the flare 100 times into the buffer
for(var i:int = 0; i < 100; i++)
    _buffer.draw(_flare, null, null, BlendMode.ADD);

In the 10.0 player there is no memory fluctuation caused by this code. But in the 10.1 player each draw-call allocates new memory. The total memory is increasing linearily until the garbage collector kicks in. This of course effects the performance.

In all browsers and on all systems that I tested the memory leak was present in the new player – but the way the garbage collector handled it varied so the graph isn’t always as clear. You can test it for yourself. And here’s the source for the test application.

My guess at what happens: BitmapData.draw() method accepts IBitmapDrawable an interface that is implemented by all DisplayObjects and BitmapData objects. If you pass a BitmapData object however it seems like memory gets allocated based on the size of the render target. This memory is not reused or instantly freed but has to be collected by the garbage collector.

Knowing this there’s a neat workaround: If you wrap the BitmapData in a Bitmap before you draw it you can avoid the bugged code and the memory keeps steady!

//wrap _flare in a Bitmap (do this only once!)
_flareBmp = new Bitmap(_flare);

//now instead of _flare render _flareBmp
for(var i:int = 0; i &lt; 100; i++)
 _buffer.draw(_flareBmp, null, null, BlendMode.ADD);
Jun 14 10

Resource Handling in Flash – Part Two

by pixelpracht

In the last post I showed two approaches to access resources such as sound or image data in Flash. To make resources available to your application you can either load resources one-by-one on demand or embed them all into the main SWF file so they are available as soon as the application has loaded. Both variants however have limitations. So in this post I’m going to show some alternatives.

read more…

Jun 2 10

Resource Handling in Flash – Part One

by pixelpracht

It’s easy to pickup ActionScript3 with a programming background in C++,/C# or Java as the languages shares the same concepts and similar syntax. So, why learn about stages and timelines, keyframes and whatnot when you can write your games like you always did? Well… almost. There are concepts in Flash that require some getting used to. Resources is one of them.

There are two fundamental different ways to get your resources loaded.

One is to embedd all the potentially needed data into your SWF file. This increases the initial loading time but once the application has fully loaded all resources are instantly available, too.

The second option is to send a lean application and load individual resources on demand. This is will reduce the initial load but making things less convenient for the coder and user.

read more…

Mrz 31 10

Flash TMX Parser

by pixelpracht

I’ve created all the key gameplay elements for Rune Hunt and the next step is to build levels to see if they can be used to create fun gameplay. I didn’t want to write my own tools so I searched for a map editor flexible and feature complete enough to meet my requirements. The editor that impressed me the most was the Tiled Map Editor that has comfy features (including Undo!) and exports an xml based level format.

For people interested in using Tiled for their flash game but unsure how to handle the level format I’ve put together a little example. It contains code that parses a tmx file and recreates the data on the flash side in form of custom classes designed to make all the data easily accessible. The code is generic enough to be used in about any AS3 based project. I support XML, CSV, base64 and zlib-compressed base64 encoding.

In my sample I modified a Flixel Framework v2.23 based demo (the original version called FlxCollision is available on githup) to reload the current game state out of a TMX file on keypress. If you run the editor and the swf simultanously you can make changes in the editor, save, switch to the swf, press the Enter key and see the changes taking effect.

Tiled Editor and Demo App

If you’re interested it’s easy to give it a try. No source compiling is required. Just get the files and unzip them somewhere. Then execute the FlxCollisions.swf file found in bin-debug by double clicking it and load the level map01.tmx found in bin-debug/data in the map editor. No restarting of the flash app should be required. Just trigger the reload ingame whenever you changed something!

If you want to use the same approach for your own project all relevant code is included. The interesting parts are found in the PlayStateTmx class where the TMX file is loaded and parsed and then used to populate the FlxState with level content matching the tiles and objects described in the level file. Have fun! :)

Mrz 6 10

Game Preview – Rune Hunt

by pixelpracht

Rune Hunt Preview Screenshot

When I discovered Flixel some months ago I was impressed by the wide range of of quality flash games that had been been developed and released based on it. I gave it a closer look, liked it and started to play around with it. I’ve not had a personal game project for years and had almost forgotten how much fun it is: Working on a project where I have complete creative control, no time constraints and where a broad range of skills are getting challenged. Skills like doing graphics and sound effects, thinking about gamedesign and story – skills that in my day job as a programmer are done by others.

Progress on my game project has been slow (I only work on it a couple of hours a week) but steady and I’m at a point where I’m quite confident that it’s eventually getting released and playable for a larger audience. So why not preview it on my blog?

When I posted the first tech demo of Rune Hunt (a working title that will probably stick) in the Flixel forums I described it like this:

The setup is classic: a hero in a dungeon full of treasure, traps and NPC of questionable attitude. The twist is that I’m limiting the player’s view to what his avatar is seeing. Top-down-ego-perspective so to speak. I hope it’s making exploring the dungeon more interesting and the enemies more scary if you don’t see all the stuff long before it becomes relevant/dangerous.

This is still more or less accurate. The opportunity to take all kind of ideas and concepts that I come up with (about algorithms, about gameplay mechanics, about game design and narrative) and just try them in-game is something I fully embrace and thus I’m really not sure where it all ends. So I won’t linger on describing story or game mechanics – you’ll see it when its done.

“When it’s done” is a pretty lazy approach to project management. It’s also coming with a high risk of never beeing done at all – just think about Duke Nukem Forever. Maybe I could create a more fun game when I’d take a different development approach, when I’d stick closer to what has worked before and apply proven game design practices instead of following a vision that is constantly in flux. But I wouldn’t have more fun creating it that way. And maybe players will like it in the end – despite the lack of standard feedback loops (like competing for highscores or leveling your character or mastering the mechanics to beat the game) that I left out because I am personally bored of them. Maybe others can appreciate what’s there instead: stuff that I considered worth trying out and then good enough to keep it in. I’m curious to see if playing the game will be as much fun as creating it was!

But if not I’m still having plans to extract some value out of it. But that’s another story…

Nov 25 09

Retro 2.0

by pixelpracht

Video games, when created by individuals, often fall into the category retro games: A genre that imitates the style and design of games authored in the early decades of video gaming.

It’s a smart pick. If the hobbyist would try to compete with todays teams of specialists that transform millions of cash into AAA titles he were doomed to fail. But two decades ago team size or money weren’t the limiting factors – the constraints were of technical nature. Back then a talented individual with a good idea could create a state-of-the art game. And thanks to better tools, better learning resources and faster computers all these games are perfectly doable now for anyone willing to learn how. Pick this niche and suddenly you’re on a level with the competition.

Despite all the limitations the old games were fun and often still are. Fun has nothing to do with photorealism. Reading a Book can be a compelling experience – because the story is unfolding in the mind of the reader. When a couple dozen abstract black symbols used in alternation can achieve that how could eye-candy and sourround sound be a critical factor in games?

At the core of any good game is the gameplay and/or narration. And to get that right you don’t need a lot of resources. Quite the opposite: The games industrie is often critizised for its lack of innovation. And when a multi-million dollar budget is at stakes you really can’t make experiements. When you have “asset pipelines” and the likes it’s hard to establish a shared vision of what exactly you want.

I think it’s still possible for individuals or a small groups to create games that matter. Thinking “retro” might help. But instead of recreating what has been done before rather copy the concept:

  • Focus on gameplay and narration
  • Build your game around a key idea
  • Think about efficient reuse of resources
  • Use the players imagination to fill the gaps

There are vantages to being independent. And there are possibilities far beyond those available decades ago. Contrasting this the indie movement in it’s current state is – with exceptions – still rather insignificant.

Nov 15 09

What I like about Flixel

by pixelpracht

I’m amazed how many flash games not only have the visual style but also the gameplay of the games of past decades. While there are good reason for pixelated graphics I’d really love to see a more variety in gameplay and presentation.

The technical limitations of the past are gone. Is there a reason not to have physics, particles, dynamic lighting, line of sight or shadows, AI driven enemys, complex simulations and cooler stuff that I can’t even think of in the games? No, not even when we’re talking about Flash games. Why we’re not seeing more of this stuff is because this technology is not made easily available to developers by the toolkit they’re working with.

A great example for the sleeping potential is the flash port of the Box2D physics engine that got released in September 2007. Even though it’s a pretty straight forward port that’s not optimized for flash at all a flood of games got released since, featuring completely new gameplay or enriching established genres with physics. The basis of a good game is a good choice of engine, tools and middleware.

A flash game engine on the rise (just my subjecitve impression) is Flixel. A game Fathom that the author of Flixel developed with it caught my attention: It’s not not only extremely polished but also had a surprising story-twist and unique elements like a fish swarm guiding your way, dynamic gameplay-relevant lighting and beautiful particle effects…

This speaks for the author’s talent but also for the engine. And based on how well Flixel is embraced by the community it’s apperently also easy to use unlike PBE a flash game engine I’ve been working with. I think “ease of use” is really a key factor for any tool or software targeting the hobbyist. Game development should be about asking what while most people seem to struggle with the how. I’d wish for game development to be as accessible as painting a picture or writing a story. In it’s current sate it’s a form of media that most can only consume not express themselves with. The crucial step of evolution would be to overcome this barrier. Everything that helps that goal has my sympathy and that it seems like a step in the right direction is what I like about Flixel.