Documentation: Prince of Persia

Prince of Persia : Developer's Diary

The Artistic Direction:
The Prince of Persia art team went to Cairo in Egypt and the Medinas of Marrakech and Casablanca in Morocco to get inspirations. One main feature will be the rooftops, where players will really rule over the enemies due to the Prince's acrobatic ability. Environments include the Palaces to the Sewers, and the homes of the poor.
Another feature is the Tower of Babel. Players will see it towering over many areas in the game. Finally, the Royal Palace features terraces, apartments, the throne room, and the Hanging Gardens.

The Speed Kill System:
A main feature in it's new combat system is it's Speed Kill systems. When the Prince sneaks up upon any enemy undetected, he will be able to unleash a killing blow. This new feature requires the development team to rethink it's AI so that they can learn how to detect the Prince. If the Prince fails in sneaking upon the enemy, the enemy is able to call upon reinforcements and the Prince is forced to fight them heads-on.
Both the Prince and the Dark Prince will have different sequences for their Speed Kills. The Dark Prince's Speed Kills will be launched by a fast-paced combination of buttons, whereas the Prince's Speed Kills will be based on specific button sequences and very precise timing during a window of opportunity. Their animations are also different, to bring out both character's different personalities.

The Dark Prince:
"Who is the Dark Prince? The Dark Prince is a "corrupt" version of the Prince who has been infected by the Sands of Time. He is a personification of The Prince's darker personality traits: ruthless, reckless, and inconsiderate. But it's still The Prince... He is extremely violent (he takes great pleasure in brutal combat), rude, and completely lacking in morals. However, since he's derived from The Prince, he's quite clever in his cruelty. Think of him as the little devil on The Prince's shoulder. If he wants The Prince to listen to him, he's got to be a little bit charming. "
The Dark Prince utilises a chain-like weapon called the Daggertail. It can be used to manoeuvre around the environment.
To revert back to his normal self, the Prince needs to seek out the Water of Life.

Ai and Animation:
The team spent lots of time defining each creature's personalities, and thus the need comes to define the AI for each one of them. Thus each of the creatures has different behaviours. They also implemented detection in the AI.
The Prince is an acrobatic warrior, thus they need to create hundreds of animations for the Prince. And the Dark Prince also has a complete different personality compared to the Prince, thus even more animations were created for the Dark Prince merciless killing behaviour.

Abstract class

Abstract class:a class that is designed to be specifically used as a base class.
An abstract class contains at least one pure virtual function. You declare a pure virtual function by using a pure specifier (= 0) in the declaration of a virtual member function in the class declaration.

Virtual Function:C++ virtual function is a member function of a class, whose functionality can be over-ridden in its derived classes. The whole function body can be replaced with a new set of implementation in the derived class. The concept of c++ virtual functions is different from C++ Function overloading.


-----------------------the codes for example of virtual class we made---------------------------
/* #include
using namespace std ;
//Monster class with pure virtual functions class Monster{
public:
//we declare a pure virtual function by using a pure specifier (= 0)
virtual void KeyGuardian() = 0; // A function declaration cannot have both a pure specifier and a definition. Example: virtual void KeyGuardian() = 0;
virtual void DaBoss() = 0;
};
//One of the derived classesclass Minion:public Monster{
public:
//virtual keyword need not to be repeated in the derived class virtual void KeyGuardian();//can also be named as just void KeyGuardian();
virtual void DaBoss();
};
//2nd derived classclass BoneFiend:public Monster{
public:
virtual void KeyGuardian() ;
virtual void DaBoss();
};
void Minion::KeyGuardian(){
cout << "Minion says hello in keyguardian mode " <<>DaBoss();
M1[0]->KeyGuardian();
M1[1]->DaBoss();
M1[1]->KeyGuardian();
//this way of definition can actually allow us to squeeze all the information of the monsters created into a single array
}
---------------------------------------------------(END of codes)------------------------------------------------
*/
reading the comments will help u understand the codes.

What will be shown below will be the sample output of those codes.

-----------------------The Sample Output for these codes----------------------------

Minion says goodbye in DaBoss modeMinion says hello in keyguardian modeBoneFiend says GoodBye in DaBoss modeBoneFiend says hello in keyguardian modePress any key to continue

---------------------------------------------------(END of Sample Output)------------------------------------------


The use of this virtual function is to be able to compile all the Monsters information into one single array for easier access for the information of these monsters.

Information about abstract classes and virtual functions are gotten for making this source code is from:
1)http://www.codersource.net/cpp_virtual_functions.html
2)http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=/com.ibm.xlcpp8l.doc/language/ref/cplr142.htm
3)And from the helpful lecturers ^^

To download the example of the source codes:
http://www.geocities.com/slhjlim321/lala.zip

Object-Oriented Game Development : Iterative Development Techniques

Two important, fundamental questions in development ('What order should tasks be performed?' and 'When is the game finished?') are discussed and a single answer is provided for both. As far as development is concerned, the worst thing that can happen is to be writing system-critical code towards the end of a project. It is such a common occurrence that you think someone will spot it and put a stop to it. It will not only stress the team, but also guaranteed to introduce other problems that were considered stable. It's always ideal to prioritise your tasks so that the problem can be avoided. It is rather tricky to describe the criteria for “completion” of a game. Some functionality and features of games that are selling are only of a certain percentage of the ambitions of the game development team. We'll normally revisit the different parts of the code to further improve the game. Thus, we need a system that allows time and space for evolution which will not spend extra time and or end up panicking that distinguishes most development processes.

One of the cons developers have to deal with how different milestones and the schedules are interpreted by production teams and management. To developers, schedules represent how well a product will evolve over time while the management see it as a contract between them and developers, promising certain things at times. Thus, developers often have to work long hours under pressure to get “promised” features out and the management have responsibility for financial balances that depend on the features being in place. Development of a game should not be shown to the management no matter how much the developers want to impress the management. Otherwise, it will just lead them to doom! It is always right to prioritise and do the most important tasks first and the superficial tasks last. Application is defined as of release quality if and only if its required features are at the nominal level. It is referred to as complete if and only if its desired features are at the optimal level. From these definitions, we see the difference of a product that cannot be sold all the way up to implementing and polishing every feature the specification has. It just gets better and better, and – provided that the tasks have been prioritise and undertaken in a sensible order – can be released any time after it becomes of release quality. Another point to note is that Object Oriented development is perfectly suited to a level-based scheme (and conversely procedural development does not adapt as easily). By writing an object in a suitably object-oriented fashion, we may end up with a reusable component.


2 things the author recommend doing:

• It places a greater emphasis on getting the most important games systems to a releasable quality. It also means we can get to work on one or two of the flash bits earlier, and from week to week, we can see both growth and improvement in our game.
• Communication is important – all programmers should know what other programmers are doing via code reviews. They should be clear and informatively documented (either via meaningful commenting or actual paper or electronic documentation) and systems should be engineered to be as self-contained and maintainable as is humanly possible.

2 things the author don't recommend doing:

• The disadvantage is that after the base level, no new functionality appears – it only improves the existing stuff. While this is fine if you view it from a purely theoretical standpoint, it does make it difficult to impress others.
• If there is only one programmer and he/she is absent from work, who will be able to do the work when only the programmer understands his/her own work? And what if there are more than 1 programmer and there is lack of communication among them, there will be a loss of momentum whenever programmers change task. Although the changes are probably smaller, it can happen several times over the course of the project, and the damage can be intensifying.