Remember you can support us on Steam GreenLight and vote for Dungeon Kingdom :
http://steamcommunity.com/sharedfiles/filedetails/?id=296809307
Thanks !
Remember you can support us on Steam GreenLight and vote for Dungeon Kingdom :
http://steamcommunity.com/sharedfiles/filedetails/?id=296809307
Thanks !
Hello brave adventurers !
The Dungeon Kingdom official Forum is online !
Join us here http://forum.dungeon-kingdom.com/
You can support us on Steam GreenLight and vote for Dungeon Kindgom :
http://steamcommunity.com/sharedfiles/filedetails/?id=296809307
Thanks !
If you like our game, please support us on Steam Greenlight and vote for it :
http://steamcommunity.com/sharedfiles/filedetails/?id=296809307
Thanks to those who already voted for us and for the kind comments !
AI Navigation into games is complex problem if you want it to be done right and realistic. Like for the AI system mentionned in he previous post, despite i tend to “revinvent the wheel”, i tried to make an effort by using public tools. Unfortunately, i had to write my own, and this it the story i’ll tell you now :
In an old school Dungeon Crawler, you can avoid writting a complexe AI navigation system : the square based architecture make everything easy to handle, and most games of this style process that way. But that’s the other games. For The Dungeon Kingdom, the AI has to be smart, and the navigation system efficient ! Ah..and i forgot to mention, everything need to be dynamic ! I did check the available tools & plugins for Unity, but most are simple A* system using a static graph or build by hand into the tool, wich is the opposite of what i needed for The Dungeon Kingdom…! So instead of spending ages seeking for the pearl, i wrote one !
So i created a bunch of scripts to automatically generating the navigation graph at runtime. In The Dungeon Kingdom, the game is building the navigation graph when playing.
One feature i added is a crowd factor to the waypoints, so the creatures, depending their size, can push the pathfinder to temporaly disable the waypoint from the graph for the others navigating agents.
Another feature: the graph has informations about locomotion type and state of the links : for example some of waypoint can require a monster to be a fly type of creature to reach it. About states, some access can be dynamically disabled, or like when you open a door (wich is automatially detected by the dynamic navigation graph building) an access to a waypoint can be restored / added. Same for pit. Actually, there’s no difference between a door or a pit for the pathfinder, it uses the same flexible system.
Note that despite the “Case by Case” system, and square based arthictecture “ala Dungeon Master”, in The Dungeon Kingdom the navigation system is totally universal and would work for any kind of environment. There’s no “Square” design limitation : the waypoints can be linked to any amounts neighbors, and those waypoints can follow any typology. And to finish, the waypoints links states are bi-directionals. Let’s see on the screen shot why it’s important :
The wire lines are drawn by the debug mode inside the tool, it shows the generated navigation graph. The blues lines are waypoints, green are opened links to any locomotion type. Yellow lines are links opened to flyers only (here because the pit is closed). Red is closed link.
Next time we’ll talk a bit about render optimizations and graphics options, or we may post a new in game video… So keep an eye on the website.
When it’s time to give life to creatures and create AI, there are several options : you can code it by writting scripts, or use tools such as Finites State Machine or Behaviors Tree.
Creating the whole Artificial Intelligence by scripts is great for a developer wich is also the one integrating the AI, wich is my case. However it’s not the ideal solution for complex behaviors , especially if you need flexibility and can also be tricky to maintain / debug.
Second option, use common tools to write AI, like FSM and BT. Nice tools, and both BT and FSM can be mixed. I have the bad habit to reinvent the wheel (wich in my opinion is not that bad if you really want to understand the coding way 🙂 ) , but this time i decided to gave try to some public tools instead of coding my system. Unfortunately, after some tries, i end-up with that conclusion: it can works great (BT can be wonderfull !), but not suitable for my needs. I need the creatures of The Dungeon Kingdom to be smart, very smart. Not just simple “if see player, reach and attack” style behaviors. I also need the creatures’s Artificial Intelligence to be smart, tweakable, and easy add variety to a base one. With those requirements in mind, it can be tricky to handle such an AI with common tools. I then decided to revisit an 8 years ago AI design i have written in c++ for a AAA class game. Of course, i have rewritten all from scratch in c#, and improving it greatly !
So what’s this AI system like ? Basically, it’s a “virtual” brain, and like any real creatures, it is made of elements/features such as sensors (vision, hear noise…probe environment…), memory (in my design, i call them cells. Add to this macro behaviors and controllers and you get the AI system. I won’t enter too much in details here, but the system has been created with flexibility in mind, and fast complexe behaviors creation. Sensors automatically create Cells, wich have automatic values history tracking and others cool features, behaviors and controllers ( a controller is permanent / parallel behavior in this system) has weight, randomness, priority, cooldown and all you can dream to help the brain decide wich behavior to execute. Let’s see how does it look into the editor (here in play mode) :
You can also notice in the 3D viewport some lines and differents shapes wich are sensors debug informations, like creature’s field of view etc. etc.
This brain setup is basic, but already good enough to create unpredictable behaviour (by the player) .
That’s all for this post, next time i’ll talk a bit about the creature navigation !
I am glad to introduce you 3 talented guys who join the effort of bringing The Dungeon Kings to life:
– Marc ‘Weren’, is the original writter of the world in wich The Dungeon Kings world takes place. Worth to mention it to newcomers, The Dungeon Kings will get few sequels, and has a strong story and a deep history context. Weren is working hard to make richer the story of the first chapter, and improve the current story telling.
– Ralf, a talented artist who has made the Dungeon Master art pack for Dungeon Master & Chaos Strikes Back mod for Grimrock.
– Jason ‘Seriously Unserious’ will care about the community on our own forum but also on other websites and help for translation.
They are great guys and passionate, and our best wish is to let you feel it while playing The Dungeon Kings !
Note: the user interface layout is set to Touch (mobile Tablets) mode for this video.
The Dungeon kings interface was in place for some weeks now. However i was far to be satisfied with it. Note that it’s about the TOUCH interface for mobile/tablets. The heroes panel was located at bottom of the screen. Nice for a panoramic view. However, there are two problems :
-DK has mainly indoors, so panoramic view is not so well suited. And also, panoramic/large view allow to see more things around, but the field of view’s “height” is reduced : you see smaller portion of the floor/ceil. Not so great as there are items or traps on the floor !
-Secondly, the game run on different devices and screen sizes. iPad has a screen ratio of 1.33 , iPhone 4/4S 1.5, iPhone 5/S/C, Nexus 7, LG G2 have a 1.7 ratio ! It brings problems when designing an interface based on screen width !
After struggling with the ergonomy, i decided to created a new playfield interface: portraits are now located on the right. Let’s see the new UI:
The red squares are actually replacing the green bars on the old interface, they are Magic and tireness indicators wich are glowing more or less according the value. Note that you can’t see on the screenshot, but items part is automatically scrolling out of screen when opening the inventory, leaving more room for 3d view and allowing drag and drop from 3d view to inventory slots. Also note that on desktop computers using mouse, you can both take item as cursor, or use drag’n drop like on touch devices ! And at last, the FOV and 3d viewport are being adjusted dynamically when the heroes panel and inventory panel are scrolling to keep a wider 3d view area when screen is partially filled by theses interfaces panels. The Arrow panel will disappear if using swip touch control mode for moving, and will be much more transparent in cursor keys mode.
After playing a while, i am now really satisfied with the current UI (user interface) layout. On small screens, i am planning to add button to automatically attack/switch heroes, making it easier to quickly attack on the small screens : hit the button, to launch an attack with curently selected hero, then after the attack is launched, the game will automatically switch to next hero, waiting for you to press again the button and repeating the process. Of course the game will decide wich hands / attack to launch for you. Keep in minds this is purely optional and targeted to small screens only.
I am finally glad i spent time to change the ui, and feel so motivated to go on creature fighting !!!
Compare the ui to old layout :
The new interface features much less lost in 3d viewport height, and more convenient to use for mobile device !
Now back to creature fighting !!