Some ideas ......

A long time ago, I began to worship the design idea of "Gao Daquan. It may be because the influence of ogre on me at the beginning of my entry made me stubbornly think that the engine should be like ogre, beautiful to almost artistic design, full of classical style.

But in a painful and exciting process of self-challenge, I kept fading my skin from this layer of deep attachment. It tried to block and made me very painful, but in the end, I realized that there was no optimal design-no silver bullets in practice. I must learn how to give up, and I must learn to give up any possible limitations in order to gain salvation and new life for myself.

Until the beginning of this year, I still had hope for a system that could "function restrained while resisting external harm", but in the face of reality, I finally found that art, when it is placed in an elegant place, it cannot be profane; but if it is in the swamp, it will be useless. Unfortunately, a requirement is a swamp, which is complex and changeable and cannot be considered. It is very likely that you are still excited to step on the stone, and the next foot has moved towards the passage of death ......

If we put everything a little simpler, in fact, the Code eventually comes down to every feature that is independently supported, and where it is repeated, it is often prone to specific functional points. Encapsulation, of course, can be understood as a top-down process facing a huge and complex system as a textbook, which can describe a complete world, but in fact, why can't it be understood as a bottom-up process of independent and self-improved support points and interfaces for each isolated functional point and support point? Or, in fact, more situations are: top-down design, bottom-up design, fierce exchanges and conflicts in the middle layer, and mutual attempt to swallow each other, and strive to maintain their own influence. The two opponents are evenly matched, and they have been in such a conflict since the beginning of the project until the end of the project.

It comes down to the engine. In the past, my ideas, as I said, were complex class structures and complex scenario systems. But now, I am beginning to believe that a sound middle layer will inevitably require independent functions and a complete structure, the establishment of underlying modules with clear interfaces -- this is not simply about VB/IB/camera and other things. I used to outline the terrain, space, and scenario structure into the core of the scenario. However, in addition to making the scenario on the middle layer rigid, it also forces a lot of unnecessary things, these simple and short modules are forced to bear the weights they cannot bear.

For example, the terrain is actually a special set of mesh. The spatial segmentation and scene structure are generally the analysis, reconstruction, and calibration processes for an existing mesh and mesh group. In this way, generally, after the corresponding component process is completed, all these things are left with only a set of special tool methods (for the terrain, the determination of the level of details, and for the space, space Location and traversal) and a large number of information functions. Object? Objects in scenarios? To the middle layer.

Use a complete middle layer as something you can publish. However, the lower layer, the core of the engine, retains some free, stiff, self-closed, and transparent isolated functions, maybe a better design?

I'm not sure, but since it started, we should continue ......