Hand-Travel Client thinking framework

Hand Tour new company new Project client I don't quite agree with the framework. Although I finally conceded, when he actually asked the boss, make this childish behavior and remorse.

However, just recently I wrote some code views, and I was more determined by my thoughts and thoughts. and ideas may not be suitable for other people, so I do not say that other people's ideas or habits are not correct or bad, just to be able to use clear ideas to write clear code.

One, 3D, unity means a longer project cycle?

Very many people will have this view. Because unity has a lot more features than Cocos2d-x. Pits many others, so the development cycle of the project will be extended. There are also some technology to the people will feel that unity optimization is not in place, so performance is not a big MMO. Even in performance than Ogre. I can't describe these people in a frog. As these people are the project leader, technical director, Senior Master. But in my opinion, the progress of project development is related to the team level, and it has nothing to do with the engine.

Today's many online successful 3D MMO Hand tours also demonstrate unity's performance.

There is no such thing as "can't do", or even "too many pits, very difficult to do". Given that it really is "pit", there won't be so many companies choosing unity and successfully developing millions of revenue-level games.

Half a month ago I also think 2.5D game casually write, because the earliest in the net Dragon use C3 engine is very reassuring, very handy. And I have seen C3 the source code is not many. Hundreds of K only. Just look at the progress of Cocos2d-x now. As well as our own transplant of 3D light effects, it will be at least a year before Cocos2d-x becomes a qualifying 2.5D game engine. Of course, the team of technical cows can do their own optimization. But I can't figure out how much it makes sense, and it's more reassuring and convenient to use unity. For example, you don't have to worry about efficiency, engine stability, model import and rendering, model animations, post effects, and so on, and these are all disgusting when I recently used cocos2d-x. Just to say, we think it's very easy. We also feel that our needs are very easy, but it is not good enough.

Second, is the MVC framework really suitable for hand-travel client?

It should be very many people will feel yes, this is a classic decoupled framework. But I feel. The framework is not the purpose, whether the decoupling is true or not, and whether to follow a design pattern is more of a goal. Build client capabilities at a high speed and make them clear and flexible. It is easy to change and read, and this is the goal. Only the code is clear, only easy to understand, you can understand the premise of all the reconstruction and optimization, but also to change the premise of the bug.

Let's say we want to follow MVC, go it, and struggle with what's show logic and what's business logic.

Our client framework today is probably the MVP structure, and P (what we call a controller) carries most of the logic and functionality. The whole client is made up of a controller.

We have to follow this structure, so clearly a class, a function call to be able to get things done. To cut into several different objects. Because these objects have a parent-child, brother, business, show this relationship, so can not be put together, between the objects through one after another event notification to complete the business flow. I'm not very optimistic about this code. Only can not see the net.

I am a little unclear, obviously similar to "my name Mt" such a simple card game has been developed for a year time. and the development to the back of their own feeling thick, what is the existence of this MVC value? Is it suitable for skin-changing? Or is it suitable for expansion? Or is it appropriate to delete the function? Or is it suitable for new students? Or is it a good team work?

In my opinion. MVC is originally for software development, Web page development to get out of a set of things, the biggest function is to separate the display and business logic, so whether it is to change the content of the page or change the background logic can not affect each other. And in the game? The interface function is very much, though. But the most worrying thing, most of the situation is no matter what the difficulty. And what can MVC do for us in the non-UI part?

I am a useful doctrine, and the doctrine of usefulness does not mean that code is written casually. It's good to finish the plan. The doctrine of usefulness is through clear rules and beautiful encapsulation. Let the code become clear and concise, so that client development becomes rule-based.

About a year ago. I have written an article and I finally have a description of my understanding of the customer's framework. I admire myself for having such a clear idea >_<.

"Here also by the way my view of the game client module dependencies, to say the truth, the game client is really a small project."

So as for this little project. There is no need to pay too much attention to coupling, modularity and the like.

Anything that makes my code neat and easy for me to write code is a good feature, even if it's a constraint. But suppose for the sake of modularity, let me write code when write a impl. Write another provider, that will make people disgusting, it turns out that some modularity is purely unfounded.

Some of the ideas of reusability are purely unrequited, for example--you see how well my code is modularized, and the logic module's line of code can be used for other projects without changing it.

I would like to say. Assuming your game is making money, we're going to do a similar project again. So I'm going to have to move your UI module over there.

Assuming we're doing a new project, I'm going to find something I want to reuse from that lump of code. It's better to make the code simple, straightforward, and I'm easier to understand.

As a game client, there are three main modules that are sufficient. Logic modules, rendering modules, UI modules, all of which work with the engine are stuck in the render module, and the rendering module is the re-encapsulation of the engine. Even if a small amount of stuff spreads to the UI module, it should just stay inside the UI control.

The logic module is only responsible and responsible for the complete logic, which is why the logical layer cannot introduce UI elements.

The logical layer of things is one of the management classes.  Responsible for the various business logic of the game. The rendering layer is a re-encapsulation of the engine, such as encapsulating a character rendering class, responsible for rendering the character (there should also be a character class in the logic layer to handle business logic, such as name, gang, this is a combination of relationships).

The UI layer is a single interface. The render layer will not move for several months after it is packaged. Logical layer and UI layer one by one accordingly, a business logic is the logical layer joins a management class and the UI layer joins several dialog boxes.

They are relatively independent of each other. Interaction is dispatched by the event hubs mentioned above.

Such an event center, looking at is very easy things. But it is the entire client infrastructure, a good architecture allows people to complete the function at a higher speed (and when the architecture is set up, 90% of the time is to write business logic and Interface Logic), and the bad architecture may let us write code slow, more bugs. ”

The core of everything is encapsulation, the purpose of which is to realize the logic and function of the client. Based on the framework mentioned above, I can't imagine any side effects or bad places.

Not to mention the number of hand tours is not very big, suppose someone can put a hand tour project to write hundreds of thousands of millions of code. It's very hard for me to agree with that.

Third, based on combination programming, object-oriented programming, functional programming?

We learned about object-oriented programming from textbooks, and we have this classic later. said that the combination should be substituted for inheritance, and then there are big God out of the functional programming how good.

How should we design the object of the client? First functional programming I'm not going to learn. As I read a few articles have not grasped the spirit of it, but can be sure that functional programming is definitely not process-oriented programming. Don't let the object just write the function.

Here is to mention a habit problem, use their own custom to do code encapsulation, and do not use the concept of smattering to parody.

Component-type structure must have its advanced and flexible place, unity in the components of the idea whether it is to learn or to use it is very convenient, probably I have seen the most beautiful realization, this beautiful not only in the body today's components themselves, but also the communication between components, components and gameobject relationship and so on.

Is it not a succession that is utterly useless? Of course not.

Even in unity there are still a lot of places that need to be inherited to implement. A component can describe the ability to describe an object, while inheritance can describe what an object is and what its function is. Reasonable inheritance can make the code clear and streamlined. And feel that the code does not need to inherit, just use the combination to describe the narrative is tall on the idea, but will produce messy code.

Iv. How to create a hand tour client from scratch

Originally I lacked some self-confidence to myself, feel oneself do a RPG, ARPG what lack experience and accumulate, doubt oneself can not build the whole project at high speed. But sometimes it is not necessarily their own success can give themselves up self-confidence, other people's failure can give themselves up self-confidence.

1, technology selection.

This is very important.

The first step is wrong. The back is on the wrong road, drifting away.

Suppose you want to do 2D games then use cocos2d-x, assuming you want to do 3D then use unity. Originally I do not want to mention such a knife-cut point of view, so it seems very no level, because the real master is to take anything can do very good.

But very many people just can't choose the client engine correctly, the result is wasting time, even the project fails.

Now there are more successful 2D games with unity, so let's say you're familiar with unity. It is good to use unity, so that the team can better do the technical accumulation. And suppose there's no experience. Then Cocos2d-x+lua is the best choice. Easy to recruit because it is simple and easy to get started. But to note that the cocos2d-x is determined to concentrate on doing 2D, assuming that the art and planning to use 3D elements to show a cool game, unity is the choice.

2, understand the selection of the engine development process and development ideas.

For example, how to deal with character movement, skill play, UI in Cocos2d-x. How Unity handles character attack decisions, physical effects, component communication, and more. It took me a long time to think about these issues when I first started contacting unity, and even though I wasted some time, I came up with a clear idea of what was going on. Ability to write code for unity style. Assume that the underlying functionality in the game can be implemented. Then a demo will be formed.

3, the game the most core play.

In most cases it is the combat system. There may be some relatively difficult things to be involved. For example, the skill system design in ARPG, the method of turning abacus in the tri-elimination game, the battle flow design in the card game and so on. It's reasonable to spend one months or more. Basically this thing is finished, the game in the beginning of the end of the part, the rest is pure logic function. While the pure logic function is time-consuming, it is not difficult and can be accelerated by adding people to the process.

4, data structure design.

This is mainly about numerical planning related things. For example, what are the attributes of a character and what are they equipped with? What structure is used to store the character information and where the equipment information is stored. The main task of the program is to figure out how to configure these properties, how to load them, and how to synchronize them.

5, network communication and UI module design. Although these two are totally different things, the solution is the same. Choose a technical solution (for example, Protobuf,cocostudio). A reasonable encapsulation makes writing these functions independent and simple. This is the back-end development of the content, the client more than half code is to handle the network message and UI logic.

6, the realization of the detailed function module. Based on the client architecture mentioned above, "adding a function is adding a management class." And some columns of messages and interfaces, "I think this should be done for a fresh student."

Ex-2: For the 2nd, I'll say a little more. As far as ARPG's skill system is concerned. Before I felt the need to achieve a very beautiful system of skills must be flexible, must be expandable. It's best to plan what new effects you can assemble yourself, without the need for a program to change one line of code. This is theoretically possible, but in theory, I've seen some of the code on Unity's online game, their skill system is not flexible, some are even dead, and a skill is a class. But it's better that they become a great arpg. Implementing functionality is of paramount importance. As long as the big frame has, the detail function on the design is not necessarily the pursuit of perfection.

Five, embrace the change of planning?

First of all, I do not think that the game function constantly overturned re-doing is a reliable behavior. If it is the boss, then I can accept it. But if it's a plan, then it's time to criticize it. I used to joke that I was a professional planner. Hobby is writing code. I think the plan should be to do what the game, the game has what gimmick, the game screen and play the goal is what, the game finally looks like what has a sober understanding. Assuming that even the game is not imagined, how to ensure that the design of the game will attract people. I think that the successful games at the beginning of the design still determine the core of the game, they will certainly have this understanding: this game should be this way. This game absolutely will fire, so cool game absolutely fun.

Second, even if we need to deal with repetitive and unpredictable planning, the framework I put forward is just as easy to change.

There is not necessarily a need for strict functional block segmentation, and when we take over the code that others maintain, many other times is to understand the planning function. It is found that it is easier to maintain the whole project by using strict module partitioning and inter-module event communication to complete the solution coupling. It seems to me to be unrealistic. Unless you really personally maintain personal, own the mess oneself most familiar with, otherwise really want to look up bug. It might be more painful.

Finally, when we need to change the skin, the same can be done easily.

We are very flexible and independent and clear. At least the rendering layer encapsulation is absolutely capable of complex. The logic is that the use of the same layer is very broad, and then assume that some features are not available in the language, and then the corresponding UI layer will not be required.



Hand-Travel Client thinking framework