May 10, 2011 Posted on May 10, 2011 in Hints and Tips | 1 comment

Win a Free MacBook Pro and $1,000 in Printing From UPrinting

Hello everyone! Today we’ve got a special treat for you. Our friends at UPrinting are giving away a free 13 inch MacBook Pro (valued at $1,199) and $1,000 worth of printing to 1 lucky Tuts+ reader. To win, all you have to do is answer a simple question and submit it using the form below.

While I am sure most of you are skimming through this text to find details on how you can enter, we would like to tell you a bit more about UPrinting before you do. UPrinting is a socially responsible online printing, marketing and technology firm with a distinct vision and clear approach to helping small businesses grow. It serves thousands of on-demand printing orders online daily, using high-quality printing presses and a robust yet simple and easy-to-use online ordering system, resulting in high-end printing at low costs.

They also offer cool print products, such as postcards, that could help you send out your artworks to friends and clients. That’s an awesome way to inspire and connect with people!

UPrinting.com has earned customer loyalty by offering more customizable options than other online printer. The company is popular for its Free File Review, a complimentary proofing service that requires no upfront payment. UPrinting.com also offers convenient marketing support such as design services and direct mailing to help the small or medium-sized business grow.

Ok, now that you know a bit more about UPrinting, now I am sure you are wondering a bit more about this giveaway. As stated in the intro, UPrinting is giving away a 13 inch MacBook Pro (valued at $1,199) and $1,000 in printing services to 1 lucky reader. To enter, all you need to do is answer the following question and submit it by following the link below.

Which UPrinting print product do you find most useful? Why?

* Please note that we will be sharing your name and email address with UPrinting. This means that you may receive emails from them after the conclusion of this giveaway. If you’re ok with this, you may submit your entry by following the link above.

---

The Prizes

• 1 MacBook Pro (valued at $1,199) Specs: 13-inch, 2.3 GHz, 2.3GHz dual-core, Intel Core i5, 4GB 1333MHz, 320GB 5400-rpm1, Intel HD Graphics 3000, Built-in battery.
• $1000 in printing credits from UPrinting. Valid for one-time use, applicable to printing cost only.

---

Rules

• Fill out this form. Tell us which UPrinting print product you find most useful and why.
• You may only enter once. Anyone submitting more than once will be disqualified.
• Make sure to enter a valid email address so that we can contact you.
• Entries will be accepted until Monday, June 6, 2011 at 11:59 PM, EST.
• Giveaway is open to all jurisdictions.
• You must be of legal age in the jurisdiction that you reside to enter.
• Giveaway is void where prohibited.
• MacBook Pro shipping free.
• Shipping for printing services is free for U.S. residents. Non U.S. residents must pay for shipping for printing services.
• Follow UPrinting on Twitter of Facebook (Optional)
• Your name and email will be shared with UPrinting at the conclusion of this giveaway. By submitting your entry you consent to receiving correspondence from them.

View full post on Activetuts+

May 9, 2011 Posted on May 9, 2011 in Hints and Tips | 10 comments

Win a Copy of “Flash Game Development by Example”!

They’re at it again! This week Packt Publishing are giving away 3 copies of Flash Game Development by Example to Activetuts+ readers! Read all about it in our interview with author Emanuele Feronato then find out how to get your hands on a copy…

---

So.. How do I Enter?

Three random followers will be chosen to win a copy. To enter, all you’ve gotta do is follow @envatoactive on twitter then leave your twitter username in the comments below!

---

Flash Game Development by Example

The book starts with simple well known puzzle games: Concentration and Minesweeper. After learning the basics of game design you’ll introduce AI with a four-in-a-row game. Then as you build your own versions of old arcade games such as Snake, Tetris, and Astro Panic. The book ends with a collection of modern casual classics.

Make sure to include your correct email address with your comment so that we can contact you. This giveaway is open worldwide, but make sure to get your comment in before midnight this Friday, Pacific Eastern Standard Time.

More information about “Flash Game Development by Example” can be found on the Packt Publishing website.

Please note: Envato staff, reviewers and authors who have written more than two tutorials/articles for a Tuts+ site are not eligible to enter.

View full post on Activetuts+

May 9, 2011 Posted on May 9, 2011 in Hints and Tips | 3 comments

Using Native Multitouch Gestures in ActionScript 3.0

In this tutorial, we’ll learn how to implement native multitouch gestures to use in your applications. Read on!

---

Final Result Preview

Let’s take a look at the final result we will be working towards:

Note: This example will work only on Multitouch devices (Tablets, Smartphones, Touch Screen Computers and Multitouch trackpads under AIR).

Note for Android users: Multitouch won’t run in the SWF embedded in an HTML page in an Android browser, but the Source download does include an APK you can use to check it out. (Please note that the APK is just for the purpose of a quick demonstration of the gestures themselves, and does not display entirely correctly.)

You can pinch to zoom, spin to rotate, and swipe to change the image. Check out the video demo if you’re unable to test the preview on your device:

---

Step 1: Brief Overview

We’ll use the native Multitouch support built in to the Flash Player to create a gesture-based image application.

---

Step 2: Flash Document Settings

Launch Flash and create a new document. Set the stage size to 600x300px, and the frame rate to 24fps.

---

Step 3: Interface

The interface will be very simple, just an image in the stage that will be then modified by the gestures.

---

Step 4: Get Some Images

We’ll need some images to test our application, choose them from your personal collection or download a few for testing.

These are the images from the demo, obtained from Flickr, all with a Creative Commons License.

Grass 01 by 100kr

deep impact on planet color by spettacolopuro

Yosemite : fall colours by tibchris

Flower by Antonio Manchado

---

Step 5: Export For ActionScript

Convert one of the images to a movie clip, and add the rest of the images to that clip in different frames. Name the clip SlideItem and mark the Export for ActionScript box.

---

Step 6: TweenNano

We’ll use a different tween engine from the default included in Flash, this will increase performance as well as being easier to use.

You can download TweenNano from its official website.

---

Step 7: New ActionScript Class

Create a new (Cmd + N) ActionScript 3.0 Class and save it as Main.as in your class folder.

---

Step 8: Class Structure

Create your basic class structure to begin writing your code.

package
{
	import flash.display.Sprite;

	public class Main extends Sprite
	{
		public function Main():void
		{
			// constructor code
		}
	}
}

---

Step 9: Required Classes

These are the classes we’ll need to import for our class to work, the import directive makes externally defined classes and packages available to your code.

import flash.display.Sprite;
import flash.display.MovieClip;
import flash.ui.Multitouch;
import flash.ui.MultitouchInputMode;
import flash.events.TransformGestureEvent;
import com.greensock.TweenNano;
import com.greensock.easing.Strong;

---

Step 10: Variables

These are the variables we’ll use, read the comments in the code to find out more about them.

private var slideItem:SlideItem; //The object that will be affected by the gestures
private var tempContainer:Sprite; //An empty sprite that will store the slide item

---

Step 11: Constructor

The constructor is a function that runs when an object is created from a class, this code is the first to execute when you make an instance of an object or runs using the Document Class.

It performs the necessary actions to start the application.

public final function Main():void
{
	//Code
}

---

Step 12: Enable Gestures Input

This line tells the Flash Player to identify the multi-touch mode for touch and gesture event handling.

Multitouch.inputMode = MultitouchInputMode.GESTURE;

Read more about this on help.adobe.com.

---

Step 13: Slide Item

Let’s instantiate the images that will respond to the gesture events.

slideItem = new SlideItem();
/* Prevents the image from changing */
slideItem.stop();
/* Center the image */
slideItem.x = stage.stageWidth * 0.5;
slideItem.y = stage.stageHeight * 0.5;

addChild(slideItem);

listeners('add', slideItem); //see next step

---

Step 14: Add Listeners

This function adds or removes the gesture listeners depending on the specified parameter.

private final function listeners(action:String, target:Sprite):void
{
	if(action == 'add')
	{
		target.addEventListener(TransformGestureEvent.GESTURE_ZOOM, onZoom);
		target.addEventListener(TransformGestureEvent.GESTURE_ROTATE, onRotate);
		target.addEventListener(TransformGestureEvent.GESTURE_PAN, onPan);
		target.addEventListener(TransformGestureEvent.GESTURE_SWIPE, onSwipe);
	}
	else
	{
		target.removeEventListener(TransformGestureEvent.GESTURE_ZOOM, onZoom);
		target.removeEventListener(TransformGestureEvent.GESTURE_ROTATE, onRotate);
		target.removeEventListener(TransformGestureEvent.GESTURE_PAN, onPan);
		target.removeEventListener(TransformGestureEvent.GESTURE_SWIPE, onSwipe);
	}
}

This means that the listeners() function called in the previous step will add event listeners to the sliding image, to make it listen for zooming, panning, rotating, and swiping gestures.

---

Step 15: Pinch to Zoom

This function responds to the well known pinch gesture. It handles the image zoom in and zoom out.

private final function onZoom(e:TransformGestureEvent):void
{
	/* Use the event data to scale the target image */
	e.target.scaleX *= e.scaleX;
	e.target.scaleY *= e.scaleY;
}

---

Step 16: Spin to Rotate

Rotation is handled by this function, two fingers are used to spin the image in the stage.

private final function onRotate(e:TransformGestureEvent):void
{
	/* Use the event data to rotate the target image */
	e.target.rotation += e.rotation;
}

---

Step 17: Slide to Pan

The Pan function is used to move the image to see parts that are off-stage.

private final function onPan(e:TransformGestureEvent):void
{
	e.target.x += e.offsetX;
	e.target.y += e.offsetY;
}

---

Step 18: Swipe to Swap

This function is a little bigger due to the four swipe directions available. The gesture is similar to that from the previous step, but firmer, and instead of simply moving the image around, it swaps it for a different image.

It first checks if a previous item is on the stage and stores it in a container in order to tween it and be able to remove it later. Then, the offset property is read to determine the direction of the swipe, showing the corresponding animation and image.

private final function onSwipe(e:TransformGestureEvent):void
{
	/* Check if image is on stage */

	if(slideItem != null)
	{
		tempContainer = new Sprite();
		tempContainer.addChild(slideItem);
		addChild(tempContainer);
	}

	/* Change Images */

	if(e.offsetX == 1)
	{
		//right
		slideItem = new SlideItem();

		slideItem.gotoAndStop(1);
		slideItem.x = -slideItem.width;
		slideItem.y = stage.stageHeight * 0.5;

		listeners('add', slideItem);
		addChild(slideItem);

		TweenNano.to(tempContainer, 0.5, {x:stage.stageWidth, onComplete: removeLast});
		TweenNano.to(slideItem, 0.5, {x:stage.stageWidth * 0.5});
	}
	if(e.offsetX == -1)
	{
		//left
		slideItem = new SlideItem();

		slideItem.gotoAndStop(2);
		slideItem.x = stage.stageWidth + slideItem.width;
		slideItem.y = stage.stageHeight * 0.5;

		listeners('add', slideItem);
		addChild(slideItem);

		TweenNano.to(tempContainer, 0.5, {x:-slideItem.width, onComplete: removeLast});
		TweenNano.to(slideItem, 0.5, {x:stage.stageWidth * 0.5});
	}
	if(e.offsetY == -1)
	{
		//up
		slideItem = new SlideItem();

		slideItem.gotoAndStop(3);
		slideItem.x = stage.stageWidth * 0.5;
		slideItem.y = stage.stageHeight + slideItem.height;

		listeners('add', slideItem);
		addChild(slideItem);

		TweenNano.to(tempContainer, 0.5, {y:-slideItem.height, onComplete: removeLast});
		TweenNano.to(slideItem, 0.5, {y:stage.stageHeight * 0.5});
	}
	if(e.offsetY == 1)
	{
		//down
		slideItem = new SlideItem();

		slideItem.gotoAndStop(4);
		slideItem.x = stage.stageWidth * 0.5;
		slideItem.y = -slideItem.height;

		listeners('add', slideItem);
		addChild(slideItem);

		TweenNano.to(tempContainer, 0.5, {y:slideItem.height, onComplete: removeLast});
		TweenNano.to(slideItem, 0.5, {y:stage.stageHeight * 0.5});
	}
}

---

Step 19: Remove Last Slide Item

When the animation is finished, the item offstage is destroyed to save memory.

private final function removeLast():void
{
	listeners('remove', tempContainer.getChildAt(0) as Sprite);
	removeChild(tempContainer);
	tempContainer = null;
}

---

Step 20: Set Main Class

We’ll make use of the Document Class in this tutorial, if you don’t know how to use it or are a bit confused please read this Quick Tip.

---

Conclusion

Gestures add a nice touch and and offer great interaction in your application, use them!

Thanks for reading this tutorial, I hope you’ve found it useful!

View full post on Activetuts+

May 8, 2011 Posted on May 8, 2011 in Hints and Tips | 10 comments

Create Your Own Pseudo 3D Pong Game

Twice a month, we revisit some of our readers’ favorite posts from throughout the history of Activetuts+. This tutorial was first published a long time ago in May, 2009.

In this tut I’ll describe how to create a basic 3D scene using the native 3D options of Flash Player 10. Then I’ll explain how to add interactivity to the elements and set up a basic pong game. Let’s go..

---

Step 1: Setting the Scene

Let’s set up the stage and create the 3D scene. In a regular pong game the ball bounces off the top and bottom of the screen, but since we’re adding some perspective to the mix we’ll need to provide these borders too. There are five movieclips needed: the floor and the four walls (two of which are actually paddles). The registration points of the walls should all be located against the floor. You can create all of these simply with the rectangle tool or use an imported bitmap image (remember to turn on "Allow smoothing" in the properties). Make a movieclip out of each of the walls and give them an instance name (I named them "wallTop", "wallBottom", "wallLeft" and "wallRight" and will refer to them later). Name the background "floor".

Select all the walls and the floor, create one big movieclip out of those and name it "bg".

To display the score later on we’ll also need two dynamic text fields. If you place these within the "bg" movieclip they’ll also have the 3D perspective. Name these "scoreLeft" and "scoreRight" then embed the fonts.

---

Step 2: Ball Creation

Create the ball using the oval and gradient tool on the stage. Don’t place the the ball inside the "bg" movieclip or it will be distorted by the perspective. We won’t give the ball actual 3D properties but make it act as if it was 3D. Place the ball in the center of the screen and give it an instance name like "ball".

---

Step 3: Document Class

Now we’ll set up the 3D scene by using the new rotationX, Y and Z properties that were added in Flash Player 10. However, before we can execute some ActionScript code we need to create the document class. Create an empty Main.as and fill it with the code below.

package
{
	import flash.display.MovieClip;

	public class Main extends MovieClip
	{
		public function Main() : void
		{
			// Replace this comment with code later
		}
	}
}

Now to use this as the main class we can fill in "Main" in the "Class:" input box of the documents properties.

---

Step 4: Rotation

Let’s try out the rotation. Add this line to the Main() function to give everything some perspective:

bg.rotationX = -30;

As you can see, all movieclips are now rotated 30° around the x-axis.

Each of the walls needs a 90° rotation to stand up. As you can see I’ve also changed the blending mode of the walls to "screen" so the gradients look better. The following code is only for preview purpose as we’ll replace it by tweens in the next step (so take it out after testing).

bg.wallTop.rotationX = 90;
bg.wallBottom.rotationX = -90;
bg.wallRight.rotationY = 90;
bg.wallLeft.rotationY = -90;

---

Step 5: Start Function

To add an effect to the walls we’ll first need to create a start button. Create a movieclip with the text "Click here to start". Again, you can place this inside "bg" if you want it to have perspective too. Give it an instance name like "startText". We can now reference it in the code and add an eventlistener to it. Also set buttonMode to true which will return a hand cursor when the mouse hovers over the button. When clicked, the start function is called and the button is hidden. We also hide the mouse pointer because the user will control the right wall with the mouse.

public function Main() : void
{
	bg.rotationX = -30;
	startText.addEventListener( MouseEvent.MOUSE_UP, start );
	startText.buttonMode = true;
}
private function start( _e : Event ) : void
{
	startText.buttonMode = false;
	startText.visible = false;
	Mouse.hide();
	// This will contain the tweens
}

---

Step 6: Tweening

We can use TweenLite to tween the walls from 0 to 90° rotation. Of course any tweening engine will do, but I prefer this one. The following code will tween the walls in 2 seconds and use the "Bounce.easeOut" easing function. To tween the alpha value of the walls as well we need to set it to 0 first. You can do this in Flash by setting the alpha to 0 in the color settings. After these tweens are completed the game should start, so add an "onComplete" property to one of the tweens and attach a function name to it (you can leave this out for testing since the function doesn’t exist yet).

private function start( _e : Event ) : void
{
	startText.buttonMode = false;
	startText.visible = false;
	Mouse.hide();
	new TweenLite( bg.wallRight, 2, { rotationY: 90, alpha: 1, ease: Bounce.easeOut } );
	new TweenLite( bg.wallLeft, 2, { rotationY: -90, alpha: 1, ease: Bounce.easeOut } );
	new TweenLite( bg.wallTop, 2, { rotationX: 90, alpha: 1, ease: Bounce.easeOut } );
	new TweenLite( bg.wallBottom, 2, { rotationX: -90, alpha: 1, ease: Bounce.easeOut, onComplete: goBall } );
}

---

Step 7: Paddles

Before we can actually start the game we’ll need to add interactivity to the left and right walls and the ball. Let’s start with the player’s paddle. Create a new class "Player.as" and add the following code.

package
{
	import flash.display.MovieClip;
	import flash.events.MouseEvent;

	public class Player extends MovieClip
	{
		public function Player() : void
		{
			stage.addEventListener( MouseEvent.MOUSE_MOVE, moveAlong );
		}

		private function moveAlong( _e : MouseEvent ) : void
		{
			var mousePos : Number = stage.mouseY - parent.y;
			if ( mousePos < 0 )
				y = 0;
			else if ( mousePos > 340 )
				y = 340;
			else
				y = mousePos;
		}
	}
}

In the constructor (the Player function) we add an eventlistener to the stage to check when the mouse moves and call the "moveAlong" function whenever it does. In the moveAlong function we calculate the local position of the mouse (just the y position since we’re only moving vertically). Next we check whether the mouse goes out of bounds and reset the position if it does. I found the 340 value by trial and error since "parent.height – height" does not return the expected value when we use 3D perspective.

Next change the properties of the wallRight movieclip; check "Export for ActionScript" and set the Class to "Player". Leave "Base Class" empty.

---

Step 8: Opponent (AI)

Creating the AI is very similar to creating the player. Only this time we’ll make it move towards the y value of the ball but with a slightly lower speed than the ball. Create another class "AI.as":

package
{
	import flash.display.MovieClip;
	import flash.events.Event;

	public class AI extends MovieClip
	{
		public function AI() : void
		{
			addEventListener( Event.ENTER_FRAME, followBall );
		}

		private function followBall( _e : Event ) : void
		{
			var ball : MovieClip = MovieClip( parent.parent ).ball;
			if ( ball.xspeed || ball.yspeed )
			{
				var newy : Number = ball.y - height;
				if ( newy > 345 )
					newy = 345;
				if ( y <= newy )
					y += 9;
				else
					y -= 9;
			}
		}
	}

}

First we need to be able to reference the ball. Since the wallLeft movieclip is inside the "bg" movieclip, calling "parent" would reference to "bg". For this reason we need to use "parent.parent". The first "if" statement checks if the ball has an x or yspeed. These are public variables of the ball we’ll set later. The check prevents the AI from moving before the game starts. The "newy" value holds the y value of the ball minus the height of wallLeft. This is the value to which it should move to hit the ball. As before, change the Class of wallLeft to "AI".

---

Step 9: Ball Functionality

The ball needs the most functionality: it needs to move around, bounce off walls, check for a hit with the paddles and update its own depth since it’s not a 3D object.

package
{
	import flash.display.MovieClip;
	import flash.events.Event;

	public class Ball extends MovieClip
	{
		public var xspeed : Number = 0;
		public var yspeed : Number = 0;

		public function Ball() : void {	}

		public function start() : void
		{
			xspeed = -12;
			yspeed = 12;
			addEventListener( Event.ENTER_FRAME, moveBall );
		}

		private function moveBall( _e : Event ) : void
		{
			depth();
			collision();
			x += xspeed;
			y += yspeed;
		}

		private function depth() : void
		{
			// Scale the ball based on its y position
		}

		private function collision() : void
		{
			// Make the ball bounce
		}
	}

}

First off we give the ball an x and yspeed. These are set to public so we can check from other objects whether the ball is moving. Next add an "onenterframe" eventlistener to the start function. When the start function is called the ball will start moving every frame. I gave the ball a starting speed of 12 pixels per frame. You can change this to speed up the game but you could also up the framerate. The moveBall function actually hightens the x and y values of the ball based on the x and yspeed. It also calls the depth and collision functions on every frame.

---

Step 10: Ball Perspective

Because the ball is not a 3D object and has no z value it will not appear smaller once the y value changes. The higher the ball gets on screen (low y value), the smaller it should appear. We can change this by simply scaling it based on its position:

private function depth() : void
{
	var smaller : Number = (( y / stage.stageHeight ) * 0.6) + 0.6;
	scaleX = scaleY = smaller;
}

---

Step 11: Collision Course

The "collision" function will decide how and when the ball will bounce off other objects. In the first "if" statement we simply check the y value to find out if the ball hits the top or bottom wall. Again I found these values by trial and error because the ball needs to bounce off in a plausible fashion. If the check is true it results in changing the yspeed so the ball changes vertical direction.

private function collision() : void
{
	if ( y >= 463 || y <= 105 )
	{
		yspeed *= -1;
	}

Checking the x borders isn’t as easy because of the perspective and paddles that move around. We can perform a "hitTest" with the walls and send the ball back if true. HitTests are a bit cpu heavy so it’s best not to overuse them. However, because we’re dealing with a simple pong game it won’t noticeably slow down the game. I did add an extra check though; to see if the ball’s x value is on the left or right side of the stage and check the wall accordingly. This makes sure there’s only one hitTest needed per frame instead of two.

	if( (x > stage.stageWidth / 2 && hitTestObject(MovieClip(parent).bg.wallRight)) || (x < stage.stageWidth / 2 && hitTestObject( MovieClip(parent).bg.wallLeft)) )
	{
		xspeed *= -1;
	}

Lastly we need to find out if the ball is still on the platform. We can find out by checking if a point on the bottom of the ball is still located on the "floor". The exact point has the ball’s x value and the y plus radius value. If this is true we find out whether the ball went off on the left or right side (again by comparing the x value to the center of the screen) and update the score accoringly. At the end, set the x and y values of the ball back to the center so the game can continue.

	if ( !MovieClip(parent).bg.floor.hitTestPoint( x, y + (height / 2 * scaleY), true) )
	{
		if ( x < stage.stageWidth / 2 )
			MovieClip(parent).bg.scoreRight.text = Number(MovieClip(parent).bg.scoreRight.text) + 1;
		else
			MovieClip(parent).bg.scoreLeft.text = Number(MovieClip(parent).bg.scoreLeft.text) + 1;
		y = stage.stageHeight / 2;
		x = stage.stageWidth / 2;

	}
}

Change the Class of the ball to "Ball".

---

Step 12: Action!

Now that we’ve created both the paddles and the ball, all that’s needed is to set the game in action. Add this function to the Main class and make sure the onComplete we used in step 6 references this function.

private function goBall() : void
{
	ball.start();
}

---

Step 13: Adding Bounce

After the score has been updated, the ball just returns to the center and starts rolling again. We need to animate the ball slightly when coming back before the game starts again.

Replace this code in the collision function of the ball:

y = stage.stageHeight / 2;
x = stage.stageWidth / 2;

By:

xspeed = yspeed = 0;
removeEventListener( Event.ENTER_FRAME, moveBall );
y = -height;
x = stage.stageWidth / 2;
var scale : Number = (0.5 * 0.6) + 0.6;
new TweenLite( this, 1.5, { y: stage.stageHeight / 2, scaleX: scale, scaleY: scale, ease: Bounce.easeOut, onComplete: start } );

This will stop the ball from moving first. Next it sets the position of the ball just above the screen but horizontally centered. If we then use the Bounce easing function it will appear as if the ball drops down from above just before restarting the game.

---

Conclusion

I hope you were able to follow along without too many problems. The game as it is now is very basic and can use some improvements. The ball, for example, always bounces 90° corners which makes the movement very predictable.

If you’d like to take it further you could try varying the x and yspeed based on where the ball hits the paddle (compare the y values). The collision detection with the paddles is nowhere near perfect but does show you a basic way of checking for a hit. Lastly, if you didn’t use gradients for the walls you will notice the ball seems to roll over the bottom wall instead of dissapearing under it. To fix this, you can easily seperate objects that should appear over the ball and place those in a new movieclip which you distort as much as the "bg" movieclip and arrange higher than the ball in Flash.

View full post on Activetuts+

May 8, 2011 Posted on May 8, 2011 in Hints and Tips | 2 comments

Interview With Untold Entertainment’s Ryan Henson Creighton

Ryan Henson Creighton has eleven years’ experience in the gaming industry, and founded the Toronto-based game studio Untold Entertainment in 2007. He runs one of my favorite blogs on the whole Internet, covering Flash tutorials, Unity tutorials, game design, conference summaries, and rants. Ryan’s very active on Twitter, and has written an excellent guide to game development with Unity.

He also has all the coins.

---

i’m striving to realize that “build once, deploy anywhere” dream that Adobe hinted at but couldn’t deliver on. Unity doesn’t live up to that promise either, but both platforms get us closer to a place where we developers don’t have to learn a dozen competing technologies just to see our work on different platforms.

The advantage of Unity over Flash is that Unity 3D is a game engine. Flash is not, plain and simple – it’s a content creation tool. In fact, a few months ago, Adobe announced that they were putting together their first on-staff focus group for game development. Their first! This comes after about fifteen years of developers strangling Macromedia/Adobe’s product into something that can play games. This all leaves a sour taste in my mouth. Flash should have had proper collision detection, pathfinding, particle systems, physics, and gamepad control about eight years ago.

Unity, conversely (as with Scratch, GameMaker, Blender, UDK, and many others) is a proper game engine – you know, for making games. The trade-off with something like Unity is the tool’s reach. Adobe rightly touts its Flash player’s ubiquity … I think 104% of computers are running it, including computers from the future and fictional computers from your favourite sci-fi novels (HAL from 2001 enjoys a good game of Bloons, i hear.) Unity can boast maybe a 5% installation base, if you squint and hold the chart at an angle. It’s to the point where it doesn’t yet make economic sense to develop a web game with Unity, which is why i haven’t. This situation should improve dramatically, as Unity announced they’re working on an “Export to swf” capability, facilitated by Molehill (the agonizingly past-due Flash 3D functionality).

---

i think it took Adobe far too long to realize the value of their army of two million developers, and they’re scrambling to do right by that group as companies like Unity Technologies threaten to eat their lunch. After the incredible let-down of Adobe’s half-assed lip-service to 3D in Flash (no built-in depth management? Seriously?), the push for Molehill in the wake of Unity’s popularity is not coincidental. Unity is in a very strong position, because they can look at what Macromedia/Adobe have done and sort of patch holes in history. Building the Unity Asset Store, and offering the Union game brokering service, for example, were very smart moves; MM/Adobe left a lot of money on the table by letting sites like ActiveDen sell Flash widgets.

As a developer, with so many platforms and languages and development tools out there, I want to ally with a company that has my back – a company that cares that i’m using their tool, responds to the needs of the community, and respects the fact that i could flit like a butterfly to the next nectar-filled development platform, but i don’t. Can Adobe pull it out of the fire with their game squad? Maybe. i’ve spent 11 years working with Flash, and inertia makes it very tough for me to dislodge myself. But i feel there’s bad blood with Adobe, and that their sudden interest in developers feels cynical. When i spoke to an Adobe employee earlier this year about it, i said “A focus on game developers? Finally! What took you so long?” He merely shrugged.

Game developers are gold to these companies. They deserve more than a shrug.

---

i don’t know if this is a worldwide phenomenon, but one of the pitfalls the colleges around Toronto succumb to is that they hear Unity and Flash are sooo easy to develop for. Console developers like to say, somewhat disparagingly, “we use Flash for rapid prototyping.” So i hear this repeated in colleges: “We’ll teach our students to learn Flash, but just for – you know – rapid prototyping”, as if all the “cool” and “real” programming are only happening with C-based languages, and Flash is only appropriate for toddlers or Special Olympians. Same deal with Unity 3D – the deans and program co-ordinators hear it’s “super-easy” to develop games with the tool, so they figure they can just run a 4-month course inside a Game Development program and that’ll be sufficient.

If course, if you’ve actually bothered to make a game in either program, you’ll know that both require real-live Object-Oriented Programming chops. Sure, they do a lot of heavy-lifting for you – you don’t have to write your own physics engine in Unity, and you don’t have to worry about memory management or garbage collection in Flash … but both Unity and Flash require real, actual programming skills. Shocker! You need to know at least the very basics: operators, conditionals, functions, arguments, return values, variables, loops, and arrays. This is the very stuff I’m covering in my Understanding Programming tutorials on the Untold Entertainment blog. Once you’ve got that stuff under your belt, you can check out something like the Understanding Classes series, which is written for everyday folks like you and me (not CompSci eggheads).

So these colleges, who attract mostly video game players instead of video game creators, lead kids with “art skills” down the garden path, thinking that since these tools are “so easy”, a teacher should just be able to plow through 4 months with the students and they’ll come out the other end knowing how to build games with Flash or Unity. Then these kids put “i know teh Flash and teh Unity and sum UDK hyre me hor hor hor” on their resumes, and the market is flooded with grads who think they know how to do things. These grads – in the very worst cases – are hired by people who believe them. And then clients come to more experienced developers like Untold Entertainment asking me to fix what these kids broke. It’s a grim state of affairs.

A much healthier approach is if you’ve got a student intake full of “artists” and you’re running a Flash course, teach them asset prep: how to build a puppet for animation, how to create both tweened and straight-ahead animations, how to name things, how to manage layers and libraries, etc. Then the graduate writes “i know teh asset prep in Flash hyre me hor hor hor” on his resume, and he’s actually correct, and so everyone is happy. If you’re running a Game Development Program and you want people to believe you and not get a shitty reputation like many community colleges are getting, you absolutely need to bite the bullet and properly teach your students how to program. Don’t run a Flash course or a Unity course. Run a programming course, which uses Flash or Unity to help students see results more quickly and easily (note to colleges: “more quickly and easily” is a comparative statement. It is NOT the same as “quickly and easily”!)

So, “is Unity easy to learn”? Yes and no. It’s certainly the easiest time you’ll ever have trying to build a 3D game, but that’s all relative. Designing in 3 dimensions is just straight-up complicated, which is why in my Unity 3D Beginners Guide, I stuck mostly to quasi-3D, and 2D games using 3D models. You don’t have to chug along very far before having to worry about trig and differential calculus, depending on your game design. Thankfully, there are a vast number of simpler game designs that you can absolutely pull off as a beginner, which is what my book aims to show you.

---

1. Do NOT pay a hooker with a cheque.

i can come up with others, but if you break that rule, you’re basically done for.

As pertains to game development, the biggest mistake that new and experienced developers alike make is dreaming too big. It’s very easy to play a video game and to be blind to all the effort that went into developing it – to forget the fact that you’re one person and they have a team of dozens … that they’ve got a budget and work 9-5 for years and you’re building your game for “free” in your off-hours and weekends. As i say in the book, many developers think they realize this, and they start making concessions: “Well, i wanna build something like World of Warcraft except better, because i feel the developers really messed up certain aspects of that game. But i realize it’s probably out of scope for me to build WoW, even if I get Johnny to do the art for it next week while he’s off school with an ingrown toenail, so i’ll tone it down a bit: i’ll only have twelve races and fourteen classes and thirty-seven weapons and blah blah blah …”

This is the wrong approach. You won’t finish, and you’ll become bitter and jaded and you’ll move out of game development to pursue something easier, like hauling lumber in a logging camp.

The right approach is to think of the simplest game you can imagine, like motherfuck*ng dress-up, and then SCALE IT DOWN. Instead of a dress-up game with twenty outfits, reduce it to FIVE. i’m absolutely serious about this. Think of something almost insultingly simple, and then simplify it. At the end of the day, if you have one finished project, you are a fundamentally better human being than someone with twenty-thousand great ideas. He who executes, wins.

i think this is one area where those of us who grew up in the 80’s arcade era have a distinct advantage. We know what a small, manageable and playable game looks like. We know that you don’t need Gears of War to have fun – you just need Mr. Do or Bentley Bear running around some maze collecting golden whatevers. Today’s new crop of game developers have only monstrous multi-million dollar console titles as their models. The solution is for gamers to play more casual and classic games, and to really explore games that create fun with very few bells and whistles.

Of course, even veteran devs aren’t immune to this problem of over-scoping things. It’s probably my Achilles heel, and the reason why i don’t finish more of my own games. Here’s an anecdote from the trenches: i’m working on a platform game for a client right now, and it’s going to have a Level Select screen. i asked how many levels he wanted me to build, and he said “Oh, i dunno … 25?” and i said “Sure”, because 25 levels seems like a decent number of levels for a casual platform game. You see how that works? i wasn’t thinking about how long it was going to take me or how much money I was being paid – i was measuring my expectations against other games i’ve played, notwithstanding the staff, budget, or development time those games enjoyed.

It wasn’t until i sat down and pieced it together that i realized my mistake. If each level took one hour to build, it would take me 25 hours – over half a work week – to build all those levels. If levels took two hours to build, I’d be spending well over a week on them. To my horror, i realized it took upwards of FOUR HOURS to compose even a simple level. That worked out to over two straight 40-hour work weeks of building levels, which wasn’t sustainable for the project’s timeline and budget. Thankfully, my client is totally cool and agreed to reduce the workload to a more reasonable 12 levels. With a less understanding client, i could have lost a huge chunk of cash on the project. And I need that cash, you see, because apparently you can’t pay a hooker with a cheque.

---

Technically, Facebook games aren’t everywhere. They’re in one place: Facebook. NEWS of Facebook games is everywhere. The press really goes nuts whenever anyone makes boatloads of money on something many consider frivolous or fun. Their coverage conveniently ignores the scads of people who aren’t making money, so we get a real blockbuster mentality. Cityville is HUGE! Great. What about all the other developers who are making games and earning nothing? Iron Man is HUGE!! Super. What about all the people making indie films about people and their feelings?

To predict trends in the game industry, you really only have to look to film. People – especially old people – are going to try to shape and mold the games industry into something with a studio system, where five or six very large entities control all the developers, and in order to get your work seen anywhere, you’re going to have to go through gatekeepers. They say “content is king”, but it’s a ruse: content is peasant. Content is only king if you’re an aggregator of content; without the content, you’re not in play. But the sneaky thing about saying “content is king” is that it implies the people who make the content have some sort of power. They don’t. The people who squeeze the content out of the creators and use their dominance to wrestle rights and control out of the creators’ hands have all the power.

So many people are trying to get into game development now that developers themselves have become a commodity. Companies now “have” developers, and they wield that power like a stick. That’s why Adobe is finally organizing a game team – they want to try to control the community of Flash game developers as “their people”, just as Apple has its throng of iOS devs that it touts. Whenever a new device comes out, the developer incentives are getting sweeter – just take a look at RIM’s free Blackberry Playbook give-away, the Google Nexus One and Xoom give-aways at GDC. All these companies will increasingly dance and shimmy and wiggle their jiggly bits in order to attract developers to their platforms.

Once they have developers in their snares, though, the treatment gets a little rough. Check out the stink Amazon caused with its app store. After tanking the casual downloadable market in its price war with Big Fish Games (dragging the average price of a game from $20 down to $6.99), they developed absolutely vicious Terms of Service for their new app store that turns developers’ hard-fought work into collateral in another high-level price war. (Thankfully, the IGDA and others grew wise and are warning developers away from Amazon’s predatory practices.) Apple famously drove the price of mobile games down to 99 cents, which makes sense perhaps for songs, but is absolutely deplorable when it comes to something like a game.

For the future, I see a continued cat-and-mouse game of gatekeepers vs. developers, where gatekeepers and conglomerates try to snatch up developers in their net, and hurl those wads at each other in a fight for dominance, while clever developers slip through the holes in the net and find new places to have their work seen, heard, and purchased. They almost had us with the console publishing model, and then digital distribution came about. Now, publishers are trying to lock up that market with publishers, but some of us will escape. And escape we must.

I’m lifting a lot of what Dan Cook from Lost Garden has to say on this topic. Go check out his blog, and his excellent GDC’11 presentation on platform power.

Another prediction: at the end of the next five years, I will be surprised to find myself paying for any tool that enables me to develop games.

---

Not. At. All.

The situation in Canada is a little different than elsewhere. We have a number of funds that teevee production companies can tap into. In fact, one of the largest funds for teevee actually requires the production company to create an “interactive digital media” component, which can include games. (Often, the teevee prodcos produce “webisodes” to take the easy way out on this.) Since teevee people really don’t understand games or how to profit from them, they see the IDM arm as a necessary evil – a marketing expense. They often try to spend as little money as possible on the IDM component of a show. They can sell the show to broadcasters, but they don’t know how to sell the IDM aspect, and many broadcasters expect them to throw in the mini-site, games, webisodes, etc. for free with the show license. And in the case of preschool and kids’ entertainment, which is where Untold Entertainment specializes, it’s even more difficult, because you essentially have to rule out the advertising model. No parent wants their four-year-old kid playing a game with a big-ass McDonald’s logo slapped on top of it.

Mobile is budging that a tiny bit. Many of the kids’ teevee companies here in Canada are diverting large portions of their tiny IDM budgets to mobile, because they’re just tickled that they can charge money for those products. Even if it is only 99 cents, that’s 99 cents instead of the ZERO DOLLARS they’d normally have earned. i’m not convinced these investments will necessarily pay out for teevee companies, though. Teevee people love to talk about the “pass-back” phenomenon: the classic example is in the car, and the kids are screaming in the back seat, so mom quickly queues up some kids’ app on her iPhone and passes it back to the little brats to shut them up for a while so she doesn’t send the SUV screaming off a cliff.

Teevee prodcos have a distinct advantage in selling their apps because they have a teevee show, which has the potential to drive a lot of awareness for their apps. But they face the same problems as any other mobile developer: namely, marketing and discovery, and since games aren’t their bag (but, insultingly, they think they understand the industry just fine), the teevee companies risk throwing all their money into ventures that are often more expensive than developing Flash web games, where we know kids are spending time. Teevee is gambling on mobile, where we think kids might be spending time.

---

Untold Entertainment is a funny company, and it must be frustrating to watch us crawl along in relative obscurity. We earn money by completing fee-for-service projects (mostly Flash web games for Canadian kids’ teevee shows and broadcasters). Once the overhead is paid – office rent, phone and Internet, and my obscene cocaine habit – we may or may not have a little money left-over, depending on whether or not we agreed to develop 25 G-d levels for that bloody game. This mark-up is often eaten up by me writing vapid blog posts that i string together with stolen LOLCat pictures and dick jokes. After that, the remaining money goes towards sending me to international conferences like GDC and Casual Connect, where i don’t have any actual products to market because i was so busy writing those blog posts. And then – THEN, if i have any money left at all, it goes towards developing an original Untold Entertainment Inc. game.

We have three big projects in development, which have been in development for a very long time. Two of them are Interrupting Cow Trivia, an online multiplayer Flash game; and Spellirium, a post-apocalyptic puzzle adventure game. Each of these projects, i’m convinced, has been cursed. Production difficulties, staff rotation, lack of cash-flow and trademark issues have held them all back. But i have established a do-or-die mandate to finish them all this year, which has nothing to do with my stalwart perseverance, and everything to do with a government-imposed deadline on each project. The Canadian government is my project manager. God save the Queen.

i continue to struggle in vain trying to drive traffic to my game portals, including ZombieGameWorld.com. i detail my futile efforts in a funny series called Pimp My Portal. In the coming months, i will unleash Formerly Earl Peterson on the world. He is a puppet, and puppets are awesome. Formerly Earl is an articulate zombie who remembers what it is to be human. He acts as a liaison between the living and the undead, and is an avid zombie rights activist. He’s going to star in some games (like the Are You a Zombie? quiz), and will perform video reviews of zombie games. He’ll also answer your burning questions about zombies, including “What do brains taste like?” and “How do zombies do it?”

We’re still steadily improving UGAGS, the Untold Graphic Adventure Game System. We built and initially deployed UGAGS on a client project called Jinx 3, and then used for the quickie weekend jam game Heads (which is available for the Blackberry Playbook), and then again for Summer in Smallywood, another client project. With Smallywood, UGAGS now supports proper branching dialogue, along with nav meshes, which give the player more freedom to move around the game screen. The next two games we’re building with UGAGS are Panda, which is about a welfare-dependent panda bear trying to raise abortion money for his artificially-inseminated ex-girlfriend, and Excuse Me For Living (But the Graveyard’s Full), which is a graphic adventure game involving zombies.

Finally, there are a few smaller projects we’re developing, including the notorious Bear in a Sombrero. This year at TOJam (the Toronto indie game jam), i’ll be working with my five-year-old daughter Cassandra on a platformer called Sissy’s Magical Ponycorn Adventure. She’s doing the pictures and the voices.

---

You will learn the very best way to part with $30-50 dollars.

If you’re new to coding, you’ll learn a lot. i tried to make the book non-coder friendly. That doesn’t mean there’s no code in it – that means that the book gently explains each line, trying not to leave anyone in the dust.

If you come from a Flash background, you’ll get a real quick crash course in Unity to whet your appetite. You’ll learn a lot of stuff that you could eventually hunt down online, but the nice thing about a book is that it lays out a comprehensive course of study for you, and saves you from doing a lot of running around.

The book teaches about starting small, about separating skin from mechanic, and about the difference between features and content (which is where we get into trouble over-scoping our projects). By the time you finish the book, you’ll have built four small games in Unity 3D, and should be well equipped to pick a new, small game idea and run with it.

And with any luck – and I’m not making this claim officially or with any air of scientific or medical authority – but I’m pretty sure that reading Unity 3D Game Development by Example will cure cancer.

View full post on Activetuts+