Sunday, January 31, 2010

Magecrawl changes license, now new BSD license'ed

Magecrawl is being relicensed under the new BSD license (3-clause). As the sole copyright holder of the source code, (the other person who helped at the very beginning both assigned me copyright and is cool with the change), I'm able to do this with little fuss.

The reason I did this is primarily due to my interested in MEF, which seems pretty cool and I'm interested in trying. MEF is licensed MS-PL, which is basically BSD licensed with a clause that says roughly "if we have software pattens that apply you can use them, but if you sue us, we can sue you back using them." I actually don't mind that clause in general, unfortunately the GPL isn't compatible with it since it is an additional restriction.

More generally however, the idea that the source code I wrote couldn't be combined with something arguably under fewer restrictions annoyed me. I realized that I had defaulted to GPLv3 not out of any ideological reason, but just because it seemed like a good place to start. I think the BSD license is closer to what I want, since I'm not expecting any commercial software company to eat up my code and sell it without giving me any credit. If you do happen to grab a segment of code larger than a "small chunk", letting me know and a note in the credits would be nice however. :)

Note: Technically I realized that tech demo I and II have been released without the required license text files saying libtcod, libtcod-net are both BSD and sdl is lgpl. If someone really wants to me, I'll pull them all down off the website and make fresh ones with the text files attached. I've fixed hg truck, so new released will be correct.

Plans for Iteration 8 and beyond

Now that iteration 7 and the second tech demo is out the door, it's time to sketch out some plans. The plan is two more tech demos to flesh out more functionality, and then I'll start with "slices". A "slice" would involve fleshing out content for say one class and some themed levels. Each slice would be a balanced mini-game within itself. Once I get a few of those slices done, I could release what I'd consider a "real" game.

With that, iteration 8 is planned to take a month and a half to two months. The headlining feature, taken from "How to Write a Roguelike in 15 steps", is "Experience". This'd involve different level monsters, a skill tree for the player, and increasing difficulty. Beyond that, I have a significant number of refactoring and rearchitecture tasks to handle.

The high level goal for iteration 9 would be hacking out the basic parts of the economy. My thoughts on that can be found here, here, and here.

Non-English operating systems, InvariantCulture, and You

As previously mentioned, Magecrawl's 2nd tech demo was released yesterday. I received multiple reports of crashes during map generation. After some detective work, it became clear that all of the reporters were using non-English versions of Windows (Polish and French). This issue can be boiled down to this simple string:

"10.0"

In some languages, the period there is replaced with a comma. All of the .NET languages by default, defaults to using the system language. This creates problems when text written using one separator is read by a program using another. The text is read fine, but when you try to parse it to a number, an exception is thrown.

The solution easy (arguably hacky) solution that somebody showed me is to tell .NET to "stop doing that".

            CultureInfo previousCulture = Thread.CurrentThread.CurrentCulture;
            Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
            //Your code here that depends on reading/writing text between languages.
            Thread.CurrentThread.CurrentCulture = previousCulture;

What we're doing here is saving off the current thread's "culture" and setting it to InvariantCulture. Then we can do our operation, and reset it back when we're done. In my case, I wrap the functions save/load functions and those that read spell/item/monster information.

If you've been bitten by this issue in Magecrawl, grab the new release here. If you use an English OS, there isn't a behavior change.

Saturday, January 30, 2010

Magecrawl Tech Demo II is released!

After a late night of testing and tweaking (and one more feature),  I think I'm ready to call tech demo II done and get it out the door!

For those that are keeping score at home, the new feature is the idea of "camp supplies". Think "tent" from Final Fantasy if you've played that game. When you use it, you burn n number of turns resting, restoring a nth amount of your hp/mp every turn. If a monster comes into view, you wake up and loose the rest of the effect. I'm not sure if that's how I want to handle things in the full game, but it works great for the tech demo.

To respond to jice's question, yes at this point I'd consider it a game. It's replayable, and somewhat fun. I have a long way until i consider it finished however, hence the fact that it's a "tech demo".

Grab it while it's hot. It's been testing on Windows 7 and Ubuntu 9.10. You'll need the .NET 3.5 framework if you're on windows (http://tinyurl.com/b8jjz7), or some form of mono on Linux (apt-get install mono-runtime for Ubuntu).

When you download it, you might want to edit Preferences.xml to change your name and hit '?' in game to learn the controls.

http://code.google.com/p/magecrawl/

Friday, January 29, 2010

Iteration 7 is Feature Complete!

Tonight I just finished up iteration 7's last feature. Some of the new features of this release include:

  • Different monster types with varying behaviors
  • Armor (and the basic bits of a real combat system)
  • Betters graphics (more color, HP bars, etc)
  • Move to location/run in direction
  • Lots of fixes to ranged weapons and spells
  • Lots of speed/memory optimizations
I'm pretty happy with how this iteration has gone. Now that I'm feature complete, I want to do some tweaking before I kick out a tech demo II. Right now, all the monsters have similar stats, and game is too difficult to be considered finishable.  Once I get that done, I'll post again with the details.

Sunday, January 24, 2010

Some things take much longer to finish than you expect, others not so much...

Predicting how long a task will take is apparently both difficult and something one I am not very good at. The reason this comes up stems from the fact that I'm using the "Student and Startup" version of FogBugz for my bug tracking needs. Besides being epically awesome in general, it also has a feature where you can set estimates on how long tasks will take. After telling it when your working on something and when you finish, it can figure out how accurate your estimates are and give you a good estimate on when you will get done with everything targeted in your current milestone.

Eitherway, FogBugz told me there was almost no chance for me to get everything done that I wanted in a week, assuming that I spend as much time as I currently am programming. I used this to punt on some "nice to have" things, and get to work on what I really wanted to have for next week. One of things was to finally finish all my issues with ranged attacks.

I finally had sorted out all the bugs and issues with lightning bolts yesterday, only to find out that I had uncovered a bunch of flaws with the other forms of ranged attack (via weapons or single target spells). Both would show the animation if you targeted an empty square, but hit nothing (and not use ammo/MP). There were three different code paths for showing ranged animations, and three different ways we were calculating targets and damaging them. Sorting all these out took a good 4 or 5 hours, but now things are more sane.

One I got that submitted, the next task was to have enemies remember where a player was if they duck out of sight. That way, they could head that way and "chase" the player. That took all of 20 minutes to implement, test, and submit. It really is a toss up sometimes, I was expecting that to take longer.

The estimate is 12 hours of work left before I can start testing the tech demo II. Time to get back to work.

Wednesday, January 20, 2010

Easy version control - Why you should submit early and often

So the changelist that brought writing this post to mind was this one. I was working last weekend on Magecrawl, and decided that writing a "lightning bolt" like effect shouldn't be that hard. It just travels in a straight line until it hits a wall (or travels a maximum distance), hitting every creature in its way. In developing it, I violated a rule I try to follow in development both at home and work.
  • Each change should only do one things (Add feature, fix bug, fix performance issues)
  • Corollary: Submit each change independently as early as possible
It started off with the basic infrastructure for a new effect type, and then it ballooned into multiple different attempts of writing new subroutines to calculate the path of projectiles. After that, I didn't like the way it looked when drawn, so I refactored how we drew all ranged attacks on the screen. I also tacked on some unrelated preference settings, and some bug fixes.

The reason this was a problem was that things took twice as long as they would have if I was disciplined. Keeping changes small makes testing them before submission easier. It makes reviewing before submission easier (I review my changes for submission to keep myself from submitting lazy hacks). After each part, the lightning bolts still weren't right, and I got discouraged from hacking on them further.

Submitting early and often forces you to keep biting off small bits of the problem, fixing or implementing just that part, testing just that small part, and getting it submitted so you can work on another. I find that it works well for me.