Maybe this is not a topic that many people are interested in, but it is true that XGE project has been running well recently, even making progress every day, but it is too tedious to provide it in the form of log, so I will talk about my views on game engine before the new version is released soon.
In fact, this project has a history of more than ten years, but due to various reasons, I repeatedly gave up and picked it up again, so that ten years passed quickly.
At first, I only wanted to develop a game of my own, but the technical requirements of DirectX and OpenGL blocked me. Although I finally got DirectX on VB, because VB6.0 is not an object-oriented programming language, I can't use it to realize a game that looks good. Finally, I reset my work on FreeBasic.
Of course, my understanding of programming ten years ago was not enough to support me to realize the same thing I did in VB by calling DirectX directly. Therefore, I have to look for other tools that can meet my needs. There seem to be many options, but when I get to know them deeply, even after using them for a period of time, every option has huge defects, which makes me have to take self-developed engine as my first choice.
I can cite some examples, such as SDL. When I don't use OpenGL, it is even difficult to achieve 20fps per second, and its hiding of details makes it impossible for me to load images from memory. Of course, SDL2 solved some problems many years later, but it is no longer an option for me.
At that time, there was a very popular engine: HGE, based on which many commercial games were developed. However, after understanding it, I found that his support for Chinese was a mess and needed a lot of modifications. At the beginning, I did not have the ability to develop an engine for the second time, and this engine was no longer popular many years later.
I have used more than 20 game engines, each of which is hard to be perfect, or it is perfect, but it cannot be used in FreeBasic, so I have to implement a 2D game engine myself, which is the origin of XGE project.
I tried Direct3D. many years ago, the information about FreeBasic was scarce, and finally the project got out of control. many unexpected program crashes made me give up this option. also, I tried to learn OpenGL, but at that time, the lack of tutorials made this attempt fail. finally, I had to choose the worst solution: FBGFX.
It has many shortcomings, but it has one advantage: I can directly operate the image memory, that is to say, I can solve any functions that are difficult to realize in this very low-level way, which perfectly cures the psychological shadow caused by insufficient functions when I used various game engines before.
FBGFX can't draw Chinese, so I realized Chinese drawing through GDI linkage, GDI is not efficient, so I realized my dot matrix font drawing, and successfully raised the frame rate of full screen text hundreds of times, and I began to have great confidence in FBGFX.
Of course, the game engine not only contains the function of drawing, but drawing is only one of the core components of most engines. To develop a game, there are many things needed, which is why I used so many game engines before and finally all of them were eliminated.
Sound playing is easy to solve, and a large number of third-party libraries can be selected, so I don't have to write one myself, so I chose bass.dll, and HGE game engine also chose this one.
Of course, the network is also an important component. Although socket is not complicated to use, it needs to manage a large number of threads, otherwise it will block the logic threads of the game. Therefore, I have implemented an event-driven network module, which is based on the high concurrency technology of IOCP, and in most cases it is superior to the network functions realized by game developers themselves.
Besides, I also need to pay attention to the technologies that can make game development more comfortable. To sum up, there are three main points: resource management, game scene management and rendering tree.
Facts have proved that these ideas are also in line with the current design trend, but I put forward these concepts seven years ago, when only a few engines started to work in this area, but unfortunately, my technology and energy could not support me to complete these ideas at that time.
Finally, I designed the file package system, the scattered materials in the manager module management games, the scene system similar to Win32 window callback, the concept of rendering objects and the basic rendering tree, but they were not developed in depth.
XGE stopped at version 0.8, and it was not picked up by me until many years later, but the lost time will not come back. What remains unchanged is that I still have a game dream, and because I have done a lot of tests on various routes, this work will not really be wasted, but become experience, so that I will not encounter too many setbacks in my future work.
Many years later, my dream was revived. I continued to develop on the basis of XGE0.8 and released version 1.0. This time, I used many new experiences. For example, through my understanding of DirectUI, XGE has a graphical user interface system, and the engine itself has been optimized.
In version 1.1, I began to focus on optimizing the GUI system, and various common graphical user interface elements were basically completed. As a competency test, I started to develop the xRpgMaker project using this version, which proved to be good and much better than I expected.
I was ill recently, which is a kind of arthritis with high incidence. In China, this disease is called gout. When I get sick, I have to lie in bed like a disabled person and feel pain all the time, which makes my work have to stop. It is very frustrating to waste time. However, I still have a mobile phone and can do a lot of things, and occasionally I will update XGE when the pain is low.
Version 1.2 was born in this environment. In my plan, this version must be internationalized, so all functions should support unicode encoding, but I can't abandon Ansi encoding, which is still easy to use for some developers with less advanced level.
Not surprisingly, version 1.2 will be released in the near future when we move freely.
Recently, I started to prepare for the development of a new version. In XGE version 0.6, there was a file package system, but this function was removed in version 0.8, because it was not as convenient to use as I thought, especially the material management tool and the over-design when I developed xywhPack system, which made this module too complicated.
XywhPack has a longer history than XGE. It has been developed to version 4.15, but my thinking is also changing. Now I need a smaller package system, which only supports file compression. At the same time, I need to develop a very easy-to-use package manager, which should be more suitable for XGE.
Recently, I have conceived many ways to manage game materials. Generally speaking, id management is more efficient, and file path management is more suitable for small game projects. I will choose ID management, which is also recommended by most games. Of course, I need to give up some ease of use, but the development of resource management tools has the greatest impact on ease of use.
Today, I reconstructed XPACK version 5.0 and passed the basic test. It only supports compression algorithm, and is friendly to secondary development and easy to use. At present, it is in line with my expectations for file package system.
Next, I want to develop a package management tool, which should be composed of two parts, one is a package manager similar to compression software, and the other is a script system for creating compressed packages. Perhaps the latter can be omitted. If the former is developed well and reliable enough, I can't be overconfident at present.
For game development, the file package system is often not necessary, and it is often the icing on the cake. Used to protect the game material from theft, the size of the game material has been compressed. In fact, I regretted that I listed it as the milestone goal of version 1.3 before, because there are more important tasks to be done, but now that it has started, I should finish it well.
It is estimated that this work will take me 5 days. If my condition recovers well, maybe I can release version 1.3 years ago.
Version 1.4 should be very important. The milestone of this version is the release of xDataBase data management system.
Why am I so interested in this function?
We know that the essence of games is to present a large amount of data to players in a graphical way, so the core work of game development is to manage a large amount of data, which is why object-oriented programming language is more suitable for developing games.
But the times are progressing, and more and more scripting languages begin to participate in game development. Why is this happening? In addition to the ability of script language to make games hot update, the most critical reason lies in the flexibility of script language when operating data!
For FreeBasic, we can't change the latter, and the compiling language is typed, but we can refer to the scripting language and define a type called value, which can be changed into various types according to the data contained in the value, even table and array.
Of course, it is certainly not as simple to use as scripting language, but it can solve the shortcomings of compiling language before, which is the technical core of xDataBase.
Of course not all of them. xDataBase is equivalent to the transplantation of complete Lua scripting language data operations, aiming at realizing the table data structure of Lua, and this data structure can be saved and loaded.
To achieve this goal, I must first implement several basic data structures, such as ordered list, unordered list and dictionary. Moreover, these data structures can be nested with each other, so as to realize the tree structure, and also realize the inheritance mechanism of the dictionary. When a data cannot be found in the dictionary, it can be searched in the parent dictionary.
It looks exactly the same as Lua's table, so why don't I build a Lua script engine into XGE? I have done similar things in the early version of XGE, but now I realize that technology is always changing. I can't make XGE tightly bound with a scripting language, and I don't need other functions of Lua.
So is there any other way to achieve this goal more simply? Yes. Json, for example, can meet my requirements, except dictionary inheritance, but it has a fatal shortcoming, and its performance is too poor.
XDataBase requires that the organization's data can be accessed 10,000 times per frame at a speed of 60fps under the mainstream hardware conditions before, so as to ensure that developers will not make the game jam because of using this function, which means that the data access speed is 600,000 times per second, and if json is used, it can only achieve 1% of this number.
There are other options, such as redis. I have used this system in many projects. It is excellent, but it is not omnipotent. Although we generally call it cache in application, in fact, the so-called high speed here is relative to SQL database. In fact, its performance is not high, and its variable access is lower than that of scripting language.
Of course, redis can actually meet the performance needs, but 600,000 times per second is my performance red line, not the upper limit. If possible, I hope this number is 100 million times per second or more, which is why after careful consideration, I decided to reinvent the wheel with this function.
I hope it goes well.
Now XGE can be competent for a large and medium-sized 2D online game development, and I am confident to use it to complete games similar to DNF or larger. However, compared with modern popular game development tools, XGE is still imperfect, such as cocos2dx. Of course, I can use these new tools to develop games. Over the years, my C++ skills have made great progress, but FreeBasic has always been my first choice.
There is still a lot of work to be done, such as high-performance automatic path finding, which will be completed in a later version. For example, cross-platform, this is my expectation of XGE2.0.
Obviously FBGFX has fallen behind, and it is only a matter of time to replace it. Therefore, I haven't written the code for directly operating the screen for a long time, such as the high-performance implementation of functions such as image scaling and image rotation. Most games don't need them, and these functions can't be passed down, wasting time.
Now my OpenGL skills are enough to support me in the development of XGE. Therefore, in the future, I will definitely give up FBGFX and use OpenGL3.3 or higher to develop XGE, so as to achieve cross-platform support, especially for Android. Before that, I still need to polish XGE, and developing games is never a simple matter, especially developing game engines. Every time I leave a little margin, developers can have more room to play.
In this process, besides the XGE game engine itself needs to be improved, I will also develop some games to verify that XGE is really competent for game development, and write some game development tools, so that people with weak programming skills can also participate in game development, such as xRpgMaker and small engines like love2d, which use script language to develop games completely.
This is a long-term process. Interested friends can contact me to jointly maintain XGE or xRpgMaker and other projects. After all, it is still a bit difficult for one person to do these things.
Game development specific discussions.
1 post • Page 1 of 1
Who is online
Users browsing this forum: xlucas and 2 guests