Use Vector Regions to Implement Field of View in a Flash Game

In this tutorial, you will learn how to cast a field of view of a turret guarding a specific location. When an enemy is within the turret's field of view, the turret will shoot at them. Vector math will be used to help in implementing this field of view.

---

Final Result Preview

Let's take a look at the final result we will be working towards. Click on the turret at the bottom of stage to begin the simulation.

---

Step 1: Field of View

I’m sure most readers have used cameras. Every camera has a view angle, defined by the type of lens attached. There are narrow and wide view angles. View angles constrain the field of view into a sector. From a top-down position, they look like the diagram below. If you take a picture, eveything within the grayed area will be captured.

The turret's field of view in our simulation is like that of a camera. If there's an enemy within its field of view, a guard will respond (sound an alarm, take aim, shoot, etc).

---

Step 2: Basic Concept

The diagram above shows the field of view of turret. Usually the angle of view will be equal on both the left and the right. The radius will also be consistent throughout the sector. So to check whether an enemy is within a turret's field of view, these two mathematical conditions can be used:

1. Distance between turret and enemy is less than radius.
2. Angle from turret's line of sight to enemy is less than 30°.

---

Step 3: Define Field of View Using Vector

We shall use vector math to help us. In this case, the vectors in consideration are vLine2 and vLine3. We can:

• Compare magnitudes of vLine2 and vLine3 to validate Condition 1 from Step 2.
• Compare angle sandwiched between vLine2 and vLine3 to validate Condition 2 from Step 2.

Read more: Use Vector Regions to Implement Field of View in a Flash Game

How to make a 2d platform game – part 2 collision detection

Hello and welcome back to my blog!

In this series of articles, I’m talking about the technology behind a platform game.

If you missed part 1 you can check it out here.

The language is actionscript 3.0, but the techniques are applicable to all languages.

In this particular article I’m going to talk about the physics, collision detection and AI aspects of the game.

The Game

There is a playable version at the bottom of the post, for those with Flash support in browser.

Class hierarchy

It makes sense at this point to talk about the class hierarchy I’ve used in the game, to represent everything which moves:

Figure 1

Figure 1 shows the class hierarchy – at the very top sits MoveableObject, which is where all the generic collision detection and response gets done; I say generic because the player does specialised work to handle things like ladders etc.

Each level in the hierarchy represents separate functionality; for example, Character contains the AnimationController which handles playing the various different animations for each character, SimpleEnemy represents a certain class of enemy character which does no collision detection with the world, and obeys special position markers when it encounters them. The Diamond pickup is a simple object which has no AI, and just collides with the world, so it inherits from the base class, since that’s all the functionality it needs.

This may seem like a lot of extra complexity for such a simple game, but it really makes adding new enemy types very easy indeed, and simplifies the debugging process because there is so much code shared between each object.

If I had to give one piece of advice from 10 years of game development it would be this: avoid code duplication at all costs. It leads to slow development and bug city whereby you fix a bug in one location, and then forget to fix it in the other duplicated locations.

MoveableObject has certain properties which it requires be implemented by any class which inherits from it:

• m_HasWorldCollision – whether full collision detection should be performed
• m_ApplyGravity – whether gravity should be applied
• m_ApplyFriction – whether the world collision should apply friction

That way, and child class can chose what elements of collision detection it wants enabled.

Consider the following snippet from the Skeleton character:

Read more: How to make a 2d platform game – part 2 collision detection

Create REAL explosions with Box2D

Look at the title… Create REAL explosions with Box2D… keyword: REAL.

This means we will make a Box2D explode into pieces using the basics of Slicing, splitting and cutting objects with Box2D. At the moment it’s just a prototype but it does not need that much optimization.

That’s what we’ll get:

Click the mouse to make the box explode.

Too fast? Get this slow motion example:

As you can see, this is a real explosion.

This is the source code, can you discover how was it possible?

Read more: Create REAL explosions with Box2D

Monitoring the Loading Process in Flash With the Loader Class

In AS3 projects, you often need to load external assets like images and other SWFs. While loading these assets you have to keep track of several events for successful execution of your application. You might have been using some of these events like ProgressEvent, COMPLETE event. This tutorial shows you how to get info about the assets you’re loading with Loader.load(), using its associated events, all in one place. So if you’re having difficulty loading such assets, or you have less time in hand to debug, take a look at this.

(Preview image courtesy of VisualPharm.)

---

Final Result Preview

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

This SWF loads an image, showing details about the loading process (progress, whether it’s complete, and more).

It won’t work embedded in this page (which shows you the responses in case of error) but it will work if you load the SWF directly.

---

Step 1:The need to load assets

Hey, if you are in a hurry, you can skip this step. But, if you are relaxed, with a cup of coffee in hand, have a read.

In the early days when I started learning Flash 5 and AS1, I used to have all objects on the stage at once, and made them visible/invisible as required. Eventually as I started developing apps, I became more familiar with Flash’s system. Wow, now I was able to use “linkage identifier” to load objects from library. Getting more advanced, I soon realised the need for external assets. But unfortunately, there was no such powerful architecture. Meanwhile, Flash was going through drastic changes. Now “AS2″ was capable of loading external assets. Finally, when it lined up in Adobe’s family, the new event-based architecture “Action Script 3.0″ was introduced. In AS3, the need for loading external assets is much better addressed than in AS2.

So, when working with Flash we have three ways to manage our assets:

1. Put all required assets (MovieClips with instance names) on the stage and manipulate them as required.
2. Put all required assets in the Library and access them using “Identifier” in library panel.
3. Put all or some required assets outside Flash and load them dynamically.

The first method is not versatile. As the number of objects increases, the size of the SWF also increases (especially when there are lots of images). Imagine how much time it can take to load on user’s machine? Also, the performance of your application might degrade. But, still it can be handy enough for creating lightweight apps. (E.g. developing a simple game, in which player needs to find out key objects from the given image).

The second method is very much similar to the first one. Instead of having objects on the stage, now they are residing only in the library. Again, if there are lots of objects, then the issues with the SWF’s size and performance remain. But with this approach, you can easily create multiple instances of objects. Plus, the objects are much easier to handle than the first method. (E.g. games like “Tic Tac Toe”, “Tetris”, and “Snake” can be developed as they require fewer objects).

The third method (loading assets externally) is much more flexible than the first two. The power of this method is, without having a single object in the library you can still develop big games (e.g. “RPG” style games). As objects are loaded externally, they are loosely tied to your main SWF, so you do not have to go back to Flash every time you want to replace or edit your assets. One more advantage of this method is, it allows you to load and display objects on an “On Demand” basis. Meaning, you can load your objects only when they are required and unload them when you are completely done. (E.g. if your game has 10 levels, then you do not need to load all assets needed for all 10 levels. Instead, load and unload them level by level.) Thus, the overall performance of the application is improved.

Note: The above “On Demand” method may not be suitable in case where assets are loaded and unloaded frequently (e.g. in an image viewer app).

Okay, so now we can conclude that, of the three methods, the third one is more flexible. But, as the system gets more advanced, it becomes more complicated to manage. Similarly, if you decide to go with third method, you will need to handle assets as one separate operation. You may call it “Asset Management” which can be divided into two parts:

• Handling assets manually (involves folder structures and operations like cut-copy-paste)
• Handling assets programmatically (involves loading, displaying, and unloading in a program)

This tutorial covers the second part, so let’s look at that now.

As our program loads assets externally, it is now dependent on those assets. If any of our assets fail to load for some reason, then our entire application will be hampered. To avoid such failures, we really have to provide “Decision Making” power to our program.

Here’s one example. You have a coin-flipping game, where the coin is an externally loaded image. Now, if this image fails to load, then what next? This is the perfect point where your program will take some decision(s). It might load another image for the coin, stored as a proxy. It might load the stand-by coin if you have placed it in the Flash library. This can be a lightweight coin made up of vector graphics and strokes converted to fill to keep the size of the main SWF as small as possible. If you do not plan to have stand-by coin, then your program could warn the user about failure.

Of course, this was just one case. For a complete game, you will need to use a mature “Asset Management” system.

Read more: Monitoring the Loading Process in Flash With the Loader Class