The most needed features:
NPC models, Wartoks, Trolls, Dragons,Combat system,AI, walkpath, enemy detection,dragon flying animation, bones, Arokh model, dragon weapons, fireballs, Rynn model, animation,swimming and above all health system
drakconianproject's dragon is probably
https://www.infinitypbr.com/?pack=dragon, but I don't know if it would fit into the world of Drakan, artistically speaking.
Anyway, I've now extracted all assets from all files. This includes:
- Sounds as WAVs
- Models as text and COLLADAs, for import into Blender
- Animations as text
- Textures as PNGs
- Class instances/Objects (these importantly define the Rynn and Arohk characters)
- dragon.rfl class dump
- Action sequences (one of them defines Arohk's awakening)
- Level layers as text (includes heighmap, triangle division, triangle walkability, texture coords, lighting config)
- Level entities as text
This means I've now got Arohk with the original bones and textures:
As well as Rynn and all the other NPCs.
For combat/AI/navigation, you probably won't need AAA-level sophistication. You can peek into Drakan's way of doing things by looking at NPC settings:
Combat detection would probably come down to raycasting through the physics engine. If you want to be fancy, raycast to each body part. If you really don't want things to get in the way of fire, use a sphere cast (fat rays). This should be O(n) overall because NPCs typically don't fight eachother. If you do allow free-for-all battles, you'll hit O(n^2) time complexity, which is when it would be better to have each NPC maintain a small list of nearby enemies, to limit that quadratic complexity, which is what UT3 does. This is more likely to happen in large multiplayer battles filled with bots.
Note that you could raycast against only static geometry to speed things up, and then do a final check for friendly fire. To speed things up even more, use a room-portal system to see which rooms an NPC can see. Another method you could use is to enumerate all triangles on a navmesh that the NPC can see and then see who else is standing on them. What's more is that you can stagger all this throughout multiple frames (check X NPCs/second).
For aiming non-instant projectiles, though, you'll need a bit of math to calculate the required angles. And, you might decide to allow NPCs to aim projectiles at moving enemies behind walls/cliffs. I think UT3 does something like this. This might make those ballistas a bit more fun (to have this make sense in-universe, you could have distant NPCs actually signal to ballistas in some way).
For a navigation mesh, doesn't Unity come with an out-of-the-box system? Remember that some NPCs in Drakan are unusually large and their radius will need to be taken into account during path finding. Maybe you'll have two navmeshes. Or, you may want a navigation grid instead. Navgrids typically use repeated raycasts to get around, as far as I know, which might be better for large NPCs.
If you don't use Unity's or somebody else's navigation system, you probably have to implement your own path smoothing algorithm. One way is to raycast ahead, and another way is to use the path funnelling algorithm. For non-zero actor radius, you'll need to use circle tangents around the corners, if the navigation mesh assumes a smaller radius. Raycasting ahead is linear at best and cubic at worst in the number of triangles, and path funnelling is always linear time. Note that raycasting can be done on the navmesh itself, without involving the physics engine.
Oh, and what's more is that spiders have their special ceiling navigation, which is unusual in games. You can also see something like this in Halo CE, where those flood things just seem to wander around the geometry however they feel like. I suspect Halo CE implemented this by using the level geometry itself as a navmesh. I don't know how Drakan has done this. The level editor lacks a 3rd dimension. Maybe it uses waypoints, or maybe it's all predefined, or maybe it also uses level geometry.
If you want to be fancy you could have an in-game navigation editor like
https://developer.valvesoftware.com/wik ... ion_Meshes. For bonus points, implement an algorithm to form a navigation mesh from a point cloud. This would allow you to create a navmesh or navvolume by simply walking around. Might want to play with voxels, or maybe let
https://github.com/recastnavigation/recastnavigation do it all for you.
You might also want to implement "fleeing" for NPCs, because, afterall, Rynn
is a power to be feared on lower difficulties. The A* pathfinding algorithm should be capable of doing this by letting the distance heuristic be the negative distance from the threat, or something like that. See
https://gamedev.stackexchange.com/quest ... or-fleeing. You'll need to stop the algorithm at some arbitrary point (number of iterations and/or distance). An additional tactic would be to use hand-placed cover markers with that in-game navigation editor you just created.
For navigation performance, don't let NPCs forget their path unless they really have to. A path only becomes invalid if they stray off it or the navmesh was modified at a nearby location. One performance optimisation is to remove the start of the path instead of recalculating the path if the NPC moves to the next triangle. Another optimisation, for tracking the closest triangle, is to follow the adjacency links, instead of doing a full spatial query each frame. The optimisation for long-range pathfinding, if NPCs will ever want to, is to partition the navigation graph into strongly-connected components, and then do hierarchical A*.
You'll also need nav-volumes for flight path finding. For exterior locations, though, you could instead use heightmaps created by raycasting down from the sky, which is what Skyrim uses (or maybe they start with a sea-level heightmap and add objects to it). To make both of these methods easier, shrink the volumes, or dilate the heightmap by an NPC's radius. You would then only need to calculate paths for a flying point.
Importantly, Arohk needs some way to know where he can land, because how else can he defy Rynn's orders? Both nav-volumes and dilated heightmaps would probably work for this. You might also need a way to find the closest reachable point, rather than a boolean "can you get here?" query. For comparison, when Skyrim wants to land a dragon, it either uses one of the artist-placed landing spots, or it searches for the closest point on the navmesh that can contain a circle, and then maybe it checks the heightmap.
For really fancy navigation, use RVOs, such as
http://gamma.cs.unc.edu/HRVO/. This will allow NPCs to intelligently avoid eachother if they're wandering around. Oh, and it just so happens that I really like "increased spawns" for these types of games, for the extra fun factor. So, RVO might be useful if you go down that route. And, for extra fun on high difficulty levels, apply a heavy dose of avoidance steering so that NPCs can avoid Arohk's projectiles of doom.
For a "health system", what you could do is have a number that indicates health as a fraction of some bigger value. Maybe what you meant was a dismemberment system. Drakan specifies dismemberable limbs by defining "cap polygons" for nodes that happen to be animation channels. I assume then that the model splits with duplicated cap polygons and skeletal bones.
I was thinking also about respawn NPCs, when Arokh flew through whole Wartok Canyons there aren't any NPCs left, so little bit boring
Of course I am not fan of games based on gaining experience points,skills(like Skyrim) that means->you better because you killed 1000 spiders in cave. Better when Rynn will have better strenght after accomplish a level.
An alternative to this is to simply have more enemies, to the point where every part of the game feels like a clusterfuck,
without continuous spawning. This kind of crazy stuff makes Fallout 3 and Skyrim liable to crashing, unfortunately, which is also the downside, because this
will stress-test your engine and player controls. You'll also need more sources of health to compensate, or maybe Arohk comes with some physical and/or magical armour, or maybe Arohk and Rynn can be "reincarnated" after a delay in some way as long as they don't both get killed (which probably blows a hole through the lore and would imply that they no longer share health).
About the Mourn Bringer, I tend to think it was meant to make things easier, at least against NPCs that don't use the same weapon. This could be compensated for by allowing only members of the Dark Union to have access to its full power, which would otherwise be half as effective, for example. Or maybe Arohk should be unhappy in some way if she uses such a weapon.
