Jump to content

  • Log In with Google      Sign In   
  • Create Account

- - - - -

UI Widgets and Views

Posted by , 18 October 2013 · 873 views

Goblinson Crusoe Urho3D turn-based rpg hex-based rpg ui programming sucks
Spent some time today digging deeper into the particulars of the UI, and started working on some general-purpose widgets for skill-bars and scrolling spellbooks:

Posted Image
Posted Image

Basically, the skill bar is a container into which you can dump action buttons. The container has methods to iterate the buttons and activate/deactivate based on whether or not the object owning or using the container can cast the spell associated with the button. It checks resource quantities, movement points, and has a (currently stubbed) query for status effects such as sleep/paralysis as well. The skillbar also implements a second method which accomplishes the same thing, but which at the same time will sort the actions so that the castable skills are listed first, and deactivated buttons follow at the end of the list. Spellbooks will use this functionality to make things more concise.

A lot of my time was spent hammering out the particulars of how Urho3D's ScrollView widget works, and sketching out a number of flow diagrams to assist me in putting it all together. I started on the spell quick-bar functionality, but I'll have to finish that tomorrow (assuming work is slow enough).

For the spell quick-bar, I intend to implement a skillbar that has the special functionality that a right-click on one of the skill slots will open a spellbook containing a (sorted) list of all the player's castable actions to choose from; choosing one from the spellbook assigns the skill to that slot. This is for a quick-bar only; you can still cast directly from your spellbooks if you so desire. It's just that the quick-bar will make certain commonly used skills quickly accessible and hotkey-able.

Additionally, objects in the world can have a spellbook attached to them, accessible if a player unit Uses the object. (Similar to Looting. In fact, I'll probably just make Looting a specific case of Use.) Typically, this will be used for teaching the player new skills. Say he successfully clears a rival wizard's tower and reaches the lab at the top. The rival's spellbook should be there, and he can possibly read it to learn new spells. Or maybe he stumbles across an abandoned smithy, which might contain some of the former smith's notes on crafting a certain item. For crafting and spell research back at his home base, he can use the spellbooks attached to his workbench and other equipment.

So how do you like the UI system in Urho3D?  Is it a nice model, or do you feel like it could be better?  I'm always on the lookout for a good system to model my own UI on, so any advice would be appreciated.

yeah, how is the UI in urho3d, how extensible is it?


And would you still recommend Urho3d over Irrlicht or SFML?

I'm not sure how the UI stacks up to others, to be honest, since I've usually written my own in the past rather than trying to work with third party. But it seems to work okay, and it hooks directly into the event system that stands at the core of Urho3D, so integration with other aspects of the game is a breeze. However, the range of available controls seems fairly small. I can make it work, since my UI will largely be button-based, but more elaborate UIs might be take some custom component writing.


Mars: I absolutely would recommend Urho3D. I'm pretty much sold on it. For one thing, it's a component-based system, so it fits right in with the way I've been doing things for several years now. It lacks the residue of years of classic object-oriented design that you see in older libraries like Ogre and Irrlicht, being designed from the ground up to be component based. The scripting system, through either AngelScript or Lua, is robust and well-integrated, and it provides a large set of systems in addition to the 3D engine, even integrating Recast and Detour for pathfinding, Bullet for physics, etc... After so many years tinkering with Ogre, then later Irrlicht, it's nice to finally have a framework that meshes so closely with what I want to do. Plus, it builds for a large set of systems (even on Raspberry Pi), so it can help me break away from the PC if/when that ever becomes necessary for me to do.