Chugging along on Magecrawl for SL...

Quick update:

I'm still chugging along on Magecrawl for Silverlight. I just finished ranged targetting with overlays, which makes melee/ranged attacks, inventory/spell use, and operate doors work.

I have a bunch of "easy" dialog work to do, a splash screen to make, animations for ranged attacks, etc. I also have the harder work of a skill tree, preferences, and such.

Back to work - FF XIV currently a bust...

As some of my previous posts mentioned, I was blasted excited about Final Fantasy XIV and planned a month or two of ignoring Magecrawl around it. The short answer is that isn't happening anymore. The game has major balance and lag issues that currently make it not fun to play. If you were interested in it, I'd give it a few months to see if they can shake out the bugs and make it fun to play.

And so, I'm back to normal development again. My plan is as follows:

• Finish up my crawl tiles license project, which just involves a boring night or two in front of changelists.
• Get Magecrawl for SL up and running. My previous post had my TODO list.
• Start work on the backlog of bugs/features. Right now, for each one that involves UI changes, I'm planning on doing it twice if reasonable.

Magecrawl Status Update

I'm making good progress. I finished up the inventory dialogs tonight, and got started on targetting. Here is is my todo list as of tonight:

Other:
Health/Mana Bars
Status Effect/Monster list on character info
Handle player death
Icons in inventory
Hitting z to cast spell, z should target

Dialogs:
Splash Screen
Help

Hard:
Equipment
Skill Tree
Way to edit preferences
Reasignable keystrokes

Message Box:
Up/Down Stairs
Save
Quit
Welcome Message

Requires Targetting:
Operate
Draw ranged attack
Attack Melee/Ranged
Inventory w\ targetting

Obviously rewriting the skill tree viewer will take the most work, but most of the rest of them will fall into place quickly. Four them require targetting, which I'm currently working on, while 6 require dialog to be written (easy). 4-6 of them don't have to be done for the game to be playable, just nice to haves.

[Silverlight] ChildWindow focus bugs, oh my!

Another day of programming, another bug in silverlight to work around. When I'm not working around bugs, I'm crazy productive however.

The issue today is key focus, in particular with ChildWindow. This class allows you to place modal dialogs up with a minimal of fuss. The problem is that for some reason they weren't getting keyboard focus correctly. This is a big problem when you want your entire game to be able to be run from the keyboard alone.

Here is my solution (with help from a friend):

public ChildWindowNoFade ParentWindow;

        public ChildWindowNoFade()
        {
            this.DefaultStyleKey = typeof(ChildWindowNoFade);
            this.Loaded += new RoutedEventHandler(ChildWindowNoFade_Loaded);
            this.Closing += new EventHandler<System.ComponentModel.CancelEventArgs>(ChildWindowNoFade_Closing);
        }

        void ChildWindowNoFade_Closing(object sender, System.ComponentModel.CancelEventArgs e)
        {
            Dispatcher.BeginInvoke(() =>
            {
                if (ParentWindow != null)
                {
                    ParentWindow.Focus();
                    if (ParentWindow.InitialFocusItem != null)
                        ParentWindow.InitialFocusItem.Focus();
                }
            });
        }

        void ChildWindowNoFade_Loaded(object sender, RoutedEventArgs e)
        {
            Dispatcher.BeginInvoke(() => 
            {
                Focus();
                if (InitialFocusItem != null)
                    InitialFocusItem.Focus();
            });
        }

        protected abstract Control InitialFocusItem
        {
            get;
        }

Roughly, I'm creating a base class that hooks into loading and closing of windows. It fixes up the focus problems in cases of stacked modal dialog (where ParentWindow is non-null).

A few other notes:

• Some child windows act funny with keyboard focus if they don't have controls in them and/or they don't have IsTabStop="True" TabIndex="1" set on the window
• System.Windows.Browser.HtmlPage.Plugin.Focus();    If you call this guy on the creation of your root object will give your application focus.

[Silverlight] Binding to list box elements throwing MethodAccessException

I spent an hour or two figuring this out, so I figured I'd post about it. Hopefully, the next poor soul who runs into it will find it here:

I was running into a problem binding my list to a Silverlight list box. On listbox creation, the output window had lots of lines that looked like this:


System.Windows.Data Error: Cannot get 'DisplayName' value (type 'System.String') from 'Magecrawl.Items.Consumable' (type 'Magecrawl.Items.Consumable'). BindingExpression: Path='DisplayName' DataItem='Magecrawl.Items.Consumable' (HashCode=45492604); target element is 'System.Windows.Controls.TextBlock' (Name=''); target property is 'Text' (type 'System.String').. System.MethodAccessException: Attempt by method 'System.Windows.CLRPropertyListener.get_Value()' to access method 'Magecrawl.Items.Consumable.get_DisplayName()' failed.
   at System.RuntimeMethodHandle.PerformSecurityCheck(Object obj, RuntimeMethodHandleInternal method, RuntimeType parent, UInt32 invocationFlags)
   at System.RuntimeMethodHandle.PerformSecurityCheck(Object obj, IRuntimeMethodInfo method, RuntimeType parent, UInt32 invocationFlags)

The answer is that under Silverlight, you can not bind to non-public objects. The Consumable objects noted above was a internal object with a public interface. Once I made it public, the problem went away.

A side note, this apparently also occurs if you bind to an anonymous type as well.

Why getting your licensing straight is important

So, you might have noticing my posting frequency has decreased the last few weeks. A few things factors have contributed:

• Deadlines at work give me less time/energy to code for fun
• Final Fantasy XIV is in open beta
• Side projects

One of those side projects is what I want to talk about. As you might have noticed, the Silverlight prototypes uses the wonderful graphics from Crawl. Those graphics were based on rltiles and expanded upon by many great artists.

However, no explicit license grant was required of those submissions, and such they are by default under Crawl's license. It is derived from Nethack's license, and is incompatible with pretty much everything. I got around this in the short term by duel licensing magecrawl under BSD/Crawl, but this is not something I'd like to continue forever.

In talking to the development team, I offered to attempt to contact the 20-30 people who have made changes and ask for them to relicense their work. They were interested in getting away from the crawl license, and so they agreed. The license that I suggested and we settled on was this one, which is pretty much a cute way to say "public domain".

The e-mails are still going out to try to get a hold of everyone. This work is going to suck up at least a week or two of my programming nights when it all finished. In addition to that, if I can't get a hold of some people, those tiles will either have to be redone or separated from the "public domain" tiles.

If the number of people that touched the tiles was higher, in the hundreds or thousands, it would be impossible to get everyone to sign off. The impossibility to relicense the Linux kernel is a great example of a project that is in that boat. It is somewhat different, because they are happy with the gpl v2.

This is why getting your license straightened out early is important. Here is a 30 second, I am not a lawyer so don't pretend I am one (not even on TV), summery of licensing.

• "Public Domain" - Technically not a license, the idea is to give up all rights to the code. This CC license or the WTFPL licenses are in this class.
• "BSD" - This is the next step in being restrictive, but just barely. The license only requires that you keep the copyright notations on the source code. The MIT license is also very similar.
• "GPL" - A very common license, with the idea that the source code should stay "open/free". Roughly, any code linked to GPL code must be GPL, and you must offer to distribute any changes that you make to anyone you give copies of your program. It places more restrictions on you as a programmer (other licensing may not be GPL compatible and hence a GPL program can not link against them), and also places restrictions on anyone who distributes your program. However, it prevents anyone from using your source code without opening their changes.
• "CC" - Many of these licensing don't apply very well to things like text and artwork. The creative commons licensees many times are good fits, with many different flavors.
• Proprietary - The source code is not open for view/edit. Uncommon but not unheard of in roguelikes. Can not link against GPL code, but can use BSD/Public Domain code.

Silverlight fun and arcane "batteries"

While the open beta of Final Fantasy 14 has taken more programming time away that I'd like to admit, I haven't dropped off the face of the planet yet. I've made good progress so far on the new "tiles" GUI, using silverlight. See this video for a quick video of gameplay. There is a huge number of things needed to make it fully functional, ranging from picking up items to the skill tree.

Assuming I was able to make the tiles interface work on Windows/Mac/Linux, both in the web browser and in a stand alone application, I've been toying around with the idea of ditching the ascii interface. I personally enjoy playing the tiles version of crawl more than the ascii version, and I feel I could make either two decent front ends or one awesome one. There is a lot of "if"s still in the air, but would doing that enrage anybody out there? While in the end I'm programming this game for personal pleasure, I do care about the opinions of the players of my game.

Another idea floating around my head is redesigning the magic system in Magecrawl. Right now, it is a fantasy standard MP system, with the MP being generally recharged after every fight. This makes fights "front heavy" with the characters dumping most of their MP early on, and resorting to melee afterwards. Also, it generally devolves into spamming the most powerful attack spell over and over. When I think about arcane duels, this isn't how I imagine things. I imagine almost every round until exhaustion some spell being cast, whether it is a earth-shaking powerful effect or a simple cantrip.

It is hard to make such a wide spread of spell types and tempos effective in the current system. My idea is a take on recharge magic, with a twist. Each spell has a total amount of "energy" that is needed to cast it. The player has a "battery" of mana, which at the end of each turn (that isn't spent moving?) some is syphoned off to fill each skill not ready to cast.

With a property selection of spells, one could alternate between two relatively fast recharging spells, or cast a range of spells (damage, push back, damage, blink away). Long term effects could reduce either the total "battery" before spells start running dry or the rate that spells recharge. Playing arcane characters should be about casting spells and making things blow up :)