One Shiny Ring to Rule them AllPosted: 2015-08-24 Filed under: Debugging, General, Guildsmanship | Tags: gaming, UI Leave a comment
After playing around with tactical movement (which I’ll hopefully be getting back to shortly), I spent a few weeks playing around with magic item creation. Rather than go through the litany of development, I’ll cut to the finale: the ring of invisibility; a somewhat classic trope of fantasy.
I’ve had basic support for invisibility built-in for quite some time as the creature awareness system needs to be able to determine what can and cannot be seen. What I hadn’t completed (or worked on) until the past week weeks was the invisibility spell, nor magic items (nor apparently any in-game actions to put on or take off body-slotted items).
So here we are now:
The command-word activation isn’t currently running through an environment interaction, I haven’t completely normalized how the sounds propagation works or which actions require verbalizing (apart from spells with verbal components). One of the many things on my to-do list.
One of the oddities of the invisibility spell is that it requires a will-save:
Well, if I saw myself before, I don’t see myself now…
Just to get an outside perspective, I’ll switch to another viewer, Spidey the spider…
Looking through spidey’s eyes and checking his awarenesses, the Wiz is definitely gone…
Removing the ring will deactivate the invisibility effect…
Well, I can obviously see myself again, now to check Spidey…
I have that loosing awareness doesn’t clear the targeting queue in the UI. That’s a minor problem since on the server you still won’t be able to target directly. Mostly needs some client UI work since the targeting system is all client-side.
DCIVPosted: 2015-08-17 Filed under: Coding | Tags: refactor, UI Leave a comment
It’s been a few months since I’ve posted, but I’ve had over a hundred code check-ins since then. A quick round-up is in order:
For the first week after my last post I was debugging, performance tweaking and refactoring a lot, trying to cleanup some code and get the system to behave more like I’d expect as a user. One of the major “new” accomplishments from that week was getting the spider to climb on the ceiling, and before two weeks were out, climbing around corners and fixing some client window issues.
Early June had some fixes to the workshop (and support functions in the core) for room editing and light propagation through room links. The bulk of June into early July was working on movement-related things such as multi-step movement targeting which involves picking a cell in the distance (using target selection) and moving towards it with a single UI command; as both an alternative to single-stepping, but as a requirement for overrun and tumble through (as well as jump). I basically had to rework the single-step movements to be a “degenerate” case of multi-step to get the whole system to be relatively streamlined.
June also saw the beginnings of my refactoring for VS 2015 (using the Community Edition Release Candidate).
By about July 26th I was experiencing a small amount of movement burnout (since I still hadn’t completely worked through overrun, tumble and bull-rush like I intended, let alone jump, run or charge). And moved on to some other things.
Fade-Out, Fade-InPosted: 2014-04-11 Filed under: Coding, General, WPF | Tags: AvalonDock, MVVM, UI Leave a comment
Since January, I have actually been a bit busy; I just haven’t been posting as much.
I had previously gotten a solid animations (TransientVisualizations) implemented and tested for Magic Missile. I hadn’t, at that time, done much with the Disabled/Dying/Recovery sequence of conditions (which became apparent when I Magic Missiled my target dummy to negative health points). It turns out to be a bit convoluted, but I managed to re-do some stuff and make it all work.
During that core-rules sweep, I started getting a bit wrapped up with fatigue and exhaustion (the game conditions, not me personally), and noticed that sleep wasn’t required or forced by game-mechanics (*sigh*) not entirely sure on what that will mean going forward. Certainly sleep is needed for spell-casters, but non-casters could theoretically stay awake for-ever without any game-mechanic penalty. I’ve read some ideas, but I think I’ll defer for now.
Anyway, after that I planned to work on action aiming, which would require some substantial client-UI work and view-models. I had been planning on adding multi-character capabilities in the “test client” for some-time, and it seemed like I should do that before adding the aiming UI. I also wanted a more-flexible UI and decided (eventually) to use AvalonDock, as it would allow dockable and floatable windows.
I started working with AvalonDock on the host application, and had enough success and knowledge gain to begin the same with the client. The main challenges have been converting the control-routed-event model I originally used years ago, and converting it to a more MVVM-ish model. I had already moved a good part of the client to MVVM, but now saw that I had much more to do (commands in the model!)
After I get the UI re-factor done (and add multi-character login support), I’ll include some screenshots here.