LeftJoyX = aStrafe;
LeftJoyY = aBaseY;

Like so then I want to use atan2

MyRadian = Atan2(LeftJoyX,LeftJoyY);

This will give me a radian valuem which is a float. But radians are between 0 and 3.1415 or Pi. To turn this into a number i can use for a rotator I need to convert it into a large int.

MyYaw = MyRadian * 32768 / PI;

MyYaw is an int which i can then use for setting a rotator like this

MyRotator.Yaw = MyYaw;

So then I cna just do something like

MyMesh.SetRotation(MyRotator);

Now MyMesh will be turned in the direction i push the joystick in, Yay!

Sitting at a coffee shop setting up a project in unreal. Ill be using a regular xbox dpad to test each limb one at a time. When i get to my camera at work ill be able to test with a full skeleton.

Sitting outside thinking about code…

Wee fun with android!

As seen on some forums, a lot of the consensus from the hardcore seem to really think that microsoft “lost” E3 with crappy lame games and a stupid device (natal/kinect) Sony seems to come up in a tie with Nintendo, both boasting lots of 3D and lots of high quality high production valued titles. But honestly, I see microsoft coming out on top, and here’s why.

Nintendo’s audience expanded into the family circle with wii sports, grandparents finally got into the fray with wii bowling and the user interface with the wiimote was obvious in a way that made it accessible to the non hardcore gamer audience, the seniors and older parent audience.

With Kinect, we’re seeing an even more easily accessible interface device, and now you don’t even need to hold a remote. Of course this depends on the games made for natal, but everyone knows how to lean, jump, and run in place. Sure the hardcore gamers are already asking if Kinect will work if you’re sitting on a couch, but that’s missing the point.

The hardcore gamer is expecting to play street fighter, call of duty, and devil may cry type games using Kinect. Contrast this with the audience this device is perfect for. Your grand parents aren’t going to play any of those, as a matter of fact they probably resent those games. How does this mean microsoft is doing the right thing with Kinect, and sony is missing out?

Games like farmville, mafia wars and others are pinned in the middle of the casual game market, and they make more money than Killzone, Heavy Rain, or Borderlands, three large production, high expense, high quality games. I’m not advocating that these games aren’t worth while titles to invest production dollars into, on the contrary. Heavy Rain introduced the hardcore gamer to story. Killzone shows us more detail than most any other title. Borderlands allows the gamer to roam freely and still have fun basically getting nothing accomplished, but these are things that only the hardcore can appreciate.

The hardcore gamer is a narrow but avid and vocal audience. Once a gamer, you’re already sold on getting new games based on what’s on gametrailers.com, and thus will continue to buy and talk about whats coming out. But the Farmville audience doesn’t know about Kotaku or Joystiq. They don’t care, as dumbfounding as that might seem, they don’t know why there is a debate between keyboard and mouse vs. d-pad (im keyboard mouse myself, im old school, and use my laptop for more than writing about games)

Microsoft has expanded their audience several fold by releasing the Kinect. Some humbling numbers, undeniably the wii is a more casual device with nearly 72 million units sold and nearly 500 million games sold they’re doing rather well. The XBox 360, till now is much more of a core gaming unit, with about 40 million units sold but the audience buys a lot of games at 350 million games sold. Xbox wants to expand into the casual audience. Sure the core gamer buys more games, but adding a new device to grab a wider audience is not a losing proposition.

Here’s why Sony’s move isn’t going to do well against the Kinect. Strangely enough because it’s more accurate than the Kinect, but not as accurate as a d-pad. It’s a cool device, and for me I’m more interested in making games for the Move than the Kinect because it’s a more hardcore device, but that’s also its folly.

The move *is* meant for hard-core games, it’s great for swinging around a sword, it’s great for aiming a gun, and it’s great for throwing punches, three things that your grand parents aren’t interested in. But once in a game, many of the core gaming audience is going to be slow to throw out their halo controls. They’ve invested many hours in mastering the setup, and most will find that they are more accurate with head-shots with the d-pad than the move.

Now it’s d-pad vs move vs keyboard/mouse, I’m leaving out the wiimote and kinect on purpose, they’re not going to be in that fight since thats not where they’re supposed to be. Microsoft expanded their market and will overlap with the wii market, good for them. Sony is going to stay right where they are, they might expand a bit because it’s a cool device, but nothing major.

The only change left is for the Wii to release a super console, something that can shove a billion triangles per frame, more memory than google, and is faster than a Ferrari Enzo. But will they? Do they need to? NO. That would be a move toward the hardcore audience which isn’t nearly as profitable as where they currently exist.

This was an interesting E3, I saw lots of fun things, and a rather defined distinction between audiences and what each one gets excited about. I’m excited about both, easier to play games that are fun and accessible, as well as super crazy graphics with ridiculous characters and super powers. Looks like i’ll get both, but I’ll have to buy a lot more titles and new hardware.

anyway, if you’re really concerned and need to get in touch with me, for whatever reason. just ping me on twitter, i promise i’ll be more responsive.

I just tested new user registration, my mail server might be getting filtered, so check your spam folder for a password once its sent to your email address. once you get the new password your comments will be pending approval, but I’ll get them, so any questions, ask away!!!

lets do some stuff the hard way just to see how we can make our objects more dynamic.

In a previous tutorial I created a MyActor.uc file with you, and in there we had Begin Object in there that created a mesh object and added it to the actor. How else can we do the same thing? lets see using the “new” command.

class MyActor extends actor
	placeable;

var StaticMeshComponent SMeshComponent;

event PostBeginPlay()
{
	super.PostBeginPlay();

	SMeshComponent = new(self) class'StaticMeshComponent';
	SMeshComponent.SetStaticMesh(StaticMesh'MyObjects.Meshes.MyStaticMesh');
	AttachComponent(SMeshComponent);
}

defaultproperties
{
}

Notice that there’s nothing in the default properties, this is because we’ve created the mesh in the PostBeginPlay() function. We started by adding a var to the class caled SMeshComponent, which is a StaticMeshComponent type object. To make use of this we fill in the variable in memory with a “new(self) class’StaticMeshComponent’” this is cool in a number of ways. First, it’s a new object for “self” the “self” keyword is a reference to the class that created it. Important because when this class is destroyed the new mesh will know that its parent is the class that created it. Second we now have control over the contents of that variable, and we can manipulate it in a few basic ways.

Comething Creative

Lets add two new variable types, a bool, and a couple of StaticMeshes, and a float for a timer.
our vars should now look like this:

var StaticMeshComponent SMeshComponent;
var StaticMesh Mesh1, Mesh2;
var float SwitchDelay;
var bool bMeshSwitch;

We’ll use the SwitchDelay to setup a place to record some WorldInfo.TimeSeconds, and then we’ll make a bMeshSwitch to keep track of which mesh we’re going to show. And for good measure we’ll keep a place in memory for each mesh.

Here’s some of the code for the timer and the mesh switch logic:

event Tick(float DeltaTime)
{
	super.Tick(DeltaTime);
	SwitchMesh();
}

function SwitchMesh()
{
	if( WorldInfo.TimeSeconds > SwitchDelay )
	{
		if( bMeshSwitch )
		{
			SMeshComponent.SetStaticMesh(Mesh1);
			bMeshSwitch = !bMeshSwitch;
		}
		else
		{
			SMeshComponent.SetStaticMesh(Mesh2);
			bMeshSwitch = !bMeshSwitch;
		}
		SwitchDelay = WorldInfo.TimeSeconds + 3;
	}
}

So in the tick we’ve got a call to a SwitchMesh() function. Right under tick we write our function. the first if statement controls how often our switch happens. When the if condition is met it will update the timer with SwitchDelay = WorldInfo.TimeSeconds + 3, so the +3 sets the next time the if statement should execute.
To switch on and off the second mesh, we use bMeshSwitch, and then when the if{}else{} statement is executed the statements will toggle the boolean from one to the other by using bMeshSwitch = !bMeshSwitch, read that as “bMeshSwitch is Not bMeshSwitch” also read that as “set bMeshSwitch to what it is not”

Now with the previous scene we’ll get updated with a ball that goes from smooth to spiky every three seconds.

Setup a new project for MyGame, so go into your UTEngine.ini and add EditPackages=MyGame, and add the new path for MyGame\Classes and drop your new code in there. For more information on this take a look at setting up a new project on this Setting up your project.

From this point on out I’ll be using the MyGame project for the rest of the tutorials.

In case you don’t want to follow along too closely…
Put these in Development\Src\MyGame
And put this in UTGame\Content\Packages\MyObjects.upk
And also you’ll want to put into UTGame\Content\Packages\ MyPawn.upk
Unzip them first of course.

Starting with some basic code reading and some basic implementations.
Let’s start with the following code.

class MyActor extends actor
    placeable;

defaultproperties
{
    Begin Object Class=StaticMeshComponent Name=StaticMeshComponent0
    StaticMesh=StaticMesh'MyActors.Meshes.MyStaticMesh1'
    End Object
    Components.Add(StaticMeshComponent0)
}

So we’re making a new object called “MyActor” and we’re going to inherit actor’s properties by extending it with our own code.

So next open “UDK…\Development\Src\Engine\Classes\Actor.uc”

It’s a big file! As of the March 2010 version of UDK, it’s nearly 4000 lines long! That’s a lot of programming already done for you, but what can we do with it all? It’s a bit baffling at first, but they’re writing UnrealScript just like you are, so don’t be too intimidated.

Around line 1572 in Actor.uc you’ll find the following line:

    native final function SetHidden(bool bNewHidden);

It’s a super simple function, it’s a “native” function so there’s C++ code underneath the actor.uc that is supporting this function, and it’s “final”, so you can’t remove any of the routines that the function has. And its important to see that it’s looking for a “bool” in the parenthesis, so you’ll want to use it like SetHidden(True) or SetHidden(False), these are the only “args” or arguements that you can give to or “pass” to this function.

There’s another important couple of functions in there, namely, “PostBeginPlay()”

// Called immediately after gameplay begins.
//
event PostBeginPlay();

The comment here says this event is called right after the game begins. It’s an “event” so that means that it receives a message from the engine, and it’s told to execute whatever procedures are written in it. In regards to the comment, we can assume it’s going to get a message when the game begins. Back in the editor, the “Actor Classes” tab in your Content Browser window you’ll find MyActor, ordered alphabetically. Select it and drop it in the example scene. When you run the game you’ll simply see a sphere in the level, big whoop. that’s what everything will do right? Okay, so let’s use the SetHidden function. Change the MyActor.uc to:

class MyActor extends actor
    placeable;

event PostBeginPlay()
{
    super.PostBeginPlay();
    SetHidden(true);
}

defaultproperties
{
    Begin Object Class=StaticMeshComponent Name=StaticMeshComponent0
    StaticMesh=StaticMesh'MyActors.Meshes.MyStaticMesh1'
    End Object
    Components.Add(StaticMeshComponent0)
}

We’ve added a PostBeginPlay() to our own code, but we added SetHidden(true); right after super.PostBeginPlay(); What did that do?
Calling Super.PostBeginPlay(); means we’ll do operations found in Actor.uc, then after that we’ll do our additions to this code, in this case, SetHidden(true); Run the game and you’ll notice that the sphere isnt there! well, it is there, it’s just hidden. So what?

Lets add another function that does something when we get near it, like make it visible only when we’re near it. How do we do that?
Well, since we’re extending Actor.uc let’s look at that again! In there we can find some interesting stuff, in this case lets look at:

// The actor's position and rotation.
/** Actor's location; use Move or SetLocation to change. */
var(Movement) const vector			Location;

/** The actor's rotation; use SetRotation to change. */
var(Movement) const rotator			Rotation;

Hey, these are handy!!!
Location and Rotation, Everything that’s extending from Actor.uc have a Location and a Rotation. It’s also important to see that Location is a vector, and Rotation is a rotator, these are variables you can create and use as well. Oh and another important function in Actor.uc is Tick, we’re going to make use of that as well.

adding to our MyActor.uc again!

class MyActor extends actor
    placeable;

event PostBeginPlay()
{
    super.PostBeginPlay();
    SetHidden(true);
}

event Tick(float DeltaTime)
{
    super.Tick(DeltaTime);
    `log(Location);
}

defaultproperties
{
    Begin Object Class=StaticMeshComponent Name=StaticMeshComponent0
    StaticMesh=StaticMesh'MyObjects.Meshes.MyStaticMesh1'
    End Object
    Components.Add(StaticMeshComponent0)
}

We added event Tick(float DeltaTime), we have to match how Actor.uc wrote their function if we’re going to inherit it correctly. likewise, super.Tick(DeltaTime); doesnt need to have float added to it because rather than writing a function we’re calling it. What’s the difference?

Writing “event Tick( stuff )” means we’re starting a new function with what are called arguments where “stuff” is. Anything added between the ()’s means we’re creating an input to the function. DeltaTime is a special keyword, every Actor inherits a DeltaTime. So, when we call Tick, we need to feed it DeltaTime, so it can be called every frame of the game. Thus super.Tick(DeltaTime). If this is still a big foggy we’ll get back to it later.

Now we’re going to add `log(Location); and we’re going to run the game with a -log window open.
try this when you open up UDK.exe from the windows start menu open cmd or the command prompt, navigate to your UDK directory. in my case, im using


c:\UDK\UDK-2010-03\Binaries\Win32\UDK.exe test_map -log -windowed -resx=800 -resy=600


This will tell UDK top play the game in a window and a script log will open along side it, quite handy. This is how we’ll watch for the `log(Location); Run the game with the MyActor placed in the level, in the Log window you’ll see someting like:


...
ScriptLog: 132.35,-86.83,-417.50
ScriptLog: 132.35,-86.83,-417.50
ScriptLog: 132.35,-86.83,-417.50
ScriptLog: 132.35,-86.83,-417.50
ScriptLog: 132.35,-86.83,-417.50
...


your coordinate positions will be different from mine, but you’ll get the idea, that’s the tick running `log(Location); every frame. Great, your actor knows where it is in the world! Now we need to know where the player is! Now lets look for how we find out where other stuff is in the game. For that we’ll need to look at WorldInfo.uc found in Development\Engine\Classes\. In there we find the following:

/** returns all Pawns in the PawnList that are of the specified class or a subclass
* @note: useful on both client and server; pawns are added/removed from pawnlist in PostBeginPlay (on clients, only relevant pawns will be available)
* @param BaseClass the base class of Pawn to return
* @param (out) P the returned Pawn for each iteration
* @param (optional) TestLocation is the world location used if
*        TestRadius > 0
* @param (optional) TestRadius is the radius checked against
*        using TestLocation, skipping any pawns not within that
*        value
*/
native final iterator function AllPawns(class
BaseClass, out Pawn P, optional vector TestLocation, optional float TestRadius);

ooo, “iterator” what’s that?
basically, iterator means we can use a ForEach keyword to use it. There are other iterator functions there, AllActors, AllControllers, AllNavigationPoints, etc. Now take a look at how to use that and add to MyActor.uc

class MyActor extends actor
    placeable;

var MyPawn Player;

event PostBeginPlay()
{
    super.PostBeginPlay();
}

event Tick(float DeltaTime)
{
    local MyPawn P;

    super.Tick(DeltaTime);

    ForEach WorldInfo.AllPawns(class'MyPawn', P)
    {
        Player=P;
    }
    `log(Location);
    `log(Player.Location);
}

defaultproperties
{
    Begin Object Class=StaticMeshComponent Name=StaticMeshComponent0
    StaticMesh=StaticMesh'MyObjects.Meshes.MyStaticMesh1'
    End Object
    Components.Add(StaticMeshComponent0)
}

We’ve added a var or variable for the player, and we added ForEach WorldInfo.AllPawns(class’MyPawn, P); and a variable in the function Tick called local MyPawn P;
With this Tick will search the scene for Every pawn that matches the class MyPawn, tell P that it’s that pawn, (by the way, that’s called casting, like an actor filling a role) and then we’re going to set the var Player to P.
So var mypawn player, is a role, and the role is being filled by P, or P is cast to Player. If there were more than 1 MyPawn in the scene player would be cast to one then the other in each tick.

After all that, we can make use of Player, because now it’s been filled in with some data. So now we’ve got a log for both the location of the actor, and the location of the player.
Check out the log and move the player around, you’ll see one of the numbers flying thought he script log changing as you move the player, thats YOU! More important is to remember that it’s the actor in the scene that knows your position, its watching you

I’ve also taken out the SetHidden, so we can see where the actor is, because we’re going to need to know. Now lets do something useful with these two vectors (the player vector and the actor vector.)
lets first get rid of the two logs, and combine them. Change the two logs in tick to `log(Player.Location – Location); so now we’ve got some vector math going!

Here’s a question, why dont we just write “ForEach AllPawns(class’MyPawn’, P)” ?
Well, AllPawns(); isnt going to work, that will only work if MyActor.uc had a function called AllPawns in it. However, WorldInfo.uc does have that in it, and we can call WorldInfo from any object in the world, that’s good to know. So to use functions found inside of WorldInfo we need to write “WorldInfo.AllPawns()” because AllPawns is a function found inside of WorldInfo.

still, not so useful unless we want to do some more clever tricks. luckily, Object.uc has plenty of clever tricks built into it. For instance, VSize( vector A ); Vsize is asking for one vector, and by subtracting player.location from location we get one vector as a result. so now we’ll take a look at how VSize works.
change the log to the following:

    `log( VSize( Player.Location - Location ) );

Run the game again and your script log will have a single value streaming through, and as you get close to the MyActor object that number gets smaller, when you’re further away that number gets bigger, that’s the number for Unreal Units between the player pawn and the actor, sweet!

okay, now let’s update Tick again with:

event Tick(float DeltaTime)
{
    local MyPawn P;

    super.Tick(DeltaTime);

    ForEach WorldInfo.AllPawns(class'MyPawn', P)
    {
        Player=P;
    }

    if( VSize(Player.Location - Location) < 100 )
    `log(WorldInfo.TimeSeconds@"player is close!");
}

Rather than logging that position im saying "if" the number from VSize(Player.Location-Location) is less than 100, `log("player is close!") so lets compile this and run it again! Oh I also added WorldInfo.TimeSeconds just so that we dont see player is close! over and over again, which isnt too obvious when it shuts off, anyway run the game and see the log to check out what I mean. WorldInfo has a lot of useful things, I suggest that you go through that and find some more useful variables.

now we can change that if statement to

    if( VSize(Player.Location - Location) < 100 )
    SetHidden(true);
    else
    SetHidden(false);

now when you get close to the object it hides itself! woah, it's interactive. Sure it's not so exciting, but you can use any other function in place of SetHidden.