I haven't written a blog for a long time. In fact, I haven't written a blog for technology for a long time.
Some people say that technology is such a kind of wine. You can taste the sweetness of it only when you are calm. Unfortunately, it has been a mess in my mind recently.
It's raining in Beijing today. It's a great pleasure. It's a rare opportunity for me to calm down and sit here and write something.
---------------------------------------
In the past few days, I have been half-quarreling with cgamer, and I am not doing well at work. I have always been unable to raise my mind. After reading the irrlicht engine with cgamer, he concluded that the engine structure is to extract the maximum degree of variability under the premise of immutability and efficiency. I think I have no objection. What is immutability? I think it is mainly about data and data sets. The core of my quarrel with cgamer is the location of immutability and variability. Perhaps, this is not a problem that we can solve.
For example, if we want to remove the file from the render layer, in addition to render converting the object contact to the label contact (changing the file * to the file name, in this way, in the abstraction of the object level, the file cannot see the render, And the render cannot see the file. You only need to establish object contact when implementing the concrete object .), Another point is that the abstraction layer needs to abstract the data to the end.
Why? Let's assume the following points:
1. What happens if the data is not abstracted to the end and only a minimal imagedata is left? When the image layer of the file is set to imagedata, it finds that many imagedata files are not recorded. Therefore, the file image layer (note that the image layer is not an abstract layer) you must implement your own xximagedata. In this case, the render abstraction layer only knows the file abstraction layer. What should I do when the render abstraction layer needs to obtain imagedata? Of course, you can make imagedata into a datachunk to solve the problem, but this is not very convenient: because the standards are determined by the concrete layer, the abstract layer is even wider, how can we know what has not yet appeared-invisible from its perspective-how to customize this standard for the concrete layer ?!
Another question is: Do I have to be coupled with the file concrete layer in the render concrete layer? It seems that coupling is required. Otherwise, even if you know what datachunk is, you still cannot do anything about how to arrange such values. Fortunately, this coupling is only a standard coupling. You only need to comply with this datachunk Organization standard. The problem is that when the file concrete layer is changed, it is likely that the xximagedata standard will not be followed, but the yyimagedata standard will be supported, which will be depressing. All items related to imagedata must be rewritten or re-modified.
Imagine why we need to separate the abstract and Concrete Layers? What if the concrete layer does not access each other? The main purpose is to disassociate modules from coupling, but the current design only forces us to be unable to disassociate from coupling.
Since the coupling is inseparable, we can try to determine it as immutability. Setting up maximized imagedata at the abstraction layer should follow this standard in both the abstraction layer and the concrete layer. If you do not know what will happen, set up DWORD dwreserved1, dwreserved2 ...... Dwreservedn is used to customize standards for the concrete layer. The most core data is already in your hands. It is much more convenient for the Representative layer to make it easy to create other data, even when the Representative layer is changed. This is similar to the idea of DX. I firmly control the core data and methods, and all variability should be done on the basis of these immutability.
2. However, when this idea encounters a high-level engine system, it will be much more complicated. As we all know, the High-Level engine system can be said to be every game, but in terms of MAP format, the map format is almost completely different for different games. What should I do? May such a high-level core data be abstracted?
The answer is: it is impossible to abstract the core data that is fully adapted to each game. However, we should try to scatter the data into each part and abstract as many patterns and details as possible. Take map as an example: we abstract some details of the map itself (long, wide, and high), and advanced details include area tables and area control methods (such as block and block grid tables ), lightmap and so on may also need to be recorded, or do not record at the moment, it is generated in the map editor instantly, in fact, it is the same. We abstract as many existing things as possible to immutability, which will inevitably consume a lot of space and efficiency. This is the question of designers: between efficiency and development efficiency, what is the trade-off. The map may also be restrained, including the scenario manager type (BSP, quad-tree, And Ock-tree). In this way, the scenario manager needs to be registered based on the currently registered scenario manager, abstract The data required by the scenario manager for these registered managers. There will certainly be better methods, but both cgamer and I are stupid.
If the terrain and map are the summary of many existing technologies and can be abstracted, the objects may be slightly more complex. The solution that I proposed to cgamer and was almost instantly rejected was to use a large amount of reserved data and scripts in addition to basic data. My program: no matter what the concrete layer and the abstract layer do not know what the data is for, it doesn't matter. The data is handed over to a powerful script for processing. For example, in my real-time strategy, btreserved1 is used to specify the labels of all parties. But when I was doing RPG, this btreserved1 started to indicate that this object is a player? NPC? Or trigger? It can be seen that abstract data organizations such as reserved are bound to require a powerful script system as a subsidy. Otherwise, the existence of the abstract data organization will only cause greater confusion. However, this genius (everyone: You owe it to me) was rejected by cgamer in an instant and did not know what he thought. (Cgamer: Do you dare to say something bad about me ?!)
Well, if you have any better ideas, please let me know, reply to them, or send a message to laburas at sohu.com (at should be @, no @ to avoid searching by many email search tools ).
--------------------------------
Another headache in the last few days is the input method. The pseudo full screen and ime in windows, Linux do not know. This should be a standard method, but cgamer does not seem to want to use it. There are not many input methods that support ime. It is said that Microsoft Pinyin also has a problem with IME support. Only smart ABC is the perfect standard. This is not clear to me. We all know that pseudo-full screen reduces efficiency. Anyway, I have been upset for a while recently, so I often do this when I get off work and check the information. A Linux-based open-source little penguin input method is very good. But to be honest, The unannotated function seems to me sweaty. Fortunately, the system itself is not big.
In the future, it is estimated that there will be something like this: the job is to package and upload tools, continue to quarrel with cgamer over those ideas, and finally look at the input methods. God bless, maybe this day will soon end.
