Zombie Hero : Revenge of Kiki Mobile, iOS, iPad game

The pursuit of better AI and the feeling of fighting with group of zombies was started in March 6th. Up until now, it has consumed development time for almost 1 month. I should not say consumes as we intended to do it, it's like a major thing that the game needs to focus on even though what have done is a partial improvement.

AI, going deeper

We have been trying to optimize AI calculation part to be in the acceptable level. Right before we added steering AI behavior for the first time, the number of total zombies that can be altogether in the game is very high. We can have more than 100 instances of zombies without a drop of frame-rate, it's maxed out at 60 fps.

After integrated steering-AI behavior into zombie, enabled and tested it, the result is not so pleasant. With ~30 instances of steering-AI enabled zombies, frame-rate started to drop. It went down to ~30 fps when we increase the number of instance to ~60. We had to do something.

Only choice if we can't really improve the situation is to cut out steering AI out and move on.

Debug-line for steering AI

So we push some effort to it and optimize it trying to ease the cost of computation either via using squared-length to avoid using square-root, taking only necessary number of zombies into calculation for certain computation, balancing by turning on/off of behaviors for certain type of zombies, finding the right number of zombies that can exist in the game altogether at the same time that allows us to have 60 fps as always. Thus we have to lower the ideal number of maximum instance of zombie existing in the game from ~100 to ~60. As tested, the latter number usually cover the stage area, it's crowd already and more reasonable.

We proceeded it, and after optimization and play-testing we get the following conclusion (for now).

• Maximum number of zombies in the stage is ~60 for both steering-AI and normal (FSM or Finite State Machine) enabled instance
• Safe maximum number of steering-AI enabled instance is ~30
• For normal AI, if such stage has only that type then the number can go beyond the constraint, it can reach ~100.
• Balancing by turning on/off of behaviors for zombie is vital because certain computation cost for some behaviors is so expensive which can drop the overall performance.

You can read this article for more information which aligned with our experiment. It says if having AI-enabled instance with reasonable computational cost inside (in our case the total number of steering-AI and normal AI) more than ~60, the overall performance starts to drop.

Frequency In Updating

How can we improve such situation is mainly about adjusting the right frequency to update.

We didn't have AI operate at the same frequency at refresh rate of screen or 60 Hz. With the reason that AI is so hungry in computational cost, thus we have to separate AI unit into sub-module as well.

We separated AI unit into 2 sub-modules

1. AI Decision Maker Unit
2. Mover Unit

We let game AI object to think at 10 Hz or just 10 times per sec. It can decide to move to anywhere, to attack, or to sense something before making a reaction. If it decides to move to point A, then it issues a command to move. Thus its Mover Unit will translate it to point A in 60 Hz or normal as screen refresh rate does the job. With this reason, it translates in smooth manner isolating from decision making.

If we think in another way that, AI object doesn't need to really operate in 60 Hz due to it's too fast for such decision to be relevant and too fast for its decision outcome to issue or start something new for its own behavior. We just lessen this to allow more cpu cycle for other jobs.

Non-Penetration Enforcer

Benefit of non-penetration enforcer
35 zombies in the stage

According to steering AI, it has grouping behavior involving separation, alignment, and cohesion. But as we tested, even using those three behaviors cannot help us eliminating too-close or too-stacked-in-layer problem of several zombies. Thus we applied with this reasonable high computational cost method called non-penetration enforcer. This is meant to make sure that zombies would not get too close and stack up together.

Of course, this solution operates in very low frequency. An expected benefit is that it makes the feeling of group of zombies to be more lively, and be able to cover up large area of stage.

Still More Work To Be Done ...

The benefit of steering AI as this point which shows clearly as tested in our game is that

• Approaching and Turning is good

There're still some of behaviors aren't added into the game just yet because of zombies and playable character are not in the same class hierarchy. Thus we need to fix this to pull out all the benefit from steering AI as much as possible.

Weighting for all of behaviors needed to be adjusted properly. As far as we concern, trial and error is a way to go. It can be different from game to game.

Other stuff

We got a Trello gold worth a month. So it's time to change the background!

Zombie Hero style background on Trello board

We also involved in open source project that leads the benefit to our game as well. It's iconOverlaying. Right now in every build, we have a version information.

Until next devlog update guys.
Happy creating!
--
Connect with us via Twitter @haxpor and @secretcharsg