COCOS micro game development complete record -> end there are surprises

background

Because I personally like games, I have always wanted to make a small game, but I have been putting it off and have no time to do it. Now I finally make a small game on wechat in my spare time on the weekend.

This is the first time to write a technical article. The length may be long, but I feel that I am full of work. If there is anything bad, I hope friends can put forward more suggestions, including the whole process of game core numerical design.

If you’re looking to get into game development, or just don’t know how to get started, I hope this article will help you out

No more nonsense, see the effect of the first picture, if you want to experience first, can directly drag to the bottom

directory

  • Gameplay Introduction
  • Numerical design (brick health, player attack, attack speed, etc.)
  • The development process
  • Mining pit record
  • Problems related to wechat deployment
  • Wechat advertising access

Note: this article does not cover much of the specific code and the entire code. It will outline the ideas of a novice developing a complete game in Cocos to avoid pitfalls, but there will be some core values or key code for reference.

1 introduction to the basic gameplay of the game

The original design was a lightweight shooting game that automatically fired bullets, changed the movement of the character by finger touch, ate different buffs to stack corresponding abilities, and scored higher points by hitting blocks.

Here are some of the features currently supported

  • Automatic fire, double, triple, four
  • The plane moved and collided with the brick
  • The bullet impact
  • Full leaderboard implementation
  • Complete game flow, start, game, game over
  • Brick health numerical algorithm
  • Buff stack, attack, attack speed, barrel count, invincible Buff

2. Numerical Design

If conditions permit, numerical design is actually a special work of numerical planning, but… I did, too. In order to figure out how much the player should attack at different times, I made an Excel to calculate the value of the player’s attack and used it as a setting for the actual development of monster life. Here’s what my numerical design looks like (Excel actually calculated about 100 lines, so the graph is too long, so I just took the first part).

I think numerical design is the core of the whole game, the core of game balance and playability. I spent some time thinking about this part, the whole game design is only attack and life, no armor, so I used a relatively simple subtraction formula for calculation

Formula 1: Attack = cost

Formula 2: Life – cost = result

Values form field Tab description

  • Monster wave number: Bricks fall in waves (a wave of bricks is a row)
  • Strike time: Average kill time for a monster
  • Growth rate: Strike time growth rate (controlling the strike time factor)
  • Monster Health: Block health
  • Health growth: A growth factor that controls a monster’s health
  • Player attack: Finally figure out what the number of monster player attacks should be for different wave numbers

Numerical design process

I will not introduce the operation of Excel, you big guys baidu by themselves. There should be a lot of tutorials

1: My idea is that initially the player can kill a block per second (since the initial attack speed is 0.5 seconds and the bullet moves to the monster for about 0.5 seconds), so there is a second column and a first row that takes 1s to hit

Get the first initial value: strike time 1s

2: Then for each monster wave, how much should the player’s strike time increase? Because this is a monster falling infinitely, the strike time must not be too long, or GG will not die, so I set a growth rate of 0.01, through numerical verification is more appropriate, when the 30th wave is 1.3s.

Get the second initial value and the calculation formula: Strike time growth rate of 0.01, the calculation formula of strike time is: =B2+B2*C2 [note: this value needs several attempts, according to your own needs to get the final result]

3: Then there is how much health the monster should have. It should not be designed too much at the beginning. If it is designed too much and kills within 1 second, the attack must be very high.

Get the third initial value: monster initial health is 2

4: The same HP must have a growth factor, so there is a HP growth rate, here I initially from 1 multiplier to 0.2, found that 0.55 is suitable for growth is not too low or too high, which is a relatively satisfied state

Get the fourth initial value and the actual HP calculation formula: HP growth rate is 0.55, HP growth formula is: =A3A3E2+D2*E2, HP growth is related to growth, but also proportional to the wave number of the brick, the higher the wave number, the higher the monster HP.

Monster wave number squared * health growth + last wave health * health growth, [initially I only thought of health * growth, found it was low, above 50 waves is still too low, so I added a monster wave number condition]

5: The last player attack is relatively easy, brick health/strike time = player attack

Figure out the player’s attack value: the initial value is 2 (because the monster’s initial hit point is 2, because a single hit point kills a child) the player’s actual attack = brick hit points/strike time

At this point, the core value of the whole game is designed, but there is a bit missing, because this is a similar shooting game, more than one bullet, so later need to add the bullet speed, the number of barrels together to calculate.

Below is the complete code for the brick health calculation

The final value of the HP variable in the first line was multiplied by 0.65, an optimization was made because the randomness of the Buff meant that the attack might not be exactly the same as the value table design.

When the barrel was full and the attack rate was full (2 frames (≈0.03s), it was found that the attack rate was too high, so a number of numerical fixes were added to the HP when the player reached different states.

Attack speed Buff is reduced by 3 frames per attack, up to a maximum of 2 frames.

Attack Buff increases damage by 3 points per attack, unlimited, more likely than attack speed

3 Development Process

With the core values of the game settled, development is actually relatively easy, just check the API and think about how the game is done.

Here’s a list of the steps I took to make the entire game

1: Figure out the specific gameplay of the entire game, how to operate it, and what the core gameplay is if you win and die. Complete the entire game step by step.

2: The first step, complete the player’s operation, drag and move

3: The second step, complete the functions of the player such as firing, bullet management (speed, bullet state, barrel number, etc.).

4: The third step: start making bricks, set the position of the bricks, according to the fixed speed down.

5: Step 4: Deal with the collision between bullets and bricks [Incidentally, at first I used the physics engine provided by Cocos for collision detection and other operations, but later I found that when there were too many bullets, there was a bit of a jam, so I looked it up and found the ordinary 2D collision detection].

Step 5: Make various interfaces, such as start interface, end interface, etc.

Oh right, the game involves data storage, I am using Node to write the back-end, because as a front-end development, will only Node ha ha ha

4 Pit mining records

  • Pit 1: UI students gave me a version of the new UI, I change after found in IOS (WeChat small game) unable to load the figure (because this figure, I didn’t notice), all the android platform Little game Unable to open small program, all sorts of baidu, and WeChat open community can access to relevant information, accidentally I saw someone said, The image size of the mini game can not exceed 2048, so I checked mine and found out which one was larger than 2048, so I tried it, and I was so… *&%%￥&, make my problem for a few days, unexpectedly is this…

  • Pit 2: Sprite map. For Cocos, it is recommended not to merge the Sprite map by yourself. It is troublesome and not easy to expand. You can use the official automatic merge wizard map, according to our reference to automatically generate wizard map, especially easy to use

  • Pit 3: When I introduced umENG statistics, I found all kinds of problems in the import, and there was no wechat authorization. Then I didn’t know whether it was my operation or the SDK code, so I formatted the min.js file of Umeng and changed it by myself.

Well, I haven’t thought of anything else. If I have, I’m making up for it.

5 questions about wechat deployment

1: wechat deployment is actually very simple, wechat games now do not need to soft, but it seems that douyin next door must be soft

2: At present, when the trial is basically a pass, as long as there is no violation of laws and regulations, basically no problem.

3: It is worth mentioning that the micro channel small program to do version compatibility has been a very headache, this has to think well

Cocos provides the global parameter CC_DEBUG to true to indicate the development environment

Applets provide the __wxconfig. envVersion attribute to distinguish between the states of the applets develop = development, trial = trial, and release = official

6 wechat advertising access

1: This is also very simple, but the premise is to meet 1000 independent UV, this is more troublesome, but nothing is not our strong country (great, glorious, correct Long live the Communist Party of China! Long live the great, glorious and heroic Chinese people!

2: Then there is a small problem, how to correctly position wechat Banner ads at the bottom, because wechat is calculated according to its own position and pixel, and only supports the top attribute, so it is very confusing, that is to say, it is not compatible with the size of Cocos, here I tell you my solution.

// Locate the Left calculation methodLeft = (screen width - set Banner width) /2;

// Calculate the Top, where 20 is the self-set distance from the bottom, the height of the Banner needs to be dynamically obtained through the onResize eventTop = Screen height - Banner height -20;
Copy the code

Here is the detailed code

const getWxSystemInfo = () = > {
    return new Promise(resolve= > {
        wxFn().getSystemInfo({
            success: res= >{ resolve(res); }})})}/** * the following contents are in a function body, which I copied separately **/
const wxInfo: any = await getWxSystemInfo();
        
/ / home page banner
this.homeBannerAd = wxFn().createBannerAd({
    adUnitId: 'adUnitId'.adIntervals: 30.style: {
        left: 20.// set it arbitrarily during initialization
        top: 0.width: wxInfo.screenWidth - 40}});this.homeBannerAd? .onResize((res) = > {
    this.homeBannerAd.style.top = wxInfo.screenHeight - res.height - 20;
});
Copy the code

Finally,, finished,

pleasantly surprised

Now the first phase of the game ranking to send cash red envelope activities, we can go to experience play, the way to make money 😄 😄 😄

The following is the experience address, welcome to experience

If you have any questions, or are not clear, please leave a comment and discuss!!

Finally, thanks to UI for the resource material

His tiger lesson website: huke88.com/person/opus…

His station is cool: zhujiu.zcool.com.cn/