Tag Archives: collision

A look at Prince of Persia: The Forgotten Sands game engine

In my last Game Engine Design class which was on Halloween, the disappointment of my professor’s lack of costume was neutralized by showing us videos of two Prince of Persia games; The Forgotten Sands and Warrior Within. We were tasked with identifying different aspects of the game engine of the former, often criticizing some of the inner mechanics despite its blockbuster production values and technological achievement.

Image

Prince of Persia: The Forgotten Sands is a 2010 multi-platform game developed by Ubisoft. Any developer will tell you how tasking it is to design the engine to work with certain consoles, similar to car engines, they need to be carefully constructed with the capabilities and limitations in mind. The version we looked at to my recollection is either the PS3 or Xbox 360 version.

My primary grievance with the engine is the sloppily put together animation layering. Most of what I know from animating layering comes from Uncharted 2 and their hierarchal structure of their character kinematics. How it works is that limbs, hands, feet and other body parts are each animated separately while using triggers to switch between animation states according to either your character’s relation to the world and/or according to your character’s action.

The issue with Prince of Persia: The Forgotten Sands’s animation layering is that it lacks detail and feels rushed, for example. When your character grabs onto ledges or walks on the wall for a few seconds, the hands don’t seem to grip on anything, it feels like that Game Jam game Surgeon Simulator where your hand can’t grip on anything.

Spider Prince, spider prince, the bad layering and lack of collision makes me wince.

Image

A major part of gaming is investment, it’s difficult to invest in your player’s actions if something like grabbing onto something doesn’t feel solid. Internet critic and entertainer Doug Walker, under his persona the Nostalgia Critic, attested Tom & Jerry’s effectiveness in its craft due to how solid the animators can make objects, hence enhancing the slapstick.

This technique can also apply to games. Take Ninja Gaiden Sigma for example, when I look at what Prince of Persia: The Forgotten Sands did wrong, Ninja Gaiden Sigma did right. When Ryu climbs, runs along, or jumps off of the walls, you can feel every one of his steps colliding with force on the wall. An example of lack of solidity would be Sonic Heroes a game I loved since my youth, has an issue with enemies feeling too not rigid to the point where you can almost breeze through them like air when your character’s get strong enough. (I may blog about that game’s engine some time down the future) Naruto Shippuden Ultimate Ninja Storm 3 is a game that manages to have both soft and hard collisions. A combat based game at its core, you have your strong, medium and weak attacks, and naturally they make for collisions of the same level of force provided your attack damages your opponent.

It’s difficult to really attest for the force of collisions in games for a lot of people without really playing the games. Though gaming veterans and people involved in the field should be able to immediately identify such deficiencies.

The game’s biggest issue is its AI and how incompetent they are. You know how in movies every enemy attacks one at a time rather than all at once? That’s the game’s AI to a tee. If that’s what the programmers were going for then I’d still protest that they robbed players of a challenge. It doesn’t help that the AI moves at a snail’s pace, both in traversing towards you as well as their attacks. It takes then, no lie, 4 seconds to land a hit on you. Though your attacks are delayed as well, so it all balances out right? WRONG! That’s just bad combat. It’s not even satisfying to kill them due to the sound effects which sound like you’re being blocked rather than tearing away at their flesh.

Image

Yeah just stand there and look intimidating, I’m sure that’ll scare the guy who can move himself more than 2 meters per second.

Once again I must refer to Ninja Gaiden Sigma, when your attacks are blocked, you hear a metallic sound effect, but when you hit you can hear the sound of your weapon tearing his flesh off his skin or bones being broken. It also helps that said game has brilliantly programmed AI whom are nearly as capable as your character, presenting a lot of challenge, a demand for skill on your part and the satisfaction of overcoming said challenge. Which means you better bring it in the boss battle.
Image
Seriously, have I hammered it into your brains already? Go play any of the Ninja Gaiden Sigma games.

I’ve been pretty hard of Prince of Persia The Forgotten Sands all this long. The truth is, despite its shortcomings, its engine has many positive aspects. One of them is its marriage of the camera system and trigger system. The camera manages to follow your character all over the level, placing itself in dynamic and interesting angles whilst capturing the emotions of the environment and situation. This means that when an explosion happens, the camera moves to emphasize the collision.

Image

Perhaps the best example is when the character swings on poles, the camera very subtly moves along with him as he swings, seemingly taking you as the player along with the ride. Parts where you’re assigned an object through an in-game cutscene, the camera will pan to point out where you’re supposed accomplish your task.

Despite the faults of the animation layering, the kinematics is above average by industry, AAA standards. The screen space ambient occlusion is top notch, and gameplay is most likely fun as ever, wouldn’t know though as I haven’t played it. Modelling, texturing, shader rendering, and movement is all top notch as well.

Image

Warrior Within proves to be a superior product despite its technological inferiority; the engine provides much better animation layering, combat kinetics and overall collisions for all the reasons opposite to that of The Forgotten Sands. The former simply has more polished mechanics. In this battle of supremacy, the old proved superior to the new; hopefully developers take not of what it means to deliver on a polished engine.

Quadtrees vs. Grid detection

Me and my groupmates are making a fighting game by the name of Shattered Tides, like any game we’re implementing collision detection code. There are many ways to implement it, however the real challenge is finding the most effect in the best possible time given our anemic time frame. After looking into it, it would seem that the quadtrees are the most common way to go but in some resources they mention the grid based solution.

So which is better and more effective? The right answer depends a little bit on the actual game you’re making, and choosing one over the other is needs implementing both and doing profiling to find out which one is more time or space efficient on your specific game.

Grid detection seems to solely apply to detecting collisions between moving objects and a static background. The greatest advantage is that the static background is represented as a contiguous memory array, and each collision lookup has the Big O of O(1) with good locality if you have to do multiple reads because entities need to be covered more than one cell in the grid. The disadvantage however is if the static background is large, is that the grid can be rather wasteful of space.

If instead you represent the static background as a quadtree, then the cost of individual lookups goes up, but because large blocks of the background take up small amounts of space, the memory requirements decrease, and so more of the background can sit in the cache. Even if it takes 10 times as many reads to do a lookup in such a structure, if it’s all in the cache, it’s still faster than a single lookup with a cache miss.

Personally I’d go with the grid implementation, because it’s easier to do and would be more productive for me to study. If I notice that our game is running slow, we’ll do some profiling and see what could use some help. If it looks like the game is spending a lot of time doing collision detection, we’d try quadtree and see if that’s any better.

More on Havok, physics and collision

What is the most important aspect of a video game? That’s something that has been debated since the inception of video games, and said question could be applied to its technological, spiritual predecessor which are sports, board games and other sorts of games. Every individual has their own opinion on the matter, and my personal opinion is that the most vital fundamental aspect of any game is interactivity; the point where the player’s choices and the game’s mechanics meet on mutual ground and develop an agreement. All games have rules that allow players certain freedoms and limitations, the player’s enjoyment essentially comes down to what state of mind these boundaries put them in.

Last week we made a very general observation of the Havok physics engine. This relates to my thesis statement as physics are an integral part of a games internal logic; the ability to move your character and do any other action is part of your freedoms, whilst falling in chasms and not penetrating walls makes up your limitations.

Collision detection is important for every game in that regard. Take away any form of collision and every object would fall through the ground with the ground itself, making any form of interaction impossible, unless you’re making a kill screen, this is not a reasonable programming design.

Collision and physics are more often than not a tightly knit pair. This is because at the moment collisions are detected, they are always resolved as part of the engine’s logic in physics and constraint integration.

The purpose of collision in a game engine is to determine whether any of the objects in the game’s world are in contact. In order to properly address this, each logical object is represented by geometric shapes. The collision system of the engine determines whether or not these specific shapes are intersection, which means that the collision detection is system is nothing more than a geometric intersection tester.

Collision systems are more than a true or false question regarding shape intersection. Its purpose is to provide relevant information about each contact. That information can be used to prevent unrealistic visual anomalies on screen. For example, last weekend at game jam, I coded an invisible border at the end of the level to go to the game over screen, an example of collision utilized to convey certain information on screen through the programming interface.

This information is used to prevent on-screen anomalies by moving the interpenetrating objects apart prior to rendering the next frame. They can also provide support for an object, such as an object at rest on the ground thanks to the force of gravity on the geometric shape of the ground acting upon it.

Indeed collisions essentially make up most of the gameplay. Think about it; coming into contact with a health power up, shooting at an object to destroy it, even being on the ground is a form of collision. Collision is the main fundamental aspect of interactivity in games, it supports nearly all of the player functions while fulfilling the main objective of the game, to enforce an experience on players.