Adobe Flash 11 Stage3D (Molehill) Game Programming Beginners Guide

By Christer Kaitila
  • Instant online access to over 8,000+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Let's Make a Game Using Molehill!

About this book

Adobe’s Stage3D (Molehill) is a set of 3D APIs that has brought 3D to the Flash platform. Being a completely new technology, there were almost no resources to get you acquainted with this revolutionary platform, until now.

This book will show you how to make your very own next-gen 3D games in Flash. If you have ever dreamed of writing your own console-style 3d game in Flash, get ready to be blown away by the hardware accelerated power of Stage3D. This book will lead you step-by-step through the process of programming a 3D game in Actionscript 3 using this exciting new technology. Filled with examples, pictures and source code, this is a practical and fun-to-read guide that will benefit both 3D programming beginners and expert game developers alike.

Starting with simple tasks like setting up Flash to render a simple 3d shape, each chapter presents a deeper and more complete videogame as an example project. Right from a simple tech demo, your game will grow to become a finished product - your very own playable 3d game filled with animation, special effects, sounds, and tons of action. The goal of this book is to teach you how to program a complete game in Molehill that has a beginning, middle, and game over.

As you progress further into your epic quest, you will learn all sorts of useful tricks such as ways to create eye-catching special effects using textures, special blend modes for transparent particle systems, fantastic vertex and fragment programs that are used to craft beautiful shaders and much more. You will learn how to upload the geometry of your 3D models to video RAM for ultra-fast rendering. You will dive into the magical art of AGAL shader programming. You will learn optimization tricks to achieve blazingly fast frame rate even at full screen resolutions. With each chapter, you will “level up” your game programming skills, earning the title of Molehill Master – you will be able to honestly call yourself a 3D game programmer.

This book is written for beginners by a veteran game developer. It will become your trusty companion filled with the knowledge you need to make your very own 3D games in Flash.

The sample chapter for this book (chapter 8; view the Table of Contents here) will be made available very soon. Thank you for your patience.

Publication date:
November 2011
Publisher
Packt
Pages
412
ISBN
9781849691680

 

Chapter 1. Let's Make a Game Using Molehill!

Welcome, brave hero!

You are about to undertake an epic quest: to make a game using the Stage3D API (Molehill). This quest will be filled with fun and excitement, as well as challenges and setbacks. It is one that you are sure to enjoy. Programming a 3D game is not easy—but you CAN do it!

Consider this book your trusty sidekick on an exciting adventure. Much like in a role-playing game, you are the star. You are the hero.

This book will take the tone of a grand adventure story. We will explore Molehill together, overcoming challenges and slowly leveling-up our knowledge. On each step along the way to our goal—the creation of a 3D game—you will earn "experience points". During your adventure in game making, you will be presented with systematic challenges that we will call "quests". At the end of each chapter, you will "level-up".

This book is aimed at complete beginners to Molehill, and is meant to be informal, semi-jovial, light-hearted, and fun to read. You don't just want a boring appendix of every Stage3D command listed in order. That information can be found using Google.

Instead, we will start from scratch and gradually explore deeper into the world of 3D Flash games, one skill at a time. It will be example-heavy and filled with information that you can use in real-life game development using the Flash 11 Stage3D API.

 

Your epic adventure awaits!


Your mission is simple. Armed with this book and a little hard work, your quest is to program a fully functional 3D game filled with action and movement, loaded with eye-candy and amazing 3D graphics. When you have completed all the exercises in this book, you will be the proud author of your very own 3D game, ready to be played by all your friends… and indeed the whole world.

Your adventures will become the stuff of legend, to be sung by travelling minstrels in all the taverns in the kingdom.

So let's get on with it! Time for the training camp; the best place to start is the very beginning. The basics:

 

What is Molehill?


Molehill is the code name for Adobe's latest Flash technology, "Stage3D". It is specifically designed to take advantage of the modern hardware-accelerated 3D graphics cards. Just like games seen on consoles such as XBOX 360 and the Playstation 3, hardware 3D graphics processors deliver some serious graphics horsepower.

Compare this to how Flash traditionally renders graphics on-screen: vector graphics are rendered in software into 2D bitmaps and are blitted (drawn) onto the screen as pixels. This is both computationally expensive and extremely slow. If you have ever experimented with drawing a few hundred sprites in a large Flash window, you know that Flash starts to slow down to the point of being unplayable very quickly.

Molehill, on the other hand, moves this entire pixel processing function onto the video card, freeing your computer's CPU to do other things while the 3D graphics are rendered by a specialized GPU (graphics processing unit) on your video card. This allows the next generation of Flash games to render hundreds of thousands of sprites on-screen—at full screen resolution—with minimal CPU load.

In previous versions of Flash (10 and below), all the work—including all drawing—was done on the CPU. Moving all those pixels in each and every frame takes billions of tiny calculations. In the new version of Flash, you can have a video card do the time-consuming and calculation-intensive tasks of rendering your scenes, freeing up the CPU to do other things. For example, your CPU can be calculating enemy movements, updating the high score, or downloading files at the same time as your GPU is doing all the drawing.

Anecdotal benchmarks have shown full 3D scenes comprised of over 150,000 polygons running full screen at HD resolution at 60 frames per second (FPS) with less than 10% CPU usage. Compare this to a typical old-fashioned Flash animation which can max out the CPU to 100% usage with only a few thousand sprites in a small window.

The Stage3D API will free artists and game designers to spend more time thinking about the content and less time worrying about performance. You will be able to draw hundreds of explosions or smoke particles or special effects within a massive and complex 3D world filled with moving vehicles, buildings and terrain, and still maintain phenomenal frame-rate.

Why is it so fast? Because Molehill makes your video card do all the work. Flash gets to sit back and take it easy.

 

What Molehill is NOT


Molehill is a very low-level API. It only provides basic 3D rendering functionality. It is insanely fast, and the brilliant minds at Adobe have made the smart decision to keep it very simple. It does just one thing and it does it well. It is not bloated. It is not a jack-of-all-trades, with a million features plus the kitchen sink. It is a low-level programming interface that deals exclusively with 3D rendering and nothing else.

It is not a game engine (like Unity3d or Unreal or ID Tech). A game engine also includes supplemental game functions such as physics simulation, sounds, music, collision detection, and much more. Instead, you use a low level API such as Molehill to create your own game engine from scratch.

Instead of trying to be everything to everybody, Molehill sticks to being really good at just one thing—3D graphics. Much like OpenGL or Direct3D, Molehill is a collection of very basic functions. They are the basic building blocks of games and game engines.

We will be doing all Molehill programming using a new set of AS3 commands. The low level programming (for shaders) is written in its own language, which is compiled at runtime and uploaded to the video card. Molehill shaders look shockingly similar to those of the most low level of programming languages, assembly language.

Don't let that scare you: the number of commands you will need to learn is small.

 

What you need to know already


As long as you are armed with a basic understanding of Flash ActionScript, you are ready to embark on this adventure without any worries. You do not need to know a single thing about Molehill. Beginners are welcome.

As you know, AS3 (shorthand for Flash's ActionScript 3) is a programming language that looks very similar to Javascript or C++. You should already be familiar with Flash programming, but you do not yet have to be a 3D expert.

You don't need to be an elite coder, neither do you have to be a mathematician to get amazing results. We are not going to explain what a function or a variable is, nor are we going to show you how to compile your project into a .swf file—you already know how to program in Flash, you just want to learn Stage3D.

If you are not comfortable with AS3 programming quite yet, no problem! There are many great books available to help you with AS3. Get yourself to the level that you can program a simple "hello world" Flash program and then come back. Basic programming skills are beyond the scope of this book, which is only about the Molehill side of Flash.

Assuming that you already know a little bit about AS3, you know everything required to jump right in.

 

Basic 3D terminology


Your basic training, to get you to "level one" so to speak, should include the knowledge of some prerequisite terminology that you are sure to encounter during your adventures in 3D game development. Most of them are generic words for concepts related specifically to 3D.

You only need to know a few new terms in order to completely understand the 3D coding. It is not as complex as some people would have you think. You probably already know what most of these terms mean, so let's get them out of the way.

Are you ready to use both your left and right brain? We only need to go over two groups of terms: 3D art and 3D code.

Your artistic side, the right side of your brain, loves art. It cannot wait to sense the colors and textures that make up the visual component of your game.

Your logical side, the left side of your brain, hungers for all that is algorithmic. It wants to dive into some tasty code and make things happen. Working together, the art and code are used to create videogames. Here are the basic definitions that you will need in order to forge ahead and dive into Molehill.

 

Common 3D content terms


This section is a perfect food for the right side of your brain. It concerns the art.

In 3D games, what you see is simulated in a virtual world that has depth and volume. Instead of a 2D game where you are only concerned with the coordinates on the screen of various images, in a 3D game you can "look around the corner" so to speak; objects are sculpted, just like a real-world building, in three dimensions. In order to do this, the following art asset types are most commonly used.

Mesh

A model in a 3D game is typically called a mesh. This mesh is built in a 3D modeling application such as Maya, 3D Studio Max, or Blender. It defines the 3D shape of an object, as well as the colors used to draw it. Your game's main character will be made up of one (or more) meshes. A vehicle, a building, or a tree is all individual meshes. A single scene can be built from hundreds of meshes.

Polygon

Each facet of a mesh is a flat geometrical shape. One mesh could be made from hundreds or thousands of polygons, or "polies". One poly could be a simple triangle with three sides. It could be a "quad" or a four-sided square or rectangle. Imagine, for example, a 3D cube, a box. It is made from six different squares (quads), one for each side. Each of these quads is called a poly.

Any kind of a polygon can be built from a collection of triangles. For example, a quad can be made from two triangles sitting side by side. As a result, modern graphics cards treat all 3D geometry as a huge collection of triangles. Usually, when somebody tells you the number of polies a particular mesh is made from, they are referring to the number of triangles (or "tris") used to define it. When a video card manufacturer is boasting about their latest and greatest benchmark performance, they will quote how many polies they are rendering and how many times per second they can do so.

Vertex

Each poly is defined by the location of three or more "corners". For example, in a square quad, there are four corners. Each of these four corners is called a vertex. A vertex (the point in space where the corner sits) is defined as a simple location in the 3D world.

In the example of a 3D box that has six sides (each being a square quad as described earlier), there are eight corners. Each of these corners is a vertex.

As meshes are made from hundreds of polies, and each poly is defined by three or more vertex coordinates, when you tell Molehill about the "shape" of a particular model in your game, you generally do so by listing thousands of vertex coordinates in a huge array.

Texture

In order to draw a mesh (unless you simply want to render a wireframe), you will use one or more images, which are called textures, to color the shape. A texture could be thought of as wallpaper: plaster the texture onto the mesh, wrapping it around the mesh, and this image is stretched to conform to the mesh shape. For example, imagine a box. It would be a mesh with six sides, defined by a total of eight vertex coordinates (one for each corner). In order to make the box look like it was made out of rusty metal, you would draw, using Photoshop or GIMP, an image, and save it as a .jpg or a .png file. This image is your texture. By instructing Molehill to wrap it around your box mesh, the game would render it as a rusty metallic cube.

Shaders

Shaders are the definition of a particular visual style. They define "how to draw" something. One shader might be used to render shiny metal while another could be used to draw explosions.

In the Stage3D API, shaders are stored in the Program3D class. In order to create one, you need to create both a "fragment program" and a "vertex program". The combination of these two programs is a shader.

When people ask you if you know how to write shaders, you will soon be able to answer, yes, I am familiar with writing vertex and fragment programs.

Vertex program

A vertex program is run once for every vertex in your mesh, every time you want to render it. It is given whatever data is stored in your vertex array for that particular vertex plus whatever variables you wish to tell it about such as the camera angle. When it is done, it reports the "final position" for that vertex just prior to rendering, plus (optionally) other information, such as the vertex color.

Vertex programs tell your fragment program about the current state of each vertex in your mesh.

A vertex program decides where each vertex is, what color it is, what its texture coordinates are and anything else you may wish to calculate prior to being sent to your fragment program for rendering.

Vertex programs allow you to interact with your vertex data, as well as change things around. In the code, you send tiny bits of data to a vertex program to change the shape or position of the vertices in a mesh every frame. For example, if you program a vertex program to control the movement of an avatar's head, in each frame you could send a number from 0 to 360 to control which way the head is facing.

Vertex programs can use these constantly updated real-time parameters in an infinite variety of ways. Instead of a single number, as in the preceding example, perhaps you will create vertex programs that use vector3Ds to change the position of a sentry gun's turret, or an entire array of numbers to completely change the overall shape of your mesh by changing the locations of each vertex.

Every mesh you render will require a vertex program, whether very simple (draw each vertex in their original position) or complex (morph the mesh to animate a walk cycle).

Fragment program

In Molehill, a fragment program is a set of commands that define how to handle the visual rendering of a particular mesh. Sometimes referred to as pixel shaders, fragment programs are all about describing how a given surface/texture responds to light. Different materials respond to light in different ways (depending on how reflective and transparent they are for one thing), and you need different code to simulate that.

Fragment programs often use textures (the bitmaps described earlier), as well as complex functions to decide what color each pixel on the screen should be. Sometimes a fragment program will combine the effects of more than one texture, as well as the RGBA (red, green, blue, alpha transparency) data stored alongside each vertex location, plus any number of parameters to arrive at the final color.

By using fragment programs, you can add special effects to your plain textures, such as adding shine or shadows or real-time animation. Fragment programs let you fade things in, tint them different colors, and tell your video hardware how to draw each poly that makes up a mesh. Every mesh you draw needs a fragment program or nothing is drawn. It could be simple (just use the texture as is) or complex (blending two textures together and tinting it a see-through transparent shiny red that is affected by some lights).

3D Content level one achieved!

With regard to common 3D art asset terms, that's it for now! All you need to remember is that for each object you want to draw on the screen, you will upload some data to your video card.

In our rusty metal box example, you will instruct Molehill of each vertex that defines the shape of the mesh. You will define a texture, the image of rusty metal. You will compile a fragment program, instructing Molehill how to draw that texture, as well as a vertex program, which instructs Molehill what to do with the vertex data.

When the game is running, you might decide to fade the box out by sending a few numbers to your fragment program. Perhaps, you will change the box from rusty metal to wood by replacing the texture it uses. Alternately, you might want to make the box wobble as if it is made out of jelly by sending a few numbers to your vertex program.

You are in control of everything you need to produce spectacular 3D graphics. All this graphics power is sure to give you ideas. Anything you see in today's next-gen games can be accomplished with Molehill's fragment and vertex programs. The possibilities are endless.

 

Common 3D coding terms


This section is targeted towards the left side of your brain. It concerns the functional side of game programming.

A videogame is like a potion. You take the raw ingredients (the art content) and add a little magic. A sprinkling of 3D code is all it takes to make the game magic happen.

Don't be afraid of a little code, as a programmer you know that this is how things are done. By using the following concepts, you will have the tools to make things move around for you. Luckily, you don't need to be a Math whiz to make a game. Even if you are primarily an artist, you can program a game using Molehill by learning from examples.

Instead of a verbose list of every possible 3D function in Flash, instead of a giant dusty dry tome filled with trigonometry and advanced calculus, only the top four terms are presented here. If you do a Google search for Flash AS3 documentation regarding 3D, then you will find many more.

The great news is that 90% of the time you will only have to concern yourself with the following data structures: vectors, normals, and matrices.

Vectors

A Vector3D is an object that contains x, y, and z values that describe a location in the 3D space.

Each component is a number (which can be positive or negative and can be a fraction), and each number is the distance from 0,0,0 (the origin). Just as in 2D Flash, where Point(0,0) usually defines the top-left corner of the stage, a new Vector3D(0,0,0) would represent the location of the "center of the universe" or the very middle of the 3D world. This location (0,0,0) is called the origin. The term used to describe the x or y or z part of a vector is called an axis.

For example, you could use a Vector3D to define the coordinates of each vertex in a mesh. You could also use a Vector3D to define the location of a bullet in your game.

For example, the x-axis (the first number in a Vector3D) typically represents the left-right movement. The y-axis is most commonly used for the up-down movement, and the z-axis describes the in-out movement (that is, moving from close to the camera to far away from the camera). In a normal 3D scene, when the z coordinate increases the object, it is seen to be smaller because it is farther away from the screen. Vectors actually have a fourth component, w, but it is rarely used. It is handy to store a rotation. In the vast majority of cases you will consider a Vector3D to consist of x,y,z.

Imagine that you want to put a model of a tree in a particular spot in a 3D scene. In old-fashioned 2D flash games, you have most likely used the Point class, which has an x and y coordinate, to define where on screen a sprite is supposed to be. In Molehill, the class you need to work with is named Vector3D.

Here are some examples of how to use vectors in Molehill:

import flash.geom.Vector3D;

var putTheTreeHere:Vector3D = new Vector3D(0,0,0);
var locationOfTreasure:Vector3D = new Vector3D(1000,0,-15000);

var aNormalPointingUp:Vector3D = new Vector3D(0,1,0);

Tip

Downloading the example code for this book

You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com. If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.

You can probably guess what each line of the preceding code would do. We have declared three variables. Each is a vector, and could be used to define where something is sitting in the world. The Vector3D class is defined in the built-in package named flash.geom.

Looking back at the preceding example source code, if you were to add the following at the end:

trace(locationOfTreasure.z);

The output in the debug log after running the code would be -15000, the number stored in the z component of the variable named locationOfTreasure.

Normals

There is a special kind of vector which is usually used to describe a direction, instead of a location. This is called a normal. You store it using the exact same class, a Vector3D. The only difference between a positional vector, which could look like [55,5000,12] and a directional vector, a normal, is that normals always have a length of one .

Normals are also often called "unit" vectors because they have a length of one unit. The term "normal" literally means perpendicular (for example, normal to a plane, or pointing straight away from a particular surface). For example, a normal vector that describes something as pointing straight up would be [0,1,0] (assuming the y coordinate is up in this world, this vector describes a direction that is perpendicular to the "ground").

In the preceding example source code, the variable named aNormalPointingUp is simply a Vector3D that has a length of one.

The reason why normals are so handy is that, because they have a length of one, you can use them to multiply with times or distances or speeds. For example, if you multiply a normal that points straight up with a speed, such as 100, then the resulting locational vector would be 100 units larger in the y axis.

You can add vectors together, subtract them, multiply, and divide them. In each case, all that is happening is that each axis in the vector (the x,y,z) is added or subtracted, or multiplied by the corresponding axis in the vector it is being added to.

How would you do this? Well, by using aNormalPointingUp from the example, we could add it to locationOfTreasure like this:

locationOfTreasure = 
  locationOfTreasure.add(aNormalPointingUp);
trace(locationOfTreasure.y);

Now the output in the debug log would be 1.

This would result in the original position of the treasure being incremented by one in the y-axis. In simple English, the treasure would now be floating one unit above the ground.

In this example, then, the original value for locationOfTreasure was (1000,0,-15000) and after adding aNormalPointingUp to it, the new value is (1000,1,-15000). Makes sense, doesn't it?

The variable aNormalPointingUp is a special kind of vector. As it has a length of one, it is called a normalized vector, or just "a normal". Why make the distinction between a vector and a normal? A normal is just a special kind of vector. As it has a length of one, you can use it in handy ways, such as multiplying it by the amount of time which has passed since the last frame, so that a missile flies at a certain speed.

You can turn a positional vector, such as [55,5000,12], into a normal by dividing each axis by the length of the vector, which forces the total length of the new vector to be 1. The easiest way to do this is to use the normalize() function that is built into the Vector3D class.

Why would you want to do this? You might want to know what direction "points" toward a particular location. In this example, the normal of [55,5000,12] is approximately [0.011, 0.987, 0.002]. You can see that the proportions for each axis are the same, now they just add up to one.

Normals are really handy in game programming, and you will see them mentioned all the time. Remember that a normal is just a vector that is only one unit long.

Matrices

Sometimes you need to move and rotate and scale an object all in one go. In order to make your life easier, another AS3 class can be used. A Matrix3D is simply a collection of vectors. Each vector inside it describes the position, rotation, and scale. Often, you will need to move something at the same time as rotating it, perhaps also increasing its size. The Matrix3D class uses a 4x4 square matrix: a table of four rows and columns of numbers that hold the data for the transformation.

You don't need to know how a matrix is organized. Just know that it is really useful as a way to gather all the movement, rotation, and scaling data for a 3D object, so you can use it in a single line of code. There are many handy functions built into the Matrix3D class that can perform the difficult math for you, such as changing the scale or adding rotations or translations (positional changes).

For example, imagine a puff of smoke used in a cool-looking particle system like an explosion. In each frame, that puff will need to rise into the air, spin around, and perhaps grow larger as the smoke dissipates. With a matrix, you can do all this in one line of code. This is usually called a transform, which is just another word for a matrix that is used to describe the movement of an object in space. You usually create a matrix and use it to transform (move, scale, rotate, and so on) an object. Sometimes in 3D programming, you will see the term "matrix transforms" and this is what it means. For example, to transform a vector you might multiply it to be a matrix.

3D Coding level one achieved!

That is it! These are all the coding terms you need to know for now. All this talk of 3D matrix Math and Cartesian-coordinate geometry can be a little bit scary. Fear not, gallant hero.

Like the terrifying stomp of an approaching boss battle, all you need to do is take a deep breath and try your best to forge ahead. Nobody is going to expect you to know how to calculate the dot product of two vectors by hand and if you didn't take calculus in school, you are not at all precluded from becoming the next game programmer hero.

Be brave, wise adventurer, and take pride in the fact that you have been awarded the very first achievement in your quest to make a 3D game.

Pop quiz – earn some experience points

Here are a few quick questions to test your understanding. If you can answer them, you are officially ready to move on to the next step in your grand adventure.

  1. Imagine a 3D model of a house. The x, y, and z location in the 3D space of the house in your game world would be defined by a:

    a. 4x4 Matrix

    b. Texture

    c. Vector3D

    d. Mole wearing a top hat

  2. If you wanted to make each wall of your house mesh look like it was made from purple plaid wallpaper, you would draw the plaid in an art program, save it as a jpeg, and use it in a fragment program as a:

    a. Normal

    b. Texture

    c. Polygon

    d. Secret ingredient

  3. Imagine a giant ogre decides to push your house over to the next lot on the street. It shifts in position to the side by a small amount. Let's say its original position was [10,0,10]. The ogre pushed it by this amount: [5,0,0]. Where is it now?

    a. [15,0,10]

    b. [15,0,0]

    c. [5,0,10]

    d. 42

Have a go hero – your first side quest

In order to really hone your skills, it can be a good idea to challenge yourself for some extra experience. At the end of each chapter, there is a side quest—without a solution provided—for you to experiment with, and it is optional. Just like grinding in an RPG game, challenges like these are designed to make you stronger, so that when you forge ahead, you are more than ready for the next step in your main quest.

Your side quest is to compile the following AS3 source code, so that you have a test bed for further experiments.

If you love to use the Flash IDE, that is great. Just set up a blank project and drop this code wherever you deem to be appropriate. If you use FDT or Flex, no problem, you know how to make a "hello world" project.

Many game developers nowadays use FlashDevelop as an IDE that uses Flex to compile pure AS3 projects without any of the CS5 bloat like timelines. FlashDevelop is completely free and is highly recommended as a more responsive, faster way to make flash files. You can download it from http://www.flashdevelop.org/. Whatever your weapon of choice, try to get yourself to the point where you have a simple project to do some experiments in.

Simply fire up your IDE or code editor of choice and see if you can get this quick "hello world" project compiled. It does not draw anything on screen: it simply outputs a couple of lines of text to the debug trace window:

package

{

import flash.geom.Vector3D;
  private var putTheTreeHere:Vector3D = 
    new Vector3D(50,0,5000);

  private var moveItByThisMuch:Vector3D = 
    new Vector3D(0,0,0);

  function moveTheTree():void
  {
    trace('The tree started here: ' + putTheTreeHere);

    putTheTreeHere =
      putTheTreeHere.add(moveItByThisMuch);

    trace('The tree is now here: ' + putTheTreeHere);
  }

}

Now that you have set up a project, you may have to change the preceding code to compile, depending on whether you are using pure AS3, flex, or flash. It is up to you to set up a basic project in whatever way you are most comfortable with.

Once you have the preceding code compiling properly, your side quest challenge (this should be the easy part) is to change the variable moveItByThisMuch, so that the tree's final position is [100,0,5555].

For the adventurous, as an extra challenge try playing around with vectors some more. For example, you can move the tree by a small amount every single frame, as part of an onFrame() event. Can you figure out a way to move the tree at a constant rate regardless of the frame rate? Hint: you might find out how many ms have passed since the previous frame using the getTimer() function and then multiplying a tiny vector by that amount before adding that total to the tree's position. Use Google if you need it. You can do it!

 

Summary


We learned a lot in this chapter about common terms used in 3D programming. The good news is that you now know just about everything required to program video games. Any time you need to move something around, rotate it, change its scale, or calculate how far something travelled during a particular TimeSpan, you will be working with vectors. Months from now, when you are deep in the middle of creating a fantastic gaming masterpiece, you will most likely be spending most of your time dealing with vectors, normals, and matrices. When you are working on the art, you will be thinking about polygons and textures.

Specifically, we covered:

  • Vector3D: containing an x, y, and z component

  • Normal: a Vector3D that has a length of one

  • Matrix: a 4x4 group of vectors with position, rotation, and scale

  • Vertex: a point in space that is the corner of a polygon

  • Polygon: a shape defined by multiple vertex coordinates

  • Mesh: a group of polygons (polies) that make up a model

  • Texture: a bitmap image that is like wallpaper for a mesh

  • Shader: the combined result of a vertex program and a fragment program

  • Vertex program: commands affecting the shape of a mesh

  • Fragment program: commands affecting the look of a mesh

Now that we have learned the basics of 3D programming, we are ready to dive into Molehill. We are now armed with sufficient knowledge to have "leveled up".

 

Level 1 achieved!


Congratulations! As a level one Molehill master, you have opened the door that leads to the inner secrets of the Stage3D API—which is the topic of our next chapter.

About the Author

  • Christer Kaitila

    The author of this book, Christer Kaitila, B.Sc. is a veteran video game developer with 17 years of professional experience. A hardcore gamer, dad, dungeon master, artist and musician, he never takes himself too seriously and loves what he does for a living: making games! A child of the arcade scene, he programmed his first videogame in the eighties, long before the internet or hard drives existed. The first programming language he ever learned was 6809 assembly language, followed by BASIC, Turbo Pascal, VB, C++, Lingo, PHP, Javascript, and finally ActionScript. He grew up as an elite BBS sysop in the MS-DOS era and was an active member of the demoscene in his teens. He put himself through university by providing freelance software programming services for clients. Since then, he has been an active member of the indie game development community and is known by his fellow indies as Breakdance McFunkypants.

    Christer frequently joins game jams to keep his skills sharp. Over the years, he has programmed puzzle games, multiplayer RPGs, action titles, shooters, racing games, chat-rooms, persistent online worlds, browser games, and many business applications for clients ranging from 3D displays for industrial devices to simulations made for engineers.

    He is the author of the book “Adobe Flash 11 Stage3D (Molehill) Game Programming Beginner's Guide” and is the curator of a popular news website called http://www.videogamecoder.com which boasts over 30,000 articles and zero ads. He is one of the administrators of Ludum Dare, and has hosted a mini weekend jam with the theme of “all talk: dialogue and conversation”. He also created the keynote lecture for Ludum Dare 21, an 8 minute video filled with words of encouragement and advice. His client work portfolio is available at http://www.orangeview.net and his personal game development blog is http://www.mcfunkypants.com where you can read more about the indie game community and his recent projects. He lives in Victoria, Canada with his beloved wife and the cutest baby son you've ever seen.

    Browse publications by this author
Book Title
Access this book, plus 8,000 other titles for FREE
Access now