Technical Document - NontendoSL/Zelda-a-Link-to-the-Past-TRIBUTE GitHub Wiki

• INTRODUCTION

• UML

• CODE STYLE

• TARGET HARDWARE

• PERFORMANCE BUDGETS

• BRANCHING POLICY

• VERSION LIST

• CHANGELIST

• BUILD DELIVERY METHOD

The purpose of this document is to have a CLEAR and WELL-STRUCTURED code. For this, we will follow the style shown below and so any team member (who doesn't know/doubt about how to organize code) can access this document and resolve the doubts.

Click here to Zoom->UML Zelda

• When we create a function, is necessary to put a SHORT DESCRIPTION of its functionality
• Capital letters in UPPERCASE. If the function contains 2 words, the second one need must be capitalized.
• Claudators will have to be ALIGNED.

Test.h

//This is the test
bool Function_Test();

Test.cpp

#include "Test.h"

bool Function_Test()
{
    return true;
}

All variables must be in LOWERCASE, except those with 2 words:

• Verb: the second one in UPPERCASE.

bool canBlit;

• No verb: words separated by a DASH, in LOWERCASE.

class Collider* collision_enemy;
class Animation link_walk_east;

• All defines and enums must be in UPPERCASE.

#define TEST_STYLE

• If an enum is very long it will have to be placed in different rows.

enum Direction{1,2,3,4};
enum Direction_v2{... 100, 101,
102, 103, 104, 105, 106, 107
108, 109, 110, 111, ...};

• First letter of the name in UPPERCASE
• Anything not used outside the class should be kept PRIVATE.
• In addition, the structure should be:
  • 1st) Public functions.
  • 2nd) Private functions.
  • 3rd) Public variables.
  • 4th) Private variables.

class TestCodeStyle
{
public:
    //Load all info before the frist frame
    bool Start();

    //if the player dead, this function will make that he return to home
    void Player_Respawn();

private:
    //With this, the link will can Move
    void Move_player();

public:
    iPoint position;
    std::list<Item*> bag;
    Direction direction;

    uint hp;

private:
    uint speed;
    bool canAttackM

};

Our game needs a PC System of 32Bits and at least Windows 7.

We decided to make the game work at 60 FPS. So we have a total of ~17 milliseconds in each Update, so we will distribute this time for all modules:

Time in ms:
    Collision: '3ms'
    EntityElementsScene: 'Total 14ms'
        Player: '4ms'
        DynObjects: '3ms'
        NPCs: '5ms'
    Scene: '2ms'

We will use Brofiler to check the performance of all modules/classes in our game.

Web Brofiler

Github Brofiler

We only use the branches for testing. All the builds we develop (both Alpha and Beta) will be at the main branch, implementing bug fixing too.

Style: [Big Update].[minor Update].[fixed bug]

Now you can see all versions:

0.1

Map Drawing (Zelda Area)
Link Movement

0.2

Static Enemies with collisions (can drop items)
DynObjects Implmented
SceneIntro

0.3

Zelda UI & Console functional
Gamepad Interaction
Link Normal Attack
DynObject Interaction implemented

0.4

Pokemon combat demonstation

0.5

Victory Road Map Drawing
Victory Road Core mechanics & items (Bombs, Hook, Bow)
Victory Road Pokémon implemented ( sudowoodo, golems, geodudes, golbats, wailords)
Miniboss implemented (Ball & Chain Trooper)
Pokémon menu

0.6

Elite Four Map Drawing
Pokémon combat
Basic Animations (pokémons, enemies, trainers)
Pokémon menus UI
Pokémon items (Potions, elixirs)

0.7

Cutscenes implemented (with Dialogues)
All enemies AI
Pokémon InCombat UI
Final Boss (Ganon)

0.8 - ALPHA

Pyramide of Power Map Drawing
All enemies AI
Starting game menu

0.9

Polish:
Cutscenes
Animations

1.0 - GOLD

Polish

We use Github method to progress in our project:

• 1) Modify the project.
• 2) Commit changes.
• 3) Sync.

The game will be compressed in a zip and it will contain an executable of the game with all necessary .dll. A data.zip whith all the needed files (maps, pictures, audios). It will also contain the README.md (info explaining release changes, controls, additional instructions) and a config.xml.