Game Text...

                This post has to do with a Human Text reaction system.  It was a common tool used in many telnet games, as well as similar principals are pulled in from Intellisense, and even web searches in some places.  It’s the ability for the application to determine ideas of what you meant from less letters than even a complete word.  A simple idea is a text based game that you have to constantly move East, West, North and South.  It would be a pain for the players to have to type West 20 times in order to go from one city to the next, so the words can be “shortcutted” (interesting word).  Instead of typing in “west” you could just type “w” and it would determine that the most logical word is West, and treat it as if you had typed the whole word.

                I happened to build one out of boredom the other day, so I figured I would share that.  The code is fairly well documented, so this is only going to cover the principals, and basic use of it.  First off, it should be noted that this needs more than a light understanding of C#.  It’s using Events and Delegation, which is roughly the same as turning methods into variables so they can be set, replaced and passed around. 

                Essentially, the first word in a line is a command.  In my case I chose the word “Verb” to name the class for it.  Essentially a Verb is given a word that it relates to, and then it is tied to a method, so if it ever gets triggered, it will call that method.  That part only requires a simple understanding of delegates.  The next part of the complications was in the “Manager” class. 

                The Manager can hold multiple verbs.  When a new verb is passed into it, it looks inside its list of verbs and places it in Alphabetic order.  So if you added West, then North, then South, it would be sorted as North, South, West.  A command called Execute in the manager separates out the first word from the text passed into it, then compares it against each word in its list to see if it matches up.  So, when I type in “s” for south, it goes to the first word, and compares the first letter, “s” does not equal “n” (the first verb being north), so it moves on the next word (south) and sees that the given letter “s” matches.  Once found, if executes that verb, passing in any additional text that was with it.

                When the manager is created, it needs a verb to execute incase it doesn’t find any matching verbs.  So if I typed “X”, which has no verbs, the manager would trigger the “unknown” verb. 

                There is one step farther.  Some words are used far more commonly, like North, South, East and West for various games.  (The words would be different for different systems)  Given this, I wanted to give priority to certain words over others.  Let us say that my game had a command called “Next”, which automatically reads the latest message or something similar.  My players now have to type in “no” at minimum for the system to know they meant North.  Or worse yet, perhaps there is a verb called “Norse” if my game has certain mythological tendencies of some sort, now my players have to type in “nort” before it recognizes “North” as the verb. 

                The priority system is simple.  If you want 2 levels of priority, which should probably be the most you ever use, then you create a “PriorityManager”, with 2 priority levels.  This class would then create 2 managers, and assign each one a priority.  This system treats the lowest priority as the lowest number.  It also uses 1-Based indexes, instead of 0-Based indexes.  It creates its own unknown verb for the managers, and when one manager doesn’t know the word, it passes it all on to the next.  If it gets through all the managers unsuccessful, the priority manager calls its own unknown, to let the system know that the command is unknown.

                The attached project was written in VS 2010 Beta 2, as many of my personal practices and projects are now written in that.  I believe it is free for everyone to download from Microsoft, but the CS files are easy enough to import into C# Express 2008 or 2005.

Download the Project Files Here

Collision Detection...

There are many ways to do collision detection in games, but only 1 I recommend.  1 method literally prints both images over each other, and checks each border pixel to see if its colliding with another from another object.  Imaginably, this can take a while.  Another checks each boundary as a box and uses basic if statements to determine how effective it is.  The third, and one I will recommend is using a Pythagorean distance checking formula.  First, I’ll get into the bounding boxes, and consider what it takes. 

With bounding boxes, you make the presumption that each of your objects fit within a rectangle.  Each object gets a location vector (Vectors were discussed in a previous article), and a Dimension vector that defines the rectangle’s height and width.  In order to compare the bounding box, we need to find out if any part of the box in inside the other. 

To do that it is somewhat straight forward, but repetitive and with small changes.  Essentially, you need to consider each border. And whether or not it is inside the other box.  Lets Presume, the following Object Fields:  Box.X, Box.Y, Box.Width and Box.Height.

The first part is easy.  Are either of the vertical sides of Box2 to the right of Box1.X.    If either are to the right of the left side of the box, it has the potential of being inside the box.

Boolean CollisionDetection(Box1, Box2)

{

If Box1.X < Box2.X OR Box1.X < Box2.X + Box.Width, Continue checking;

}

               

                Another way to write the same line, is to decide to stop checking, Like so:

Boolean CollisionDetection(Box1, Box2)

{

If NOT (Box1.X < Box2.X OR Box1.X < Box2.X + Box.Width), Return False

}

                Essentially at each validation line of the collision, it can stop processing, to save work, when it has already determined that it can’t be touching.  The line for determining the Top is almost the same as the height.

Boolean CollisionDetection(Box1, Box2)

{

If NOT (Box1.X < Box2.X OR Box1.X < Box2.X + Box2.Width), Return False;

If NOT (Box1.Y < Box2.Y OR Box1.Y < Box2.Y + Box2..Height), Return False;

}

                Detecting the bottom and right sides are similar, and to make it easier, I’ll add a few variables.

Boolean CollisionDetection(Box1, Box2)

{

                Top1 = Box1.Y;

Top2 = Box2.Y;

Bottom1 = Box1.Y + Box1.Height;

Bottom2 = Box2.X + Box2.Height;

Left1 = Box1.X;

Left2 = Box2.X;

Right1 = Box1.X + Box1.Width;

Right2 = Box2.X + Box2.Width;

If NOT (Left1 < Left2 OR Left1 < Right2), Return False;

If NOT (Top1 < Top2 OR Top1 < Bottom2), Return False;

If NOT (Right1 > Right2 OR Right1 > Left2), Return False;

If NOT (Bottom1 > Bottom2 OR Bottom1 > Top2) Return False;

Return True;

}

                So this is checking to see if one box is colliding with the other.  This includes checking if one is inside the other.  Reviewing this code though, it takes at least 4 equations, and at least 8 if statements.  So for every comparison you have 12 steps being processed.  At 2 objects to compare, this happens only once, but with 3 objects, you’ll have to repeat this 3 times, and with 4 objects, 6 times.  Lets presume the game has 20 objects on the screen that you need to detect collisions for, that means it has to run this 190 times.  That means 760 mathematic equations and 1520 comparisons.

                Its easy to see that this builds up quickly.  It also limits your areas to boxes.  Sometimes boxes are exactly what you need.  This is often true of Map based games, where things are set on squares (even if the squares are not so visible to the player).  But in free floating games, like flight simulators, water or space games, using circles is faster and easier.   Don’t worry about Cosines or Tangents, this won’t require any Trigonomic functions.

                Pythagorean Theorem is all that we’ll need.  If you haven’t gotten to it in school, or forgot it, here it is; In a right triangle (it has a 90 degree angle) the hypotenuse (the side opposite the 90 degree angle) is equal to the square root of the sum of the other 2 sides squared.

                In plain mathematics, the triangle below, C = √(A*A+B*B).   In code, that looks like C = Math.SquareRoot(A * A + B * B);.  The order of A and B don’t really matter in this case. 

               

               

                The next question is how to apply this to in our code.  X and Y are also 90 degrees apart.  Lets say X is A and Y is B.  What you need is the X and the Y differences, and you get the points where A and C connect, and where C and B Connect. 

                In our new Game Objects, we will use location and radius or size.

//Game Object

{

                Vector2 Location;

                Float Radius;

}

To test if they impact, we will get the distance, and decide if it is greater than the radius of the 2. 

//Compare Objects

Boolean DetectCollision(GameObject g1, GameObject g2)

{

                Vector2 Diff = g1.Location – g2.Location;

                Float distance = Math.SqRt(diff.X * diff.X + diff.Y * diff.Y);

                If distance > g1.Radius + g2.Radius, return true;

                Return false;

}

                This code is considerably smaller.  Vector2 math uses 2 equations for each equation we use on it.  “g1.Location – g2.Location” is the same as “g1.Location.X – g2.Location.X” and “g2.Location.Y – g2.Location.Y”.  There are 7 equations and 1 comparison when checking 2 objects.  For 3 objects, there is 21 equations and 3 comparisons.  For 20 objects there is 1330 equations and 190 Comparisons.  So that is a significant improvement over bounding box collisions.  (As a reminder, that was 760 Equations and 1520 Comparisons, for 20 objects)

                But part of my statement isn’t true.  Bounding boxes can work better in some conditions.  For instance if the most common collision detection is between the player and everything else, and the player is typically at the bottom.  Your first check can be the top border.  If that fails, it can be only 1 equation and 2 comparisons.  Which means your most average check would only be 190 equations and 380 comparisons for 20 objects.  That is dramatically less.  Bounding box comparisons can leave earlier. 

               

                I recommend implementing both systems for practice, and doing some comparisons early in your game to decide which works best and why.   Do some performance testing on how it effectively works.

Vectors in Game Design

                When we first start creating 2D video games, we most often manage the variable X and Y for the object’s location on their own.  While all physics can still be applied this way, it makes it more difficult, and usually harder to enhance your game over time.  The modern world uses Vectors and for good reason.

                A Vector is simple, it holds 2 or more numbers.  For 2D sake, (since 2D has less to explain) we will use a Vector2.  A Vector2 is made up of 2 variables, X and Y.  The X and Y are used in more than just location; they are used for movement, dimensions and ranges.  For instance, perhaps your game needs to know the screen size.  At the beginning you create a Vector2 called Screen.  At any time, your program can ask for Screen.X, which is the width of your screen or Screen.Y which is the height.

//Settings

Vector2 Screen;

Screen.X = 800; Screen.Y = 600;

                Each of the objects in your game also carry a location vector, which defines where they are.  At the drawing cycle of each game loop, it will find each object, and draw it based for its location. 

//GameObject

{

                Vector2 Location;

}

                However, each of those are just setting a variable to identify a location.  Screen defines the Bottom Right Corner of the screen (0,0 being the Top Left Corner) and Location giving exact coordinates for anything that needs to be drawn.  Another perspective is Movement.  Movement, or momentum is a highly valuable feature.  My previous article discusses the use of momentum when applied to a single variable. 

                Imagine that if you pressed UP, it simply subtracted your Force variable (engine torque) to your Momentum.Y.  (By subtracting from the Location.Y, you move the object closer to the top of the screen)  If you pressed down, it added your Force to the Momentum.Y.    This takes care of your momentum for speeding up and slowing down, but now I’ll throw another variable in, Handling.   Handling will define how affective your steering is.  When you move left or right, it will subtract or add your Handling to your Momentum.X. 

(NOTE: “A += 5” is the same as saying “A = A + 5” it is a short cut in most languages used to reduce the typing for this common use.)

                OK, now given past knowledge, we might just say location.X += momentum.X and Location.Y += Momentum.Y.  With Vectors in programming, there are certain overridden operators, like + and – and * and \ and =.  This means that I can say Location += Momentum, and it will Add the momentum to my location, taking care of both X and Y.  If you are using DirectX, XNA or other game engines, this is probably already taken care of,  but if you are writing your own classes, you will either need to add your own methods, or you will need to learn about Overriding Operators and add methods for +, +=, -, -=, etc…

//GameObject

{

                Vector2 Location;

                Vector2 Momentum;

                Void Move()

                {

                                Location += Momentum;

                }

}

                In addition to Adding Vectors, you can also Multiply or Divide them by a single number.  Like Friction.  Such as, Momentum += 0.85. 

//GameObject

{

                Float Friction = 0.85;

                Vector2 Location;

                Vector2 Momentum;

                Void Move()

                {

                                Momentum *= Friction;

                                Location += Momentum;

                }

}

                I leave this article off with a request for you to go try it.   The only way to gain experience and timing knowledge is to practice this. 

Game Physics - Momentum & Friction

                One of the natural progressions in game development is going from a locked speed to a momentum based system.  Originally, you might have had code that made your ship move forward by 2 pixels every time someone pressed forward.  It’s easy, done in a line of code, and you can forget it.  But when it comes to upgrading your character, ship or vehicle, you are now faced with a lot of hard coded upgrades.  Instead of moving 2 pixels, now you move 4 pixels.  Etc… 

               

                I remember the idea of adding physics as one of those near-impossible tasks, primarily because I didn’t understand how it worked.  Below, is the basic idea.  To start with, I’ll commonly refer to the word “cycle”, which means that the game makes its decisions/changes, draws the frame, then moves on to the next.  Each game loop is a cycle. 

                During each cycle, I check if the forward key is pressed.  If it is, instead of moving the ships location by two pixels, I add 0.3 to a variable called momentum.  So if I went from still, to pressing the button, the first cycle would move the ship by 0.3 pixels.  During the second cycle, I add another 0.3 to the momentum, increasing it to point 0.6.  That means this ship is moved 0.3, then 0.6, and next it will move 0.9, then 1.2, 1.5, 1.8 etc…   This means that it smoothly increases.  Suppose you are in a car.  You want to be moving 35, but from 0, it doesn’t just happen the instant you touch the gas pedal.  The car gradually accelerates.  First moving only at 3 feet / second, then 6 feet / second, etc…  until you reach 35.

// Game Loop

{

                If UpArrow is Pressed, Momentum = Momentum + 0.3;

                Position = Position + Momentum;           

}

                At this point, in your game, it will increase in speed until you let your finger off of the forward button.  It will coast at that speed.  As with proof of concepts, this brings up another challenge, the ship keeps moving faster when you hold the button.  The speed gets unreasonable pretty quick.  What you need to do is add a top speed variable.  Let’s say TopSpeed = 2.  Every time before you add the momentum to the location, check if the momentum is greater than TopSpeed.  If it is, then set Momentum = TopSpeed.  This way the ship never moves more than 2 pixels per cycle.

//Settings

TopSpeed = 2;

//Game Loop

{

                If UpArrow is Pressed, Momentum = Momentum + 0.3;

                If Momentum > TopSpeed, Momentum = TopSpeed;

                Position = Position + Momentum;

}

                A quick recap so far, you can add a Force variable, and when you press to go forward, it adds that amount to the momentum.  This is now a variable you can set per vehicle, calling it torque, or how fast you accelerate.  Your TopSpeed variable, which is pretty obvious, which is another easily upgradable value for your individual vehicles. 

                So next, lets add Friction.  Friction isn’t necessarily something you need to add, but its excellent for

cars, boats, planes, etc… where you want the vehicle to gradually lose speed when the vehicle isn’t having the gas pedal pressed.  Essentially, you add create a variable called friction, and it’s value will be 1 meaning no friction, or 0 meaning completely blocked.   A good starting friction is probably 0.85.  At the beginning of every cycle, multiply your Momentum by your Friction.  Momentum * 1 = 100% Momentum.  Momentum * 0.85 = 85% Momentum. 

//Settings

TopSpeed = 2;

Friction = 0.85;

//Game Loop

{

                If UpArrow is Pressed, Momentum = Momentum + 0.3;

                Momentum = Momentum * Friction;

                If Momentum > TopSpeed, Momentum = TopSpeed;

                Position = Position + Momentum;

}

                Friction is easily applied as an Aerodynamic feature for each of your vehicles, which is also easily changeable now, for each different vehicle in the game. 

                There are a lot of directions this can be taken, but I wanted to cover some others, like Force/Torque, Vectors and Gravity, in future articles.  This is an article that is meant to be practiced.  The basics are here.