I'll start with a warning: this tutorial is not for the absolute beginner. You will need the AIR/Flex SDK, Microsoft Visual Studio, familiarity with C++ coding and be comfortable creating packages via the command line. Also, while I'm comfortable with Flash and ActionScript, I am definitely not an authority on C/C++ so there may be other (better) ways to do some things. Of course, if you happen to be an authority on that stuff, please feel free to suggest improvements! Ok, with the initial disclaimer out of the way, let's go ahead and get our hands dirty!

Setting up the C++ project

To begin, you'll need to have Microsoft Visual C++ 2010; and yes, the free Express edition is just fine. Once you've got that installed (and any necessary updates) go ahead and open it up and start a new project. We want to create a Win32 project so select that and give it the name NativeAdd.

Select Next and on the following screen, under Application Type, choose DLL (Dynamic-Link Library) and click Finish.

Great! The C++ project has been created! The next step is to make a few changes to the code; open up dllmain.cpp and the top of the file remove the following line:

#include "stdafx.h"

and replace it with this:

#include <Windows.h>

After that, let's go to the DllMain function and remove the entire switch statement so that the only code left in the function is: return TRUE;

The dllmain.cpp file should now look like this:

#include <Windows.h>

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved )
{
    return TRUE;
}

Now turn your attention to NativeAdd.cpp and remove the line: #include "stdafx.h"

The next thing we'll do is get rid of the extra files automatically added to the project by Visual Studio. In the solution explorer, open the Header Files folder and right click the stdafx.h file and select Remove. Go ahead and just click remove again if you get a popup box. Do the same to targetver.h and also stdafx.cpp in the Source Files folder.

The next step is to add a few files. First, we'll add NativeAdd.h to the Header Files folder. To do so, right click the Header Files folder and select Add > New Item. Select Header File from the list and name it NativeAdd.h.

Now we'll grab some necessary files from the Flex SDK and add them to our project. Navigate to the Flex SDK directory and enter the include directory. You'll want to copy the FlashRuntimeExtensions.h file from there. Go back into Visual Studio and right click the Header Files folder, select Add > Existing Item. When the file selection dialog comes up, paste the FlashRuntimeExtensions.h and then select it.

We've got one more file to grab from the Flex SDK so go back to the root folder of the Flex SDK. Navigate to lib/win and copy the FlashRuntimeExtensions.lib file. Right click the NativeAdd project in the solution explorer and select Add > Existing Item and again paste the file in the file selection dialog box and select it to add it to the project. If you've followed along your solution explorer should look like the image below.

We've got just one more thing to take care of before getting into the code. Because we removed the stdafx files, we need to tell the compiler not to look for them. To do this, right click the project file in the solution explorer. Select Properties to bring up the dialog box. Choose Configuration Properties > C/C++ > Precompiled Headers. At the top of the dialog box, change Configuration to All Configurations. Now, in the right-most pane, change the Precompiled Header option to Not Using Precompiled Headers. Use the image below as a guide if you need it.

You can check out my simple demo here, head to the AS3MUL website to learn more about it and download the library from google code.

To see actual multiplayer with the demo either have a buddy sign on with you or just open the demo page in a second browser window/tab.

1 - Pen and Paper
When you get a new project, don't jump straight into coding. I know it is tempting to get started right away, but take some time up front to think about the project. Outline what possible classes you may need to write and what methods those classes should contain. The idea here is to blueprint the project on paper before you get into coding.

Once you have a nice draft down, go over the relationships between various objects and look for any potential problems that may arise during implementation. It's a lot easier to fix these problems on paper as opposed to having to refactor a portion of your code base due to unforeseen snags. With a solid foundation on paper, the actual coding becomes a matter of following directions as opposed to engineering on the fly.

2 - Make a to-do list
Give yourself a goal each day for projects at work. Say to yourself, "ok, today I'm going to get X done." Write it down and then focus on just that one thing until it is complete. All too often developers set out to accomplish a task and end up getting side-tracked with implementing numerous other features and the main task suffers as a result. If you have a specific goal written down and find yourself working on something unrelated, it's a lot easier to drop it and get back to your main objective for the day.

I recommend making a to-do list a few days ahead of time so that you don't waste time in the morning trying to decide what you're going to do that day. Without a to-do list, you don't really have a specific goal and more times than not, this will lead to a wasted day where nothing in particular gets finished.

If you happen to finish your to-do list for a given day early (and most of the time you will), don't get started on the next days' tasks. Instead spend the time cleaning up the existing code, eliminating bugs or adding helpful comments. If you start on tomorrow's tasks today your schedule will begin to fall apart and you'll find yourself wasting time again.

3 - If you're stuck, get away from the computer
We've all hit problems that stump us for a while, but sitting in front of the computer screen for extended hours does little good. At best you'll find yourself with a headache and an inelegant hacked solution based on the confines of the code you've already written.

If you get stuck on something for a while the best thing you can do for yourself, and the project, is to take a bit of a break. Get up and grab a snack or take a walk outside for ten or twenty minutes. This will give you time to think about a real solution and how to implement it... even if that means deleting existing code.

4 - Don't work late
This one goes hand-in-hand with number three. If facing an especially difficult problem you may feel compelled to stay at work until it gets sorted out, but that's probably the worst thing you can do. When you're working late and you're tired you will make poor decisions. You'll end up writing sloppy, bug-riddled code just to get a half-assed solution in place. Instead of forcing yourself to stay late and finish, go home and eat dinner; relax and come in refreshed the next day and start with a fresh approach to the problem.

I can't tell you how many times this has helped me out on projects. One example is a facebook application I was working on at a web agency. Everyone on the team was working late nearly every day and things weren't getting any better. One night we spent an additional eight hours working on a particular feature and had it working, but it was really sloppy code. After going home and getting some sleep, I came in the next day feeling refreshed and in about 30 minutes came up with a much cleaner and easier solution for implementing the feature. Essentially the previous night's eight hours of work was completely useless; we deleted the code and implemented the new method before 10:00 AM.

5 - Stop doing freelance work
Freelance work can be a nice secondary source of income for many of us. However, it can also be a major source of added stress and will suck up valuable time that could be used doing something you really enjoy. If you can afford it, I recommend dropping the freelance gigs. Instead focus on your own projects. Make your own mobile apps or websites or whatever it is you want to make. You may not make as much money, but you'll probably be a lot happier. And who knows, perhaps one of your projects will make it big!

6 - Do a little every day
Sometimes just thinking of a project as a whole can be overwhelming, but you don't have to kill yourself to get your projects done. Instead of going for marathon coding sessions on personal projects, try doing just a little each day. Even if you set aside just one hour each evening you can still accomplish a lot; especially if you keep the other items on this list in mind. It may take a while to finish a project, but getting those small victories will help keep you motivated from day to day and you can certainly work more if you really want to!

The key here is to make sure you don't take a day off because if you take one day off, you're likely to take two and so on.

7 - KISS (Keep it simple, smarty)
Yes, I know most people end this with "stupid" but I don't think that makes much sense. What's more stupid: going with a simple, straight-forward approach or over-complicating things and giving yourself unnecessary headaches? I submit that the simple, straight-forward approach is the smarter of the two.

If you find yourself writing a big mess of code thinking "there's gotta be a better way of doing this" then there probably is. Stop what you're doing and reevaluate the problem. Try breaking it down into simpler sub-problems and start from there.

I had a great time today at Barcamp Orlando! I saw quite a few interesting and funny talks and was able to grab a speaking slot for my presentation on working a more efficient 4 day, 32 hour work week. It seemed to go over really well; there were some great questions and feedback from the audience.

I've put the presentation online if you want to look over the slides. However, I'm not sure you'll get much out of them without the talk to give some context. They were more or less just shorthand notes so I could remember what to talk about next.

The presentation is tentatively titled A Better Work Week and goes into the details about the benefits of working a 4 day, 32 hour week instead of the standard 5 day, 40 hour week.

This is something that I feel strongly about and I hope the idea can gain some momentum in the US. If you're in the area please drop by and check it out!

You can play the game now on Newgrounds.

As for iOS, I will also be making an update there in the next couple of weeks. It takes a lot longer to get stuff published with Apple.

The 9% fee from the premium license applies only to Flash Player-based games that utilize both Stage3D and Alchemy. Furthermore, it only comes into effect if said game manages to pull in $50,000 or more in revenue. Anything packaged with AIR is exempt. This means anything you do for mobile does not require a fee.

I've been developing with Flash for quite a while now and nothing I've ever built has met the requirements for paying the 9% fee. And perhaps more to the point, nothing I plan on building in the future would incur a fee either.

Unless you're a major game developer (think EA) it's pretty safe to assume this announcement does not apply to you or any Flash projects you're planning on building.

As Richard Davey said on Twitter: "All everyone will take-away is the '9%' headline and ignore the fact it applies to not one single game yet"

HTML5 and Apple zealots will likely continue to make a big scene about this, but hopefully now you understand that this is really not a big deal and perhaps cooler heads will prevail. For another voice on the matter, check out Lee Brimelow's recent post in which he explains the situation.

I'm pleased to announce the release of my first Flash game of the year: Night of the Loving Dead.

I've spent the last couple months creating this game and am overall pretty happy with it. It also represents my first Flixel-based project and I was really impressed with the Flixel engine. Give it a shot and let me know what you think!

The first thing you need to know about this technology is that it is not readily available just yet. To get this to work, you'll need to download the developer build of Google Chrome, called Canary. Once Canary is installed, open it up and type "about:flags" in the address bar. Find the MediaStream option and click Enable; you'll need to close and reopen the browser for this change to take effect.

To test if it's working (and to preview what we will be building here), use Canary and head here to see if the stream comes through. Note that you will be prompted to allow access to your camera.

With MediaStream enabled, we can now move onto the code. We'll begin by laying out a simple HTML file.

<!DOCTYPE html>

<html>

    <head>
        <title>webRTC Test</title>
    </head>

    <script type="text/javascript">

    </script>

    <body onload="init();" style="background-color:#ababab;" >
        <div style="width:352px; height:625px; margin:0 auto; background-color:#fff;" >
            <div>
	            <video id="camFeed" autoplay>
		        </video>
	        </div>

            <div>
                <canvas id="photo" width="352" height="288">
                </canvas>
            </div>

            <div style="margin:0 auto; width:82px;">
                <input type="button" value="Take Photo" onclick="takePhoto();">
            </div>
        </div>

    </body>
</html>

As you can see, we've got a fairly standard HTML document here. At the top we've got an empty script block which we'll be filling out in just a bit. I've just inlined the css styles for this example because there isn't much to it. When the body tag loads, it will call a function, init, which we haven't written just yet. The init function will be responsible for determining if the user's browser supports webRTC or not.

Within the body we've got a simple wrapper div that holds all the content. Inside there we have another div that contains a video tag. The video tag is where the webcam feed will be rendered.

Following the div containing the video tag is another div. This one holds a canvas element. This canvas element is where we will display the photo that gets taken. It is important to note that I set the width and height attributes of this tag directly and not through css. This is because HTML5 will actually scale and stretch a canvas element when the width and height are set using css. Some people think this is a nice feature; I just think it's stupid, but that's how it is.

You may also have noticed that the width and height of the canvas element are a bit random (352, 288). I came up with those values after seeing the webcam feed was being rendered at that size in the video tag. You may need to adjust these values according to your camera.

After closing the div containing the canvas element, we create one more div. This one holds a standard button that when clicked will call a javascript function, takePhoto. This method will be responsible for rendering the photo in the canvas element.

It is now time to get to the javascript. Add the following code inside the empty script block we created above.

function init()
{
    if(navigator.webkitGetUserMedia)
    {
        navigator.webkitGetUserMedia('video', onSuccess, onFail);
    }
    else
    {
        alert('webRTC not available');
    }
}

function onSuccess(stream)
{
    document.getElementById('camFeed').src = webkitURL.createObjectURL(stream);
}

function onFail()
{
    alert('could not connect stream');
}

There really isn't a whole lot to it. In the init function we first check to see that the browser supports webRTC. If not, we throw up an alert letting the user know that it is not supported. If it is, we use a call to webkitGetUserMedia to get things going. We tell it we're using video and then give it a function to call upon successful stream creation and another to call if it fails.

Note that the webkit vendor prefix may or may not be necessary depending the browser (Opera, for example). Once standardized, the method should become just: getUserMedia. However, it isn't there yet and because we're using Canary, we need it.

In the onFail function, we just send an alert to the user letting them know that something went wrong and we were unable to connect a stream to the video tag. In onSuccess, we receive a stream as an argument. We then create an object URL for the stream and apply it to the src property of our video tag.

We're just about done now. All that's left to do is write the takePhoto function to copy an image to the canvas element. Add the following method just after the onFail function we created above.

function takePhoto()
{
    var c = document.getElementById('photo');
    var v = document.getElementById('camFeed');
    c.getContext('2d').drawImage(v, 0, 0);
}

It's that easy! We just grab a reference to our canvas tag and also to our video tag. We then get a 2D rendering context from the canvas and call the drawImage function. We tell it what to draw, the video element, and where to draw it (0,0).

That's it; we're done. This works...but probably not if you try running it locally! This is due to a security restriction in Canary. You can push the file to a web server and it should run fine as long as you enabled the MediaStream flag earlier (with Canary). When you navigate to the page you should be prompted to allow access to your camera. Obviously you should allow it if you want to see this working!

If you don't have access to a web server, don't worry, you can still run the file locally too. You just have to run Canary with another flag set: --allow-file-access-from-files. You can do this by opening a command prompt window and navigating to the directory where Canary was installed. On my Windows 7 machine, the command looks like this:

cd C:\Users\USERNAME\AppData\Local\Google\Chrome SxS\Application

Then just launch the canary exe with the following command:

chrome.exe --allow-file-access-from-files

When you open the file locally, you'll know it's not going to work if you see: "null wants to use your camera." If instead you see "file:// wants to use your camera" you're in good shape.

It's worth pointing out that while this functionality is new to Chrome, it was actually available last year in Opera's development browser.

That's all there is to it; I hope you had fun with this tutorial and I encourage you to keep an eye on webRTC in the future. I imagine it should be readily available on all major browsers by the year's end, but we'll have to wait and see.