Is an Object-Oriented Game Engine necessary? (2)

Now, what is an ideal game object design in an object-oriented language? I think that a good game object design has been completed at former time. So a video game programing has been implementing a factor of object-oriented design since that time.

It's important that video game programers of the time did not want to realize object-oriented programing. They had been questing for productivity development and exciting video game. There is something that we should learn.

We can use full spec object-oriented programing language. I wrote that it is the cause that disorder our game object design at the previous entry. But video game programers of the time could not use C++ (and C!), so they used machine languages. A project that I have joined first was written in assembly. Under such a condition, programers can not quest for object-oriented design, so its design gets a good balance for game naturally.

Check it. The technique that we have used is Task System. Of course, video game programers are using this technique now with C++. But, programers of the time wrote the Task System in assembly, so current way and old way have difference.

Task System is one of popular video game development methods. That is a primitive memory block that consists data and jump addresses. Rewrite jum addresses to change a behavior. Call backed code can access member data by offset access. Polymorphism already came true. There is no "type", but it is similar to the compiled result of C/C++. We write this in C++ now. C++ has the vtable concept, so C++ can realize polymorphism better.

On the other hands, our project forbad that a task block accesses a jump address of other task blocks. In other words, we forbad the message communication between game objects.

It is not safety that a task block accesses a jump address of other task blocks, because there is no 'type'. C++ can handle it more better, because we can write safety down cast comparatively in C++. But, it's also difficult to debug. Another reason why we forbad it is that we could not find a merit from such a way.

Child tasks control own. But if these tasks need to work with other tasks, the parent task which is a manager role for children does the work. I don't know whether this way is optimum solution for us. But, it was easy to debug, tune and tweak, and was flexible for change.

Because there was not term "Object-Oriented" around us in those days, we didn't quest for it. Complacency of programers did not disorder game object design.