Cocos2d-x evolved to some idea of 2.5D, cocos2d-x2.5d

Cocos2d-x evolved to some idea of 2.5D, cocos2d-x2.5d
Zookeeper

First of all, I have to say that Unity3D has already done a great job. It doesn't really make much sense to do these things. What are the advantages of Unity3D? I have written two articles to describe my ideas.
If my next job is U3D, it is estimated that I will not have these ideas or research. But who made me switch back to cocos2d. My new job is probably to write a cocos2d-x of 2.5D games. If I do what I think, it must be U3D, but I have never been a technical developer. In addition, games graphics and algorithms are not very important in many cases. To put it bluntly, everything can be done. In this case, more people may be familiar with the engine or their preferences.
This article does not have any technical things. It is more likely to be spof or hypothetical. First will analyze the disadvantages of U3D (good words have been said a lot), and then will analyze the cocos2d-x to do 2.5D advantage, and finally will analyze the feasibility of 3D.

I. The crux of U3D:
Developing 3D games with U3D is almost the only right choice. For the next generation of games, you can also consider UE3 or UE4, but for mobile games, there are almost no games that rely on the next generation of images. U3D almost represents the peak of the screen. In many cases, the picture of a game is not determined by the engine, but by the art. The excellent engine will also be delayed by the slag art.
U3D provides a convenient cross-platform, flexible and scalable editor, a complete particle system, rich resources and extensions, and a simple and systematic framework system. If there are many benefits, we will not list them one by one.
Here we will analyze the shortcomings. Some of them are irrelevant, some can be bypassed, and some are really disgusting. In this interview with NetEase, the main process also said that they are more accustomed to using self-developed 3D engines than Unity. They also have a sound editor and workflow, but they can avoid some problems with Unity.
Of course, only a large company such as Netease And a technology-oriented company will have such strength, and the small team will be able to use Unity securely. After all, the screen effect, whether the game makes money, and the development progress are all related to the team level, and have little to do with the engine. It doesn't mean that the development is slow, the screen is scum, or the optimization is poor, but the engine is poor, but its own level.
U3D is wonderful, but some details or procedures are really disgusting. In either case, you may consider dropping U3D. One is the R & D engine of a large company. It doesn't make much sense to start R & D again, but old game companies have accumulated a lot of technology, R & D engines are really not difficult, especially for mobile games. The second is that my requirements are very simple. For example, if I only want to render the 3D model and play the animation, it is OK. In this case, it is OK to not use U3D.
I personally feel that U3D is not very beautiful in the online game development process. It is more of a service for small teams like independent games. Although the successful MMO mobile games are quite a lot, the NIU x team bypasses the pitfall or fills in the pitfall, which does not indicate that the pitfall does not exist.
1. Resource Management. U3D resources are automatically packaged and maintained by the engine in a unified manner. You do not need (or are difficult) to control a resource in the form of files. This often makes me feel stuck. Although it is acceptable for the engine to manage resources in a unified manner considering the pre-made and resource loading and maintenance in scenarios, I did not think of a simpler and more straightforward way. But it is always uncomfortable. The details of resources (such as textures and models) are hidden behind the U3D resource system. How can we ensure reasonable resource release, how to Ensure the resource dependency of AssetBundle is worth writing an article separately. This is the dark details.
2. AssetBundle. Because Unity Resources have a set of internal data connections (such as script binding and material attributes), Unity provides a file system independent of the package, this is also the basis for automatic update policies for web games and mobile games. On the one hand, it can complete the automatic update function, on the other hand, it can also achieve data maintenance work developed by multiple people. However, it is not easy to ensure the optimal resource by packing the package correctly. In addition, after resources are packaged into AssetBundle, there will be certain limitations in the editor development. For example, the animation state machine cannot be viewed by Animator.
3. multi-person resource management. The only thing I can think of now is to make art accustomed to using Unity, and then use AssetBundle for resource maintenance in a unified manner. The program only needs to care about Bundle. However, this requires only resources. If the program still needs to process resources, such as binding scripts and adding collision detection, additional workflow modifications are required. If everyone shares a svn (or git), the project folder may have n gb (My ARPG project folder has more than 10 Gb ). In addition, it is disgusting to use meta files to store information. Some information is useful, such as animation information and texture segmentation information, but many of them are useless, however, a large number of online games may have many fragmented files, and the size of the meta files is terrible. In addition, the bound script may be lost due to misoperations during resource modification. This can only be said that the simple situation is very simple, and the disgusting situation is very disgusting.
4. script. Honestly, I have not found a better solution. However, binding a script to an object is not a perfect method. Because the scripts and resources have been bound together, it means that the code and resources must be managed together, and it is no longer feasible to maintain the code and resources in the traditional way. In addition, the project's correctness also depends on the resource data configuration, or a large part of the programmer's work needs to configure resource data. Maintaining the entire project on svn or git is very painful. I originally wanted to open source the project that was stopped before, but it is impossible to upload 2 GB of resources to github, and it makes no sense to upload only the code. For other projects, you only need to manage the Code. For resources, maintain a final resource configuration in the Network Disk.
5. Many functions are available but not easy to use. This is mainly from the convenience of MMO development. For example, in MecAnim, animation redirection is very good, and the state machine editing method is also convenient, especially for animation fusion editing. However, developing MMO is not a good choice. At least many companies still use old animation systems. The existing framework (or development experience) is based on the old animation system and fully satisfies all functions (for the company, redirection is not the core consideration ), there is no need to taste it (although it has been around for a year or two ). I have also written an article about how to make it easier to use MecAnim. However, even so, it cannot be said that the solution is perfect, but it can be changed from impossible to developable. In my opinion, the biggest pitfall of MecAnim is that it is not compatible with the old animation system. The biggest change in the use of the new and old animation systems is the method of editing the state machine, however, the connection and editing of status transfer parameters are very painful, and the direct playback of animation interfaces may affect some functions (or do not know whether there is any negative effect, if it is not open source, it is not easy to know about it ). The perfect situation is that the editor, animation redirection, and Action fusion editing functions are relatively independent, so that developers can customize the animation system based on their preferences.
6. 2D functions are convenient but tasteless. This is an extension of the previous one. Unity4.3 has released the 2D feature and is further improved in 4.5. However, if I do not want to modify it, I will use it to develop a 2D mobile game, such as dazhangmen and the legend of the turret, it is still a very painful thing. To some extent, cocos2dx is more convenient. It doesn't mean you must use the cocos code format or structure. I think the editor-based development process of Unity is quite good. However, some basic functions are missing, or are not provided directly and conveniently, making secondary development necessary. I want to write (improve) a 2D plug-in, which has already completed 70%, but it is estimated that this will be extended because it will be switched back to cocos later. Unity's Native only provides convenient Image Display and animation creation functions, but the image packaging function is very weak (image rotation is not supported, Trim is not supported, and the operation method is awkward, compared with TexturePacker, animations cannot be edited or precisely controlled (such as a frame offset control or time control), and there is no existing multi-resolution solution (Camera Resolution control ). These are all necessary functions for game development.

2. What kind of 3D engine do we need:
For mobile game development, the next generation will never need to be considered. Even those cool effects of Unity are also "disabled" on mobile games, such as real-time lighting. On the one hand, we are pursuing the Performance of High models, and on the other hand, we need to pursue the efficiency of low-profile data, so we cannot achieve the so-called "high quality ". However, a game is really cool and cool. Many times it doesn't look at whether it is a "video card crisis", but the overall style and feeling of art. For example, I feel that the light effects of full screens and the numbers of full screens are very cool games. Whether the hair is meticulous or whether the mouth shape matches is out of my consideration.
The 3D engine I need is very simple in functionality. It is enough to efficiently render 3D models, skeleton animations, and particle light effects. What is important is not how rich the functions are, but whether the basic functions are convenient and extreme. Because it is a self-developed engine, we can spend more energy on efficiency optimization. For example, I have always wanted to implement a-person-war RTS game. The efficiency I tested in Unity cannot meet my needs, unless the model pressure is very gloomy. If you develop it yourself, you can try to optimize and solve it.
I reiterate that the most advanced graphics technology is not my consideration, and practicality is the top priority.

Iii. Open Source engines for reference:
There are many open-source 3D engines that can be used for learning and reference. standing on the shoulders of giants will take less detours. Many companies have spent tens of millions of years developing 3D engines, and some have not yet completed (unsuccessful game masterpiece). In my opinion, it is just a detour. On the one hand, these developers despise open-source engines such as OGRE and think that they are technically scum, and on the other hand they have not made convincing things. Engine development is not that easy, because it is time-consuming and labor-consuming to make a convincing engine that requires comprehensive considerations such as editors, functions, effects, efficiency, and development processes. However, engine development is not that difficult at the same time. As long as we are willing to discard all the things we don't care about, we can quickly develop engines that convince ourselves.
1, genesis-3d, Sohu Changyou engaged in a set of Open Source engine, very similar to Unity. It belongs to the kind of things that Changyou does not need and then recommends to others. It is of little reference value because it is huge and complicated. And I personally think it is a detour. It looks like Unity, but it has no other highlights than Unity. Instead, it lacks various functions and there is no Unity development community. How can we compete with Unity?
2. godot, another thing that is very similar to Unity. It is also the engine of the editor.
3. Torque3D and Torque2D are open-source.
4. GamePlay, Panda3D, and PixelLight are not very famous, but their functions are relatively complete. Do not go through the editor path. Panda3D has a large amount of code.
5. Ogre, KlayGE, and WildMagic are well-known open-source engines. You can look at structural design and graphics technology. Other things, such as the ghost and fire, have no major highlights. They are similar to OGRE. Just pick one and let it go.

4. The feasibility of 3D status and evolution of cocos2d-x:
The cocos2d-x-3.2 version has been added with support for 3D models and skeleton animations, and the latest github has more refactoring and improvements such as support for submesh. Of course, this is far from enough for a 3D engine, but it is often more than enough for us to make a 2.5D game.
As to why we should consider cocos2d-x 3D, instead of using the engine mentioned above, the main consideration is the learning cost and development cost. There are many people learning cocos and many people playing games using cocos. Therefore, the corresponding developers are more attractive, while the cross-platform pitfalls are basically completed. The most important thing is that, looking at the habits of the main process, the habits of the main process can guide the technical direction. In other words, the engine cannot determine the development efficiency. The correct use of the engine is.
At this stage, the most important deficiency is a complete Particle system, such as the Particle Universe of OGRE. The Particle system itself and the editor are indispensable. For others, let's see if the weapons can be bound or changed. If so, no additional development workload is required.
As long as the development process is correct and the editor is not that important, you only need to Support WYSIWYG editing in scenarios, UIS, and other content. Getting familiar with the process is much more efficient than getting familiar with the editor.

5. Even if the direction is incorrect, what will happen if time is wasted:
It seems that there is no loss. On the one hand, I once again prove that my appreciation for Unity is correct, and on the other hand, I can learn the underlying engine technology. This is helpful for subsequent development. When there is no problem with the underlying technology, developing a game is about writing logic. It is okay to implement the logic clearly. However, when a new problem occurs, understanding the underlying layer will help solve the problem.

Some special ways of writing cocos2d-x do not understand

Hello:
Let me help you solve this problem =!
You should know the game engine's predecessor when you use COCOS2D-X?
Nice is cocos2d-iphone
In fact, the-X engine is transplanted to the Iphone version.
Everyone knows that IOS is developed using object-C language.
O-c has a feature that sets the global variables of the class as attributes and then automatically generates methods similar to get and set.
This is actually a macro definition, which is about the same as the o-c Special.
It is estimated that the cocos2d-x is improved to use exactly the same as the original version ~

In fact, he did these things.
Protected: int nTest;
Public: virtual nTest getTest (void) const {return nTest ;}
Public: virtual void setTest (int var) {nTest = var ;}

Next, you cannot understand the writing method.
In fact, this is a macro-defined syntax and should be considered as a C ++ knowledge (well, I am not very familiar with it. If not, I should not say this sentence)

I think you should have used a lot of macro definition.

Let me talk about this one from the landlord.

Similar syntaxes and
The format is as follows:
# Define Conn (x, y) x # y
# Define ToChar (x) # @ x
# Define ToString (x) # x

Are you talking about 1st types?
X ## what does y mean? X connects to y, for example:
Int n = Conn (123,456); the result is n = 123456;
Char * str = Conn ("asdf", "adf") returns str = "asdfadf ";

Almost understandable?

Hey

Some basic questions about cocos2d-x

Your question is too vague. The control genie can refer to the CCSprite interface to call CCDirector: replaceWithScene in conversion scenarios. Let's go to tests...