I apologize if this derails you a bit (and leads to any confusion), but my suggestion is don’t worry about formal UML (or any other modelling tools for that matter). Put something together that makes sense to you, allows you to catch architecture issues early and allows you to convey your ideas to others. Of course, it’s a good thing to follow some semblance of a known modelling tool, but it’s not the end of the world if your entire architecture is drawn in crayon on a napkin (okay, so that’s a bit of an exaggeration ;)).

One of the major points of using these tools is to fail fast and fail cheap (it’s a lot better to catch logic/architecture issues up front and early rather than when you’re knee deep in code that takes a tremendous amount of time to refactor). If you’re spending more time trying to figure out how you should be using these tools rather than flushing out your logic, something sounds a little suspicious to me 😉

In over ten years professional experience with many people much smarter than myself, I have yet to encounter anyone who can remember ever syntactic element of UML when whiteboarding (or if they do, who care enough to use it).

Just go ‘n get stuff done. Don’t worry so much about the formal details.

I agree with @Demian Brecht.

It is really important to not get caught up in semantics.

What is really important is that you flesh out any design snags that
you have yet to encounter.

In other words:

The value of UML is not just to write some precise model so that the world can understand your design, but it is a tool, so that… you can understand your design, then share with your colleagues.

So, just keep drawing. Ask the questions: “Does this accurately represent the Current State, or Future State?”, “Are we leaving anything out?”, “Does this pass the practicality test?”.

With practice, it is possible to envision diagrams before fully understanding why they represent higher-orders of complexity. Comparing any diagram to reality can then reveal unexpected oversights or optimizations (hidden-fruit).

In all cases: it really doesn’t matter if the arrow has a crows-foot pointing in the right direction or not. What matters is that you are fleshing out the design through a visual process, so as that aspects of the design challenge are not hidden from your awareness at development time (time-bomb).

To directly answer your question on Activity Diagram:
What you need to do is to find a way to make your activity diagram meaningful.
If you cannot see a way to fit the enemies into the UML prototype that you are looking at, consider how it may be adjusted so that they can fit in. Do not feel limited by tradition. The goal is to visualize the design of enemies on paper.

If it is meaningful, it is valuable – and can be re-used later. If it
is meaningless, it is not valuable – ever.

So just put what you know down, and start to add on to it. When you realize that something is left out, figure out how to incorporate it visually into your diagram. This will lead you into new realms of awareness of your design that you did not originally conceive. Finding this awareness is the point of improving your designs. Only then do you finalize the diagram into a standard way that others can understand. Only then, is the Unified aspect of modeling applied. In the interim, it is up to you to discover what is unknown through iterative diagramming.

Hope that helps.

Just from the couple examples you gave (in particular “generate path”), I think you are trying to define your use cases at too low of a level. The enemy’s actions in a use case might be attack, chase, search, stand but “generate path” is too low of a level. Also, it is describing “how” and not “what” which is also a bad idea IMO. If you do use-cases at that low of a level you’ll never get done.

Back to the original question….how to show the enemies? You would normally identify the event that triggers the use-cases. It could be a timer, it could be the player comes within x-distance away. It is possible to declare the system or the timer or any other trigger as an actor if it makes sense. It’s even valid to declare the enemy as an actor. ie. The enemy detects the player and does…. You don’t necessarily have to specify how the enemy detects the player (just that the event the occurs). You worry about the how in the implementation.