Skip to main content

Level design basics, part 15

Game design and level design

They are very closely related. A good method is to make separate
document, that shows the relation points. Game design is like an arch
type to all other documentations. Which of course includes the level

design. One documentation doesn't go without the other. They are co
related, and both very important; two documents should do for the
entire documenation: of course as a document I don't mean 1 page or

any thing like that. Because an entire documentation of either can be
in one extensive document. But for better understanding and
comprehension; by then two documents are optimal. Level design

documentation is mostly and most oftenly a part game design
documentation. Level design is paramount part of game design. It
supports the whole structure together. It is very important, in other

words. A good way to start doing that is by making a separate game
design document. Or a level design section. Write all the references
to the level design documentation. What they both share in common is

the word "design". Designing a level is more than just planning it
and then designing it. They inter vine with each other. They are co
related. They don't go one with out the other. And so they both

require a giant ammount of effort. Making a campaign takes time,
effort and dedication. Game design basically covers all game aspects,
what makes it out standing from other games, game play querks,

challenges. Level design is not only writing about levels, but
covers data as well. So can game design. Data is crucial for the game
to not over flow the computer system with memory information. It has

to be stored in data bases. Game data design can quickly cover a lot
of game design and level design in over lap. Data is a very complex
infomation structure. A data unit basically contains a lot of bits

of information. So there is actually a lot of document over lap
between game design and level design. They are very deeply inter
related. As they cover all other design parts of the game, including

code design.

Comments

Popular posts from this blog

object oriented programming

Object oriented programming is a sound and bold approach to c++ and internet wiring application and video games. It reduces a lot of code messes, made by global and half global functions. One of the more advanced object programming techniques are private access, poly morph and object message inheritance. It is set by c++ bjarne stroustrup and iso isometric standard convention comitee to use classes instead of structs and structures for making objects. Which means you most definitely should , but not must or have to. class Monster {     std::string memory_attributes{}; public:     void treck();     void track();     void trace(); }; The treck() function makes the monster roam and do human like jogging and trimming. track() means the monster goes ai path tracking and trace() means it tries to find other monsters in the area. class Weapon {     std::string memory_attributes{}; public:    void use(); }; void Weapon::use() {   ...

What does a good game consist of? (part 19)

Programmer's Role in Game Development -part 1: Better Code Organization This will be a bit different blog post compared to the previous. It will be a sub-series of the role of programmer in the game development. The first part of the sub-series will explain how a game programmer is more effective alone or in a team. Code organization is in my experience essential, as the amount of code quickly increases, especially if the game has many features. It includes: knowledge of the programming language, APIs, dev kits and make sure you know the techniques with which will you finish the project  list of steps to get there a clear to read and understand GDD a clear task list don't rush to learn everything about everything related to your project-set to make a project which you can actually handle(=have learnt 98%-100% about it) There you go, one step closer to understanding how to make a classic game.