Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
4. February 2014

 

In my head this part of the process of creating a dynamically equipped character in 3D and rendering it to 2D was going to be a breeze.  Conceptually it went something like this...

 

  • Create a named bone in parent object where the weapon could attach.
  • Create a named bone in the child object where the weapon starts.
  • Find bone one, attach bone two.
  • Go enjoy a beer in smug satisfaction.

 

Sadly it doesn’t quite work like that.

 

There are a couple problems here.

1- LibGDX doesn’t have a SceneGraph.  A Scene Graph is basically a data structure that holds relationships in the world.  Essentially this is what scene2D actually is.  Well, LibGDX sorta has a SceneGraph in the form of Model, which is a graph of nodes that compose the model.  There however isn’t a layer above this for creating relationships between models.  This sadly means I can’t (out of the box) do something like myTank.attachObjectAt(turrent,(3,3,3));

 

2- Modifying bones in LibGDX doesn’t actually seem to do anything.  My first though was… well this is easy enough then, Ill just set the GlobalTransform of the child bone to the location of the parent bone.  This however doesn’t do anything.  I might be missing something here, in fact I probably am.  But I couldn’t get changes to a bone to propagate to the attached model.  This one is likely user error, but after playing around with it for a few days, I am still no further ahead.

 

3- Bones don’t have direction.  Well, that’s not accurate, bones don’t point in a direction.  Here for example is a sample hierarchy of bones exported in text readable format:

{"id": "Armature",
   "rotation": [-0.497507, 0.502480, -0.502480, 0.497507],
   "scale": [ 1.000000, 1.000000, 1.000000],
   "translation": [ 0.066099, 0.006002, -0.045762],
   

   "children": [
      {"id": "Bone_Torso",
      "rotation": [-0.498947, 0.501051, -0.501042, -0.498955],
      "scale": [ 1.000000, 1.000000, 1.000000],
   

      "children": [
         { "id": "Bone_UpArm",
        "rotation": [ 0.007421, -0.000071, -0.009516, 0.999927],
        "scale": [ 1.000000, 1.000000, 1.000000],
        "translation": [ 1.728194, 0.000000, -0.000000],

      "children": [
         {"id": "Bone_LowArm",
         "rotation": [ 0.999846, 0.012394, -0.000030, 0.012397],
         "scale": [ 1.000000, 1.000000, 1.000000],
         "translation": [ 1.663039, 0.000000, 0.000000],

      "children": [
         {"id": "Bone_Hand",
         "rotation": [ 0.999737, -0.016222, -0.000425, 0.016225],
         "scale": [ 1.000000, 1.000000, 1.000000],
         "translation": [ 1.676268, 0.000000, -0.000000]}
      ]}
   ]}
]}

As you can see, you have the Armature, which is basically the root of the skeleton.  It’s translation is the start location of the bones in local space ( of the model ).  Each bone within is therefore offset from the bone above it in the hierarchy.  What is lacking ( for me ), is a direction.  As an aside, I can actually confer the direction using the distance between (in this example) Bone_Hand and Bone_LowArm.  This of course requires two bones on both the parent and child models.

 

Consider this bad drawing.

 

You have a tank and a turret like so, with the red dots representing bone positions:

 

Tankexample1

 

So long as your tank and turret are modelled with consistent coordinate systems ( aka, both same scale, same facings, etc ), you can simply locate the tank bone and offset the turret relative, like so:

Tankexample2

 

In this simple example, it works perfectly!

 

Let’s consider a slightly more advanced situation however. Lets say we are diehard Warhammer fans and want to add sponsons to the side of our tank.

Once again, by modelling consistently with the tank and sponson, we can get:

TankExample3

 

Yay future tank now looks a hell of a lot like the world’s first tank…  but this is pretty much what we want.  Now lets mount one to the other side of the tank.

 

TankExample4

 

Ah shi… that’s not right.  Our second gun is INSIDE the tank.

 

The problem here is, we can’t depend on the coordinates of the both models matching up anymore.  We need to figure out direction when mounting the new weapon to the tank.  This means we need a facing direction for the bone, and this is something we don’t have.

 

Again, this problem has proven trickier then expected.  I will share some of my failed approaches shortly as this post got pretty long.

Design


9. January 2014

 

Right off the hop for my new game I have to deal with a problem that many games have to deal with but one that could have a huge impact on how my game is structured, so I am going to address it with a proof of concept right up front.   That thing, as the title probably spoils, is character customization.

 

As I said earlier, this is a pretty common problem in games and something you see questions about quite often if you hang around game development forums for any period of time.  So what do I mean with character customization?  Ever played Diablo or a similar title?  When you change your gear in Diablo, your character is updated on screen.  This behaviour is pretty much expected in this day and age… personally I really hate when I am playing an RPG and the weapon I equip has no affect on my avatar.  That said, it is certainly a non-trivial problem and one that could have a pretty big impact on your game.

 

Let’s start by taking a look at the various options… at least the ones I can think of.

 

2D - Pre-render all possible configurations

Of course, brute forcing it is always a possibility and in a few cases may actually be ideal.  Basically for a 2D game, you simply create every combination of sprite for every combination of equipment.  So if you have an animation sequence for “walk_left” and “walk_right”, you would have to create a version for each possible equipable item.  So you might have “walk_left_with_axe” and “walk_left_with_sword” sprite sheets for the different weapon combinations.  If you are rendering your spritesheets automatically from a 3D application, this could actually be the easiest approach.  Of course there are some seriously massive downsides to this approach.  Memory usage quickly becomes outrageous.  For each piece of equipment you double the size of your original sprite sheet for example.  Once you start adding more and more options, this approach quickly becomes unfeasible.  If you only have a very small amount of customization ( two or three weapon options ), this approach may appeal due to it’s simplicity.  With anything more than a couple combinations though, this approach is pretty much useless.

 

2D – Pre-rendered spritesheet + pre-rendered weapon animation frames.

You can use a regular sprite sheet and simply keep the weapons separate.  So basically you have two separate sprite sheets, one of the character without weapons, one with just the weapons.  Then at run-time you combine them.   Consider these two sprite sheets ( taken from a StackOverflow question ).

Animated Character:

Player SpriteSheet

Weapon:

Weapon SpriteSheet

Then at run-time you combine the two sprites together depending on what is equipped.

In fact, if your weapon isn’t animated ( as in, it doesn’t move, like a sword, as opposed to a weapon like a whip or nunchucks ) you can get by using a hard point system, where you define the mount position of the weapon ( for example, the players right hand ) and orientation.  Basically for each frame of animation, you provide an x and y coordinate as well as rotation amount that represents where and how the weapon should be mounted.  Then at runtime you combine the two sprites, positioning and rotating the weapon sprite relative to the mount/hardpoint. This way, you only need a single image per equipable weapon.

This approach has a couple downsides.  First, you need a separate data file to hold mount point data and possibly a tool to generate it.  Second, it makes bounding/hit detection more difficult as the mounted weapon may exceed the dimensions of the originating sprite.  Third, you need to deal with z-depth issues, you cant simply paste the weapon on top of the sprite, as what happens when the character is walking right but carrying the weapon in the left hand?  To handle this your workflow needs to basically be: render obscured weapons, render character sprite, render foreground weapons.  Finally, weapons with their own animation, like a whip snapping, would require even more effort.

All told, this is probably the easiest while still flexible system for 2D animation.  It requires a bit more work than simply brute forcing your sprite sheets, but the payoffs in reduced size and complexity are well worth it, especially if you have more than a couple items.  One other big win about this approach is then weapons can be re-used across different sprites, a huge win!  Then you can model a single sword and it will be available to all sprite sheets with hard/mount point information available.

 

3D - Bone/hardpoint system

If your game is pure 3D this is often the way you want to go.  If you character is a knight for example, in your 3D modelling application you create named hard points in your model, either as bones or as an object of some form such as a null object, point or invisible box.  Then at runtime you bind other models to those locations.  So for example, if you equip a long sword and shield, your code searches for the “right_arm_shield” bone and uses it as the parent object for a shield 3D model.  Then you bind a sword to say… the “left_arm_hand” bone.  You can see an example of this behaviour in this UDK example.

This approach is basically identical to the last 2D method mentioned except in 3D and that you dont generally need to define your own hardpoint system, as most 3D packages and engines already support it out of the box, either by binding to a bone or by accessing and parenting 3D objects to named locations.  Like working in 2D, then your weapon and character are two separate entities, like so:

3P_Weapon_Attach.JPG

One of the major advantages of 3D over 2D is flexibility.  Most animations in 2D need to be pre-calculated, while in 3D you have a great deal more flexibility with the computer filling in the blanks for you.  Unlike in 2D, additional 3D animations add very little to the data file sizes.

 

2D Bone based animation

One of the major downsides to 2D animation is, as you add more animations, it takes up more space.  People have been working on solutions, one of the most common of which is 2D bone animation.  How exactly can you use bones on a 2D image file you ask?  That’s a good question!  In 3D, its pretty simple… the motion/influence of the bone transforms the attached geometry.  In 2D, there is no geometry, so how can you do this?

Well, the simple version is, you cut your bitmap or vector image up into body parts.  So instead of a single image of an animated character, you instead of an image for the foot, lower leg, upper leg, torso, waist, shoulder, left upper arm, etc…  Then you can draw 2D bones that control the animation of this hierarchy of images.  There are applications/libraries that support this, making it mostly transparent for you.  Here is one such example from Spine from Esoteric Software.

 

The character:

Creating Bones

 

It looks like a single image ( and you can see a couple bones being drawn in the foot/leg area ), but it is actually composed of a few dozen source images:

Set Parent

 

Basically the workflow goes, you create your traditional image in your regular art program, except instead of creating a single image, you create dozens of hopefully seamless ones representing each body part.  You stitch them together, setting the drawing order ( what’s covering what ), then define bones to create animations.  This has the double advantage of massively decreasing space requirements while simplifying the animation process.  The downsides are creating your initial image are a great deal more difficult and of course, you need to buy ( or roll your own ) bone system, such as Spine. 

 

Spine is not the only option, there is also Spriter from BrashSoftware and probably others I am unaware of.  Both of these are commercial packages, but then, both are dirt cheap ( IMHO ) with price tags between $25 and $250 dollars, with $60 and $25 dollars being the norm with each package respectively.

The nice thing about taking this segmented bone approach… you basically get the ability to swap components or bind weapons for free.

 

2.5D hybrid approach

2 1/2D is becoming more and more popular these days.  Essentially a 2.5D game is a 3D game with 2D assets ( such as 2D sprites over a 3D background ), but more commonly its 3D sprites over a 2D background.  How does this work?

Well there are two basic approaches.  You model, texture, animate your 3D model as per normal.  Any character customization you perform you would do as if you were working in full 3D.  Now is where the two different approaches vary, depending on performance, the hardware you are running on, etc…  You can either generate a sprite sheet dynamically.  Essentially when your character is loaded or you change equipment, in the background your game renders a sprite sheet of your updated character containing every animation frame, then you use this sheet as if it was a normal 2D sprite sheet.  The other option is, you render your character each time it moves.  Creating a spritesheet consumes more memory, but very little GPU or CPU demand.  Generating your characters current animation frame dynamically on the other hand, takes almost no memory, but at a much higher CPU/GPU burden.  Which is right for your game is obviously up to you.

Of course the 2.5D approach certainly has it’s share of problems too.  First off, it is the most complicated of the bunch.  Second, you cant do any “by hand” calculations on your generated sprite/spritesheets, as they are now being rendered dynamically.  This means no ability to create pre-calculated bounding volumes for example.  On the other hand, the 2.5D approach gives you most of the advantages of 3D ( compact animation data structure, easy programmable modification, ability to alter texture mapping, lighting effects, etc… ) that 3D does, but with the simplicity of dealing with a traditional 2D world.

One animation to rule them all!

You may be thinking WAHOO… I can cut my work way down now!  All I need to do is animate an attack sequence and then I can simply substitute the different weapon images.  Not so fast I am sorry to say.  Think about it this way…  are the images for swinging an AXE and a Sword the same?  What about a pole arm?  You are still going to have several different animations to support different classes of weapons, but these techniques will still vastly reduce the amount of data and work required while allowing a ton of customization.

 

 

So then, what am I going to do?

So, which approach am I taking?  Ultimately I am going to require a great deal of customization, going far beyond the examples described above.  One such example scenario is a Mech with a customizable left weapon… this weapon could be an arm holding a gun, a turret containing one or more guns, or possibly even a large pack of rockets.  Each “weapon” could have it’s own animation set.  Oh, and I am much more proficient in 3D than 2D.  On the other hand, the game itself is a 2D game and I would prefer to keep it that way for the simplicity that brings in a number of areas ( level creation tools, path-finding and other AI tasks, physics, cheating at art, etc… ).  As a result, I am going to try the 2.5D approach, where the mech is created and animated in 3D, dynamically equipped, then rendered to 2D.  I am going to try both pre-rendering sprite sheets and dynamically rendering a single frame and see what the overhead of each is.  I actually have the compounded issue of dealing with enemy characters that are also dynamically generated, so any impact will be magnified many time over!

If I can’t get adequate performance from each approach, I may be forced to go full 3D and emulating a 2D look.  As I said, it’s one of those things that can have a major impact on your game!  That said, I am pretty confident performance wont be too much of a factor.  My immediate take away task list is:

  • get a LibGDX project set up that can load and render an textured, animated 3D model exported from Blender. I am pretty new to 3D in LibGDX ( okay… completely new to it )
  • bind another model to a bone on this model ( aka, a sword to a hand bone )
  • try to dynamically generate a sprite sheet of the character’s complete animation.  Measure resulting memory usage and time required to generate sheet
  • re-architect the code to instead generate each frame of animation per frame on demand.
  • scale both scenarios up to include multiple instances and see results on performance
  • measure performance impact of each approach on both desktop and mobile.

 

The outcome of this experiment will ultimately decide what approach I take.  Stay tuned if that process sounds interesting!

 

Oh, and of course, these are only the scenarios I could come up with for dealing with dynamically equipped characters, if you have another idea, please share it!

Design Programming


7. August 2013

 

This isn’t an area I spend a ton of time on, as I haven’t got much talent for drawing.  That said, if I just fire up Blender and start modelling I tend to be a lot slower then if I nail down the basics of my concept, at least the proportions and overall shape, before even beginning to model.

 

In this case my concept was pretty simple… I want to make a jet that is a throwback to classic planes of old like the twin tailed Lockheed P38 Lightning or the DeHavilland Vampire, except with wing mounted engines like the Me-262.  However, I want it to appear near-future modern, like a contemporary of the F22 Raptor or F35 Lightning II.

 

For non plane buffs, I basically want:

 

This (P38):

p38

 

Or This (Vampire):

Vamp

 

With engines like these (Me-262):

me262

 

But more modern/futuristic, like this ( F22 ):

f22

 

 

Got it?  So basically I want a retro style twin tailed jet that looks futuristic.

 

So, time for some doodling!  I have a tendency to start with something really quick, break it down into individual pieces and go from there.  This way I get mostly the correct perspective, but I can work on smaller details instead of big picture… I can also quickly decide what works and what doesn’t.

 

For this, I worked entirely on my iPad Mini using a 5 dollar stylus and the application iDraw, which is a vector based graphic suite for iOS and MacOS.  Obviously any sketching app would work, as would paper if you have access to a scanner or digital camera.

 

Here is my first brain dump of the concept, side and top view:

1

 

I'm relatively happy with the top view, but hate the under-wing engine and am not a fan at all of the side profile.  I am thinking wingmounted engines don't work too well with the look I am shooting for here.

 

Instead I am going to switch to a single jet engine, like the Vampire pictured above.  Let’s clean up the tail section a bit and move to a single centrally mounted engine, again top and side view:

2

 

OK, I'm pretty happy with that look over all, now I’m going to look at the top and wing layout.  I start with:

3

 

Not really a fan.  Doesn’t make a ton of sense for the wing to extend out in front of the air intake.  Instead I decide to extend the air intake forward quite a bit, like so:

4

 

I like the overall shape better, it’s starting to look more modern, but I am still not a fan of the cockpit, nor have I nailed down the side profile yet.

 

On to the side profile.  I start with a quick sketch of the side, now using the forward wing, air intake and single engine. 

5

 

I did a quick sketch in black and it’s too fat and not very modern.  Drew over it in red more to my liking.

 

Now it’s a matter of figuring out the cockpit I am still not happy with, as well as the front view.

6

 

Started with a 3/4 view of the cockpit area, a rough front sketch, then a slightly cleaner one.  Over all, I’m pretty happy with the front profile.

 

So, I’ve got my basic design down, now the most important part, as a modelling aid and so I get the proportions generally right, I trace over the side and top view of my design using the line tool and end up with this:

7

 

The basic outline for the side and top profile of our jet.  I am certainly going to win no awards for artistic talent, but it should be sufficient for my needs and over all, I’m fairly pleased with the design concept.

 

You will see how we use it in the next part when we fire up Blender.

Art Design


1. August 2013

 

Way way wayyyyyy back when I created I want to be a game developer… now what? I wrote:

So, you’ve picked a language, the libraries you want to use and now you need to, you know… do something.  The following are a list of suggested projects for a new developer interested in games, with a ( fully my opinion ) difficulty rating attached

Then I completely neglected to actually provide the list.   Oops.

 

As this is one of those questions that comes up so often with new developers, I’ve decided to finally answer it.  Basically this is just a list of progressively more difficult game projects that you can work on when just starting out, as well as details of why to do each project.  Of course, you don’t need to do any or all of these projects, it is simply a logical ( to me! ) progression of projects for a new game developer to work on. 

 

For each example, I've linked some random tutorials that you can refer to if you have trouble.  I would suggest trying to do it without the help of a tutorial the first time, you will learn more that way.  That said, there is no reason to bang your head against the wall over and over if you run into difficulty.  Although occasionally satisfying, head banging is rarely an effective learning method.  If there was a new concept introduced with the game, I often also add other links that should prove of some use to you. 

 

The tutorials were discovered mostly using Google, then I took a brief look at the code to make sure it wasn't awful.  If you have better recommendations for linked tutorials, let me know in the comments and I will edit them in!  If you run into trouble, also let me know in the comments and I will see what I can do. I hope some of you find this guide useful!

 

Games you should make when just starting out, in chronological order

 

Adventure/Zork/Simple text adventure

Why?

It's about as simple as you can get and still call it a game.  You are going to learn string handling, something you will be doing A LOT.  You will also implement a rudimentary game loop ( get input, update world, display result ).  Also, you don't have the added complexity of graphics.

Examples:

C++ text adventure tutorial

Java text adventure tutorial

Javascript text adventure sourcecode

 
 

Hangman

HangmanExample

Why?

If creating a text adventure isn't your thing, Hangman is another simple game concept that doesn't require graphics.  In many ways, the process will be virtually identical to a text adventure, so if you do the one, you won't really learn much by doing the other and vice versa.

Examples:

C# Hangman tutorial

C++ Hangman tutorial

JavaScript Hangman tutorial

Java Hangman tutorial

 
 

Tic Tac Toe

Why?

One word… AI.  While not having made the jump to graphical programming yet, you are now going to have an opponent to program.  The nice thing about Tic Tac Toe is, you can start of brute forcing the logic, but after some time you can look at implementing a more elegant solution.

Examples:

Java Tic Tac Toe Tutorial

C# Tic Tac Toe

See Also:

Once you've got Tic Tic Toe going, consider looking at a more elegant way of solving the board.  A very commonly use algorithm in AI development for making decisions is the MinMax algorithm.  After you licked MinMax, there is an optimized version called AB ( alpha-beta pruning ).

MinMax description

MinMax and AB pruning explained ( pseudo code )

C# implementation of Tic Tac Toe using Minmax and AB pruning.

 
 

Pong

Why?

Welcome to the wonderful world of graphics!  You will have to learn about the render loop, how you draw the world each frame.  This will also be your first taste of collision detection, although with Pong this can be faked.  You will also have to learn how to make an AI that isn't perfect!  Of course, you will also be taking your first steps into 2D game math, although you can minimize the math required a great deal, depending on how you implement Pong.  You may also encounter a state machine for the first time, depending on how you implement it.  Pong represents a project you can start simply and make a great deal more complex as you get comfortable.

 

Examples:

Over-engineered pong in C++ using SFML ( on GameFromScratch.com )

Pong in XNA (C#)

JavaScript Pong

 

See Also:

At this point you are going to need to select a graphics library for your language of choice.  Pong is simple enough you can often get buy using the native drawing library of your programming language ( if it has one, C or C++ do not ).  Otherwise you need to select a library.  This post should help you in the selection process if you are using C++, C#, Java or Python.  If you are using Lua, this post should help.  If you are using JavaScript, select a library here.

Now might be a good time to brush up on the concept of a game loop.

 

Breakout

Why?

Well, it's basically Pong for one player with slightly more sophisticate math.  Purely optional, but if you completed Pong, Breakout/Arkanoid should be a pretty easy progression.  Granted, you won't really learn much new.

 

Examples:

Breakout in JavaScript using Canvas

Breakout in Java

Asteroids

Why?

Math baby math.  The process is going to be very similar to Breakout or Pong, but since the player can move and shoot in many directions, the math is going to be very different.  The collision detection is also going to be more complicated.  Don't let math scare you off, it's not really that complicated, and I've got examples/tutorials for basically everything you need to know!

Examples:

Asteroids in C#/XNA

Asteroids in Python with PyGame

 

See Also:

For the math, I've created a series of math tutorials that cover everything you need to know to implement Asteroids.

PacMan

Pac-man

Why?

PacMan introduces a couple interesting concepts.  First is the concept of a level file or map.  Next is the AI controlling the ghosts, commonly implemented using a State Machine, a very common algorithm in game programming.  PacMan also introduces the concept of levels.

Examples:

PacMan in JavaScript

Source for PacMan in LUA/LOVE

Source for PacMan in C++/SDL

 

See Also:

Finite State Machine in PacMan (PDF Link)

Platformer

SMB

Why?

Now would be a good time to try and implement a platforming game, be it a single screen game like Donkey Kong, to a side scroller like Super Mario brothers.  You will be faced with implementing some kind of physics ( jumping, falling, not-falling ) and more advanced collision detection than you have to date.  You will also have more difficult level requirements.  Optionally at this point, you can implement physics in your game, don't worry, it's not as scary as it sounds.

Examples:

JavaScript platformer tutorial (link to part two is in the comments)

Android platformed with Java/libGDX

 

See Also:

A big requirement to creating a platformer is a level creation tool.  Now might be a good time to check out Tiled one of the most popular, and free, map editing tools available.  If you decide to use Tiled, I have a very detailed tutorial series to get you started.

For 2D physics, Box2D is the most popular library and it has been ported to dozens on languages.  Here is a tutorial on creating a platformer using Box2D and Cocos2D with Objective-C.

What now?

 

That will have covered off most of the basics.  The only thing glaringly missing from the list of things covered that I can think of is advanced pathfinding, such as learning the A* (A-star) algorithm.  You can learn more about it by reading this Stanford article.  The next logical jump would probably be to work in 3D, if that's where you want to go next ( you could easily spend your entire life just working on 2D games if that was your preference ).  If you want to go 3D, I highly recommend using an engine to start.  If you are struggling with how to create art for your game you may want to check out A Programmer's Guide to creating art for your game.

 

Once again, this page was simple meant as a list of suggestions for games to create for developers that are just starting out.  Feel free to do them in whatever order you want, or to skip them entirely, but as listed above, the difficulty progression does make a certain amount of sense.

Programming Design


3. July 2013

 

Now that Project Anarchy is out, I’ve decided to take a look at what you actually get.  If you’ve never heard of it before, Project Anarchy is a collection of Havok game development tools made available completely free for mobile developers.  In this post, we will look at exactly what those tools are composed of.  To get started, head over to the download page and download the installer.  The initial download is just a downloader, the actual install is a great deal larger, just shy of 5GB on my system.

 

 

When I started this post, I expected it to be rather short… boy was I wrong.  Let’s just say, you get a LOT in this package.  This post will give you a pretty good idea of what you get in Project Anarchy and should give you an idea of it’s capabilities.

 

 

Getting started and help contents

 

After installing, you should have a folder structure like this:

image

One important thing to keep in mind, to develop for iOS you need a Mac and need to perform a different download.  Also it is important to note that the vast majority of Project Anarchy’s tools do not run on MacOS.  So basically, you will need a Windows and Mac machine if you want to do iOS development.  That’s pretty much normal at this point in time though.

 

A bit of a warning, Project Anarchy isn’t the only thing you will need to install.  To do Android development on Windows, you will also need the Android SDK and NDK installed, Visual Studio 2010 or higher ( Express works, but lacks Android debugging), as well as the Java 1.6 JDK.  Notice again, 1.6, not the newest version!  Seems a common trend for developer tools to require Java 6 instead of 7.  If developing for iOS, you need to have XCode and the iOS SDK installed.  There is a document specifically about getting start with Android and iOS that walks you through the process in more detail.

 

Documentation and learning resources

 

The documentation shipped with Project Anarchy is in a word impressive.  A great deal of the documentation is installed locally.  The directories that will be of immediate interest to most developers are \Docs\Vision\windows, \Docs\Vision\android, \Docs\Vision\ios, although confusingly enough, they seem to contain only slightly modified versions of the exact same documents!  So, if you want to shave 600MB or so from your install, you can probably start here.    The VisionEngine_Documentation_platformname.chm file is the master index, pulling all the other documents together.  Project Anarchy includes the following documents:

 

image

 

As you can see, a pretty comprehensive set of documentation.  The Startup Guide is the most logical place to start.  It gives you an overview of the various tools, a short Lua scripting primer, etc.  Perhaps coolest of all, there is a full sample project with assets that you can play around with.  These assets are referenced multiple times in the documentation.  There are actually a ton of assets for anyone to get started with, especially if you dont have immediate access to Maya or 3DS Max.

 

In addition to the documentation installed locally, there are a series of video tutorials available, covering vForge, Animation and the basics of scripting.  The quality of the videos varies massively from very good to… not.  There are also a series of courseware, which you can think of like tutorials that are targeted towards school curriculums.  The course ware series all revolve around the sample project you can download here (direct link, 100mb in size).  Additionally they have a StackOverflow style question and answer page as well as a remarkably active forum, considering the age of the project.

 

All told, the information available is quite good.  That said, I’ve done a fair bit of jumping into the documentation and it’s a mixed bag.  It’s well enough written and generally useful.  That said, it has some serious legacy issues, as much of this obviously was inherited from Havok tools, and they’ve been around for a long time.  For example, I found configuration details for Metrowerks Codewarrior… a compiler that might be older than some of the people reading this right now!  So there is a huge amount of documentation, but figuring out which parts you need might be a bit of a challenge.  In the end though, it’s much better than I was expecting and a very well documented and supported SDK.  You can tell they put some focus on documentation/new user experience, and it shows.

 

vForge

 

In many ways vForge *IS* Project Anarchy, in the same way Unity Studio is Unity.  This is where you create your levels, write your scripts, create landscapes, etc.  Basically it’s the glue that holds all the other pieces together.

 

Here is vForge with the RPG project loaded and the Arena scene open.  FYI, the RPG project is available at Data\Vision\Samples\Engine\RPG

image

 

You can navigate around the scene using the mouse.  Aiming with mouse, left mouse button to move in the direction your are looking, right mouse button to change your look direction.  You can also configure it to use WASD keys for navigation if that is your preference.  See where it says “Default Layout”, this is where you can change the layout between the various things you might want to do in vForge, such as script editing, particles, etc.  You can also define your own custom layouts, or use almost every panel as undocked, which is nice on a multi monitor setup.

 

In Engine View, this is where you can place items in the scene.  Here for example, I instanced a BOSS shape from the Shape Creators tab by dragging and dropping onto the Engine View.

 

image

 

Press the Play icon in the Engine View toolbar, and your game will start playing, UI and all ( animated obviously… ):

 

image

 

So, vForge is where you place game objects, but that’s just scratching the surface.  There are a staggering number of tools embedded in here… see:

 

image

We will look at many of them shortly.

 

Script Editing and debugging

 

For example, opening the Script Panel, brings up a script window.  Here is the Boss script:

 

image

 

As you can see, the script editor has full intellisense support, well if that wasn’t a trademarked Microsoft term that is.  What’s the non-trademarked term… code hints?  Anyway… it has them, and I love ‘em.  It’s not as detailed as you might be used to in Visual Studio, but its a great help.  That ? icon to the right brings up context sensitive help too, so highlight a function name and click that button and it will open the reference help to that entry if found.  Handy.

 

Each of these floating panels can also be docked within the main editor, here is the script panel docked below the Engine View for example:

 

image

 

The script editor looks remarkably simple, but there is a great deal of functionality hidden in there.  For example, there is a full snippets library:

 

image

 

In addition to the Script Editor, there is also a full script debugger:

 

image

 

With all of the traditional components you would expect, breakpoints, watches, type inspection, it even allows you to connect to a remote device for debugging.

 

Perhaps coolest of all, by clicking the highlighted debugger, you can invoke the code profiler.

 

image

 

Allowing you to identify performance bottlenecks in your scripts. 

 

 

Terrain

 

Creating Terrain in vForge is a straight forward process.  In the Shape Creators tab, simply drag a Terrain over to your scene:

 

image

 

You will then be prompted with this dialog:

 

image

 

Then its a matter of configuring your terrain:

 

image

 

And presto, our landscape, using the default settings and sand texture:

 

image

 

Now fire up the Terrain Editor and you can raise, drop, smooth, paint, etc… your terrain.  Select the tool, and hold down SHIFT or CTRL and Left Click to paint.

 

image

 

And after playing around for a few minutes:

 

image

 

Obviously I am just playing around and using a fraction of the tools.  You can paint mesh (instances) directly on to the terrain, paint billboards ( textures that always face the user, useful for grass and similar effects ) as well as set up sky boxes including full day/night cycles.

 

In fact, there are dialogs for editing the sky:

 

image

 

Editing time of day, including the effect, sunset and sunrise times:

 

image

 

As well as fog editing and post processing effects ( glow and tone mapping, two settings you chose when initially creating your project ).  So the terrain editing tools are fairly comprehensive.

 

Particles

 

Of course, particles are a heavy part of almost every modern tool and of course, vForge includes a suite of tools for working with/ creating particle systems.  In the form of the particle editor:

 

image

 

This is one of those things I have always sucked at, so it was comforting to see the templates when I clicked the Create a new particle effect button:

 

image

 

The actual editor has a few hundred different settings for your particle system, if you create a particle system, then set it to your newly created system, you can press the play button and watch your change in real time.

 

 

Physics Integration

 

As you can see, Havok Physics is also directly integrated into vForge

 

image

 

Of course, that is only part of the physics equation…  the global part.  You are of course going to need to add physics to your scene.  This is accomplished by means of components.  Add an entity to the scene, define its model type, then you can add a component easy enough.  In this case, i’ve add an entity with a ball model.

 

image

 

Here we selected then entity then added the Havok Rigid Body controller.  As you can see, there are a number of parameters you can play with for Rigid Bodies:

 

image

 

Of course, rigid bodies aren't your only option when it comes to physics.  There are a number of constraints you can add as well ( under the Shape Creators ), such as adding a Terrain constraint to the Terrain object, which will then cause our Rigid Body Ball in interact with the terrain.

 

Mobile Helpers

 

Mobile development has it’s own special difficulties, two of which Project Anarchy has a nice solution to.

 

The first common issue is the deploy cycle.  Generally what you do (on Android) is create an APK, which is your application and all of it’s data bundled together into a single package.  So what happens when you change a few small things then want to test it on device?  Well, you create a new APK file and deploy it.  As your application grows in size, this process gets more annoying.

 

Enter vFileServe, which can either be run in vForge or as a stand alone application.

 

image 

 

Essentially it acts as a virtual file system.  You deploy an application to your device ( using the Prepare Devices Button), which then syncs files between your device and vFileServe using wireless.  This allows you to make changes and do rapid on device testing.

 

Another common problem with developing for mobile devices is emulating the controls.  Multi-touch and motion controls specifically are often difficult to replicate on a PC.  For this Havok provide the vRemoteInput plugin, which enables you to use a mobile device to control vForge.  It is enabled in code however, so there is very little I can show in terms of screenshot.  Basically once enabled, when you go into “play” mode, your game can be controlled using your devices touch screen and motion sensors.

 

Shaders

 

There are also comprehensive tools for dealing with shaders.  The first and easiest to use is the Visual Shader Editor:

 

image

 

This tool enables you to create shaders by linking items and operations together.  For those that prefer direct access to their shaders, there is also an editor:

 

image

 

On top of this, there are panels for creating and managing shader libraries, property inspectors and more.

 

Havok AI

 

AI is obviously a big part of game programming and the user is often left to roll their own.  Not so in Havok, Project Anarchy includes the Havok AI suite.  This is a combination of a set of tools integrated into vForge, as well as many AI related functions available to the programmer.

 

Here are global AI settings:

image

 

In vForge, you have the ability to set up Nav meshes, which consists of geometry that define the navigable portions of your game:

 

image

 

You also have the ability to makes paths ( bezier splines ) for AI to follow, triggers and more.  The majority of Havok AI seems to be on the developer side, with a large number of api calls for things like determining the best path, etc.  I need to look into Havok AI in greater detail later.

 

Havok Animation Tool

 

This is another entire application, seemingly for making animation state machines, so basically for “gamifying” your rigged animations.  Yeah, I think I made that word up.  Truth is, I am not an animator, so this is way outside my pay grade…  anyways, here is Havok Animation Tool running an included example project ( located at C:\Users\Mike\Documents\Havok\Havok Animation Tool 2013.1.0.0-r1\GameAssets\Hero on my PC ).  You can control the characters animations using a game pad.

 

image

 

Again… not my realm of knowledge, so I know very little about this tool.  I believe this was a good part of the product known as Havok Behaviour.

 

Other Tools

 

There are a collection of other tools that are part of Project Anarchy as well.

 

One is the Visual Debugger

image

In Havoks words:

The Havok™ Visual debugger (VDB) is a very convenient tool to monitor the physics representation of a scene in real-time. By watching the physics objects in the visual debugger, you can quickly locate any potential errors, which may not have been located by viewing the scene in vForge alone.

 

vFontGenerator

image

For creating fnt bitmap font files.

 

vSceneViewer for viewing scenes (outside of vForge)

image

 

vModelViewer the name pretty much says it all, for viewing Project Anarchy model files:

 

image

 

vAnimTool You can load a model and anim animation file preview and edit animation sequences:

 

image

 

Art Pipeline Tools

 

There are plugins for Max and Maya for exporting 3D content.  I don’t have either currently installed, so I can only show this screenshot taken from the documentation:

 

image

 

So then… what happens if you don’t have Max or Maya?  Well, you are out of luck.  There is a 30 day fully functioning trial available, but unless you are a student there is a 5000$ pricetag at the end of that trial.

 

Fortunately, that is just a temporary problem, from the ProjectAnarchy answers website:

 

Based off the community feedback we are currently working and testing an FBX importer. We realize that many users in the community use other modeling packages and the FBX importer will help those users with being able to get their assets in.

 

Once that importer is available you will suddenly be able to use tools like Blender, Cheetah, Poser/Daz, Silo, etc.  Basically any tool that exports FBX, which is just about every modern app.

 

Summary

 

There’s tons of functionality packed in this engine, and this is just looking at the tool side of the equation.  Of course there are dozens upon dozens of APIs behind the scenes as well.  In the future I will look closer at how you actually put it all to use.  Let me know if there is anything you specifically want covered.

 

I will say, I am a lot more impressed than I thought I was going to be.  I thought it would be a bunch of poorly documented tools mashed together with minimal documentation.  In reality, it’s a remarkably cohesive and powerful package that covers almost all of the bases.  They certainly have my interested piqued.  Good job Havok!

General Design Programming


GFS On YouTube

See More Tutorials on DevGa.me!

Month List