Level design basics, part 8

 Abstract code

Optimally, there should be two or more level design team members, one for graphical
design and one programmer. This is where code abstraction comes in handy. The
graphical part of doing it is to make a level design document in code: 

arena.lvl
Arguments: hard level, hard bonuses.
Design:
main table = circular 4 meters radius

C++ abstract script code:

Level arena_1{};
arena_1.set_script(hard, hard, basic 3);

Such code extraction and abstraction makes hard to transfer documentation into
actual soft ware and hard ware code to more convienient process.

class Ware
{
    std::string data[100]{};
public:
   void draw();
};

The ware class can be used to more correctly bridge the gap between the both
documentation types.

void Ware::draw()
{
    Direct play{};
    for(int iterator{1};iterator<=100;++iterator)
    {
        play.push_x(data[iterator-1]);
    }
}

The class creates a ware house node in the graphical processing unit, so it is more
challenging, but also more convinient to sort through the random access memory.

Ware pixel_1{};
Ware pixel_2{};

Code abstraction makes a level design document more convinient to read for the
programmer or a coder. A ware house node is stored to the random access memory,
but also the central processing unit.

void Direct::push_x(std::string print)
{
    if (print=="array")
    {
        return;
    }
    else
    {
        std::cout << print[1-1];
    }
}

The function prints the system message if the program is console type. Two members
should collaborate and debate on how to improve the level. Basically printing a 3
dimensional square in a video game is hard, so abstraction fixes this problem. In

theory it sounds easy, but it really isn't. Wether it is a first person shooter, real time
strategy or third person adventure game. This is where data abstraction comes in handy.

class Square
{
    int position_x[4]{};
    int position_y[4]{};
    int position_z[4]{};
    std::string script{};
public:
    void draw(std::string parent_type);
};

Same problems arises when making a square in making a 2 dimensional game that
correctly resembles reality, or real world.

arena_collosal.lvl
0 1 12 3 4 5

You would expect only 4 parameters for the square, but there are additional 2 for
colossal challenge input for the monster parameters. You would expect the arena
to be circular from the top down, but it is realistic, which is why physics have to

be applied as well. Such as low-polygon count to improve the frame rate. 60 frames
per seconds is good for level design, especially when making a two dimensional
simulation. Making breathing sounds in a two dimensional stealth games is hard.

And challenging. Code abstraction comes here in handy too. So code abstraction
doesn't make development easier, but actually harder, but also more worth it. People
thinks source code abstraction is to make the coding easier, but where could there

possibly any point in that? Experience points system can be abstracted too.