For me programming (and game development) is all about solving problems. When I proceed in the project the difficult things are always also the hardest problems. Sometimes problems are algorithms like a FOV algorithm or some kind of level generation algorithm. Another type of problem is what I call logic problems. In my projects they are often in the flow of the program: something is happening in wrong time or wrong order.
An example is when you start to write some kind of walking or pathfinding routine. Here usually the game loop is static and can't be used directly in multiple step loops. You need to separate the individual routines and make them stop if some conditions are met. Most automatic routines are like that, they need extra stuff to find out things which typically are found by the player as human component of the logic chain.
I think it's important to solve these difficult problems as soon as possible, but another aspect of it is not only asking how to solve the problem but what is the problem. It's perfectly possible to create "artificial" problems by overthinking, when a simple solution is often the best one. As a micro-managing tool in programming I think it's extremely useful trying to give a clear definition to a problem and also try to find out solutions to it even before programming a single line of code.
Another example of overthinking is the quest for "perfect" routine or way to implement something. It can be fine when you are not planning to release the game any time soon, but in most cases you want to create something that roughly works and then move on to next problem as soon as possible.
One of the annoying things about problems is that sometimes they feel so difficult that you just want to go away and not even try to solve them. It's almost like problems in real life. And like there some people try to solve the problems no matter what while others just ignore them and leave unsolved for a long time, sometimes even many years.
Tuesday 24 March 2015
Saturday 14 March 2015
Thoughts on inheritance
In my experience object-oriented programming concept constructor-destructor rule combined with the idea of ownership has reduced typical memory corruption bugs of C to a point where it has become almost non-existent problem, yet very common source of bugs to C programmers. C++ has also other useful concepts which are extremely simple such as the scope of a class.
In C++ and other object-oriented languages the concept of inheritance is an essential feature, but it's proven to be difficult to use properly. Rather than using inheritance as it was designed I've been using it sparingly and probably also wrong way in the first place. For a long time I was wondering what is wrong with inheritance and I think I've found a good explanation.
The main problem with inheritance is something that many roguelike programmers find in what we call a game engine. It's an idea where data is handled by a program core called engine and the content of game is in the data entirely or as much as possible. We have years of knowledge about engine programming which in mathematical term tends towards infinity. This means you spend ridiculous amount of time trying to write a roguelike engine which turns out to be extremely difficult.
The engine vs. direct approach to game programming is analogous to inheritance and class hierarchy, because both are examples of generic vs. specific case. Even if you write a generic engine you still need to solve the other problem, because each game is specific. I believe this is the root of the problem. You have an idea to write generic class library and/or program using lot of inheritance to make sure no similar code is duplicated, but the result is more or less generic. You still have to create the actual game which often include extremely specific content.
This is the reason why it's easier to create specific classes to solve some problem, because it's more direct style even from the outside it appears to be OOP with classes and all that. The generic solution is as difficult to program as is a game engine that can handle all specific cases of a game. It can be possible, but I think it requires lot of experience and planning, unless you have a talent for using inheritance which I guess few people have, according to my internet research on comp.lang.c++ and other forums.
When you look at the big picture I think object-oriented programming is still difficult to handle after 50+ years of its invention and that's why some people don't like it or they write inefficient code which sometimes can reach strange meta-levels not really required to produce computer programs. OOP can be a trap for people who think they are clever and who refuse to understand the concepts and admit that there is possibly something from which they have only limited knowledge.
In C++ and other object-oriented languages the concept of inheritance is an essential feature, but it's proven to be difficult to use properly. Rather than using inheritance as it was designed I've been using it sparingly and probably also wrong way in the first place. For a long time I was wondering what is wrong with inheritance and I think I've found a good explanation.
The main problem with inheritance is something that many roguelike programmers find in what we call a game engine. It's an idea where data is handled by a program core called engine and the content of game is in the data entirely or as much as possible. We have years of knowledge about engine programming which in mathematical term tends towards infinity. This means you spend ridiculous amount of time trying to write a roguelike engine which turns out to be extremely difficult.
The engine vs. direct approach to game programming is analogous to inheritance and class hierarchy, because both are examples of generic vs. specific case. Even if you write a generic engine you still need to solve the other problem, because each game is specific. I believe this is the root of the problem. You have an idea to write generic class library and/or program using lot of inheritance to make sure no similar code is duplicated, but the result is more or less generic. You still have to create the actual game which often include extremely specific content.
This is the reason why it's easier to create specific classes to solve some problem, because it's more direct style even from the outside it appears to be OOP with classes and all that. The generic solution is as difficult to program as is a game engine that can handle all specific cases of a game. It can be possible, but I think it requires lot of experience and planning, unless you have a talent for using inheritance which I guess few people have, according to my internet research on comp.lang.c++ and other forums.
When you look at the big picture I think object-oriented programming is still difficult to handle after 50+ years of its invention and that's why some people don't like it or they write inefficient code which sometimes can reach strange meta-levels not really required to produce computer programs. OOP can be a trap for people who think they are clever and who refuse to understand the concepts and admit that there is possibly something from which they have only limited knowledge.
Subscribe to:
Posts (Atom)