Skip to main content

Studying Metal Slug's Engine

There's a Debug Menu in many titles from the Metal Slug series. Today I played around with that debug menu in Metal Slug X, especially I turned on 'body rect' and 'attack rect', which revealed how the game works. Now not only did I have tons of hours of fun, I also studied a lot from this amazing game!




Of course the following are only my observations, or my best guess on how they have been implemented the game. Although I think my interpretation should work, but it's definitely not the only way, and it's quite possible that the developers have achieved the same effect with another (maybe better) method.


First Impression


At the first glance, the debug drawing is far cleaner than I had expected, it seems that it's not tiled based physics at all. But note the thin shadowed area below the line, which may imply that it's still using tiled based calculation somehow.



Edges


The ground is described as line segments, from the way the shadow is drawn I think that those are directed edges, so we know that on which side shall we keep things. Actually I think that all the edges are half-platforms, will talk about that below.

 In this picture, an obstacle is mark with 3 line segments, clever & cute! 


Rectangles


Besides the edges, there are two types of rectangles, 'body rects' (marked with a pair of right angles) and 'attack rects' (marked with a pair of arrows).

All the rectangles are axis aligned, even if they disagree with the visual. The missiles in the above pictures are heading toward different directions, but their body rects are still AA.  Sometimes we need to approximate the shape with multiple rectangles, for example in the pictures below.

Two body rects for the truck

Note the attack rects of the missles
Note the attack rects on the boss, marking the effective area of the spikes.


My interpretation of the rectangles is that they are using for hitting detection. Attack rects mark the effective area of attacking, and body rects mark the effective area of receiving damages.
About the attack rect of the player, I think it marks the melee range.


Colliding

Objects in Metal Slug can be roughly categorized into the following groups:

- Terrain: ground, slopes, platforms
- Mobs: infantry, vehicles, bullet, projectiles
- Attack areas: logical areas that may cause damage

So let's try to talk about all possible ways of collidings.

Terrain vs Mobs

Terrain collide with mobs only.  Since terrain is mostly marked as line segments, for each mob it is easy to find out which point on the ground is supporting it. One way of doing this is by casting a gravity direction ray right below the mob and find the first intersection point with the terrain.

How to find the intersection then? I guess the game is using the line sweep algorithm from left to right. A clue is that there are never vertical edges, which do not have upper side and lower side. Whenever the game wants to setup vertical obstacles, unit squires are used, as in below: 


The stacked squares are used to block the player. I think that it may be easier to implement this way than vertical line segments. Also I think the squares are not static body rects, why? see below.


Sometimes multiple squares are used, not sure why, maybe to avoid bugs? Also note that the body rect of the player is colliding with the them, so this proves that body rects are not used for terrain colliding detection. Instead I think that the foot point (don't know the actual term, I just mean the mid-point between the feet) is used.

 

The entrance of a cave, the line segments with squares around them are reversed platforms, they prevent user going up but not going down. This picture also proves that the foot point is used.

More examples:

 

A door.

Steps.


There are still some questions left:
 - Are the line segments represented by two endpoints or tiles? Both might be possible, but tiles may be more consistent with the squares
 - Why using all those reversed platforms inside (the door and the cave) entrace? I think it's enough to use the lowest one only. One possible answer is for robust.



Finally, the joints:

When a slope intersects with horizontal edges, special care must be taken, as marked in the screenshot. Interesting.


Attack Areas vs Mobs

Attack areas only collide with mobs. It's pretty straightforward,  if a mob collides with an attack rect, it may receive damage - need more logic checking, e.g. friendly fire. There are also other cases like saving hostages. It's too intuitive to put more words here.



Mobs vs Mobs


In Metal Slug, usually the player doesn't collide with enemy infanty. But there are exceptions:

This is the rightmost position I can reach from the left side of mummies. Note that I can jump into them from above, but will get pushed away gently.


This is the leftmost position I can reach from the right side of zombie dogs. Note that in this case if I try to jump onto them, I will bounce up instead of fall through.



With tanks it seems to be more complicated, it behaves differently when I try to approach from left and right. I didn't figure out if it's using the foot point of the body rect. There could be another type of rectangle, or there's an offset on the x axis.



Summary

So these are what I've got so far. I don't know why I haven't though of this idea before.

The using of directed edges and foot point is quite effective, since it's point-line segment intersections, which is much faster than polygon intersectons, or even AABB. Tunneling effects can be detected this way. And jump platforms are natural to implement.

On the other hand, this design justifies for Metal Slug, but may not for other games. Because the body rects may collide with the terrain, which may look weird in pure tiled based games like Super Mario. In Metal Slug, however, it's ok, since the background is not tiled, and we can see 'side faces' of '3d objects'.

Metal Slug has always been one of my top favorite games. Now there's a new way to play with more fun! I'd like to play through the series again with all the rectangles turned on!

Rocket lawn-cher!
Enemeee chaser!
Mission Complete!

Comments

Popular posts from this blog

Determine Perspective Lines With Off-page Vanishing Point

In perspective drawing, a vanishing point represents a group of parallel lines, in other words, a direction. For any point on the paper, if we want a line towards the same direction (in the 3d space), we simply draw a line through it and the vanishing point. But sometimes the vanishing point is too far away, such that it is outside the paper/canvas. In this example, we have a point P and two perspective lines L1 and L2. The vanishing point VP is naturally the intersection of L1 and L2. The task is to draw a line through P and VP, without having VP on the paper. I am aware of a few traditional solutions: 1. Use extra pieces of paper such that we can extend L1 and L2 until we see VP. 2. Draw everything in a smaller scale, such that we can see both P and VP on the paper. Draw the line and scale everything back. 3. Draw a perspective grid using the Brewer Method. #1 and #2 might be quite practical. #3 may not guarantee a solution, unless we can measure distances/p...

[转] UTF-8 and Unicode FAQ for Unix/Linux

这几天,这个东西把我搞得很头疼 而且这篇文章好像太大了,blogger自己的发布系统不能发 只好用mail了 //原文 http://www.cl.cam.ac.uk/~mgk25/unicode.html UTF-8 and Unicode FAQ for Unix/Linux by Markus Kuhn This text is a very comprehensive one-stop information resource on how you can use Unicode/UTF-8 on POSIX systems (Linux, Unix). You will find here both introductory information for every user, as well as detailed references for the experienced developer. Unicode has started to replace ASCII, ISO 8859 and EUC at all levels. It enables users to handle not only practically any script and language used on this planet, it also supports a comprehensive set of mathematical and technical symbols to simplify scientific information exchange. With the UTF-8 encoding, Unicode can be used in a convenient and backwards compatible way in environments that were designed entirely around ASCII, like Unix. UTF-8 is the way in which Unicode is used under Unix, Linux, and similar systems. It is now time to make sure that you are well familiar ...

Moving Items Along Bezier Curves with CSS Animation (Part 2: Time Warp)

This is a follow-up of my earlier article.  I realized that there is another way of achieving the same effect. This article has lots of nice examples and explanations, the basic idea is to make very simple @keyframe rules, usually just a linear movement, then use timing function to distort the time, such that the motion path becomes the desired curve. I'd like to call it the "time warp" hack. Demo See the Pen Interactive cubic Bezier curve + CSS animation by Lu Wang ( @coolwanglu ) on CodePen . How does it work? Recall that a cubic Bezier curve is defined by this formula : \[B(t) = (1-t)^3P_0+3(1-t)^2tP_1+3(1-t)t^2P_2+t^3P_3,\ 0 \le t \le 1.\] In the 2D case, \(B(t)\) has two coordinates, \(x(t)\) and \(y(t)\). Define \(x_i\) to the be x coordinate of \(P_i\), then we have: \[x(t) = (1-t)^3x_0+3(1-t)^2tx_1+3(1-t)t^2x_2+t^3x_3,\ 0 \le t \le 1.\] So, for our animated element, we want to make sure that the x coordiante (i.e. the "left" CSS property) is \(...