Game AI: How to implement a basic deathmatch shooter

Many thanks for your feedback! I will put your points on a to-do list for further consideration.

If we would ever develop a real product, many things like your suggestions would be important additions. In this particular case however, we wanted to focus on the AI part and verify the features of Yuka with a more complex showcase. If you only develop very simple stuff, certain restrictions of a library won’t be visible. This project provided valuable input to make Yuka more stable.

Besides, it was important for us to demonstrate that you can implement something like this with good performance even for low-end devices. The app is single threaded and we have done no modifications to three.js. One of our most important task for the next months is to further improve the performance by implementing more software optimizations in Yuka.

BTW: The demo just draws the front faces so it’s easier to inspect what’s going on from the spectator view. In FPS mode, it is not an issue at all. Unfortunately, it’s hard for us to optimize the animations of the bots since we have no designer in our team. We are using the assets 1:1 from Mixamo.


Looks great. Studying it now.

I initially tried it on a MacBook using Safari and got a black screen. Console shows this error ReferenceError: Can’t find variable: requestIdleCallback.

Looks great in Chrome.

So Yuka is a Game Engine using THREE.js as the main render component. Is that correct?

Do you generate NavMeshes by hand or do you use a program to generate them?

1 Like

Safari is not supported so far since it does not support window.requestIdleCallback. This could be polyfilled but Safari does also not support Ogg Vorbis. We decided to exclude Safari and invest our time in other stuff. Sometimes I have the feeling Safari becomes the new Internet Explorer :unamused:

Yuka is actually just an AI engine but it provides some game engine related logic so you can easier represent your game entities as renderable components (e.g. meshes). In any event our team is too small to develop a real game engine (we are only two guys right now^^) so we try to focus just on the AI part. It’s also important to note that there is no dependency to three.js. You could also use Yuka with any other 3D engine like Babylon.js.

We generated them in Blender. However, a long-term goal of the project is to implement an own nav-mesh generator. The general approach for doing this is well documented in code and scientific papers. It’s just a matter of time to start with a JavaScript implementation. In this way, you could generating nav meshes on-the-fly if necessary.

If you are interested in the general concepts, read Programming Game AI by Example. We extensively worked with this literature^^. The basic AI architecture of the project is based on the shooter “Raven” which is discussed in detail at the end of the book.


Thanks for advice. I’ve been playing with the Blender Navigation Mesh builder. Afraid it isn’t as tidy as the Unity one. Looking for ways to export the Unity one as a 3D Object. Might be easier to create one by hand.

If you can export it to glTF, you can load it with YUKA.NavMeshLoader since the library expects the data in glTF format. This project might be helpful in this context.

Thanks for the tip.

what is the best practice this days for a mini map?

what i have found is this approach

with two render

I would say that’s pretty bad. You want to render only what is needed, not the entire scene. It’s bad for performance otherwise. It might be a good teaching tool, but you would almost never do it this way in a real game.

Also, typically you want to render a symbolic representation, show enemies as red dots, ammo pick-ups as yellow bullets, and health pick ups as white crosses, for example.

I have a minimap module for meep, it’s pretty complex as a result of applying multiple optimizations but it does what I have described as its core.


Easily the best free and open-source WebGL FPS available, that I have found. Feels very professional. :+1::+1::+1:

I felt that the second weapond did no damage at all. Then I understood that it must be the “shotgun”. It did not look like a shotgun, so I expected something else. Also, I think a short-range weapon may be mostly useless in the particular context. The way to “win”, in my short experience, is to find a rifle before going willingly into a fight. (And probably camp near a health pickup. :stuck_out_tongue: )

Stats would be cool. Kills and deaths.

Enabling controllers (from the programming side) is actually not hard, using the HTML5 Gamepad API.


Nah, I think blood is irrelevant to the “sports” aspect of the game. And definitely to the AI aspect (unless the bots start following blood trails). Maybe I am a bit on the anemic side. :wink: At least I found the amount of enemies perfect. Most encounters are proper duels, which is not necessarily the case with more enemies on the board. And there are moments of hunting (or hiding) and expectation between the encounters. Maybe I would get bored after playing a while, though. Then a slider in the GUI would be great.


We added a shotgun in order to implement a weapon which fires multiple projectiles at once. That’s a bit different how the blaster and assault rifle works.

To be clear, the weapons and items are all from Sketchfab since we could not invest any money for assets. :sweat_smile:

The demo renders the same scene with a top view camera which is essentially the same approach like in this Unreal Engine 4 tutorial (

However, you can also implement a minimap more simple by just mapping the most important objects like characters or items onto a 2D sprite representing the level. In this way, you do not render the scene twice which is definitely more performant.


The texture for such a 2D sprite may be generated from a single orthographic rendering of the map with no characters or powerups, optionally stylized with another shader.


That’s a matter of preference. Either way, particles can be teddy bears for all it matters - what’s important is to highlight the impact, to communicate to the player visually and audibly that a hit on a certain object has occurred.

I do like the idea of non-murdery games, but personally - I’m completely desensitized to blood in games at this point.

I do just that, but it’s an off-line step, I export a 2k rendering of the entire level as seen from above. In that rendering I remove certain objects from the level, as they have no relevance and would only confuse the player. At runtime I load the rendered texture. It seems like common sense mostly. There are some additional things that can/should be done if your level is very large, like tiling that image.


Super idea !!! )) I propose to add tanks and armored vehicles !!!

I once made an online shooter. You can kill yourself in different browser tabs. ))

And in this case, you can connect online players.

That went off-topic pretty fast :smiley:

I suggest we move unrelated stuff into separate topics in the future to keep this… topical :palm_tree:


Perfect! :clap:
I will study the code to learn.

I observed that
When walking and leaning against the wall, he stops.

@Usnul I see no discussions or posts that are unrelated to the topic. :confused: I think we have stayed reasonably on-topic for the forum format.

Congrats! looks very polished and profesional :slight_smile:

one question, how is the cost table calculated? do you use a plugin for blender?

i wonder if there is something like for JS

1 Like

The NavMesh was computed in Blender, the cost table computed once with Yuka (after the NavMesh was imported) and then exported as JSON.

1 Like

This is so Dope!

1 Like

Awesome and inspiring!